The most value adding ceremony

A well managed sprint planning meeting is the answer. Well organized sprint planning meetings provides the opportunity for participatory development by discussing diverse logic for achieving the same objective, and then converging to a single logic by aggregating the best of every design view. It is in the planning meeting where the development team members get amble opportunity to learn and share. Irrespective of the duration of the sprint, a well conducted sprint planning meeting will be between 5 to 8 hours duration, which is equally divided into two halves. The first half is for understanding and estimating the size estimate (story point) and the second half is for decomposing the user stories into activities and estimating the effort required for the activities.

Common obstacles for conducting effective sprint planning meeting; 

• A general belief that planning time is wasted time.
• Highly technical scrum master who likes to dictate estimates to the rest of the team.
• Lack of domain and technical knowledge of the team, which prevents them from arriving at reasonably realistic estimates.
• Lack of trust in the team.
• Product owner and scrum master roles overlap developing conflicting interests.
• Lack of requirements readiness

Prerequisites for effective sprint planning meetings 

• User story availability
  • Reviewed for completeness
  • Acceptance tests defined and reviewed
• Teams capability measures from the previous sprints (velocity, average velocity)
• Domain knowledge of the team
• Technical capability of the team
• 5 – 8  hours dedicated slot. The scrum master / product owner  should see it as an investment
• An open environment conducive for open discussions without any fear

Outputs of the sprint planning meeting 

• Sprint / release burn down chart for the product owner and the senior management  (Y axis – story points, X axis – duration of the sprint)
• Sprint burn down chart for the development team and the scrum master (Y axis – balance effort to complete the sprint, X-axis – duration of the sprint)
• Tracking board

10 points for effective #scrum meetings

1. Scrum meeting or the daily scrum is not allowed to go beyond 20 minutes in any circumstance. Every body in the team must be aware of the concept of time boxing, and the about the non negotiability of time in scrum.  All must be trained on scrum, or all in the team must have read and understood the scrum guide.
2. Daily stand up meetings (scrum) must happen every day. If possible schedule it at the same venue and at the same time.
3. The team members must stand in a circle, to ensure that there is no hierarchy in the team.
4. Since it is the team’s meeting, scrum master / product owner presence is not mandatory. Very often their absence in the meeting helps.
5. The objective of the daily scrum is to understand the status of work (sprint), so this meeting must not be used as a issue resolution meeting.
6. Each member updates three things to the rest of the team;
   1. What did I do yesterday?
   2. What am I doing today?
   3. What are the issues I am facing, and need help.
7. Each team member can take up to two minutes to update the status of his/her work to the rest of the team.
8. If someone needs help to complete his / her tasks, then other team members can help (after the stand up meeting)
9. If the scrum master’s intervention is required to sort out some of the issues, communicate that as an action item for the scrum master.
10. Revisit point 1 about the non negotiability of time.

Time boxing work – the nano sprint

The best way to experience the power of time boxing is to do sprints of 1 hour duration using a timer. The count down starts from 60, 59,58…and the pressure to complete the task planned within the one hour start building up. The pressure with pleasure. My ipod which I abandoned long time ago have found new purpose now as my timer. At the end of the day, it is not that great news. I have not done much of that useful, important work. I will improve.

A young gentleman walks into my cabin for…

A young gentleman walks into my cabin for the first time to borrow some money for his lunch, and he is a team member who did not get his salary on time. That was a very powerful message to me. Points to the challenges of a start up, and the sacrifices and sufferings behind a startup. Unfortunately it is hampering the commitment and motivational aspects of the team, which dilutes the sprint.

Story tellers….

What is the story of your project?. What is the story of your work?. What are the stories of the users of your product?…How is the product going to change / make their stories inspiring. Can you narrate it with enthusiasm?. Only then you should write the user’s stories…else they become dull and pale…and will not deliver much value to the users. Today was a forced holiday, due to bundh (strike), and that gave me some time to introspect about my current project. Unfortunately, I am struggling to narrate the story of my project to myself convincingly. Do you have a project story for me, which can be narrated to me with enthusiasm and passion…

Writing a story is different from telling a story. If you have to tell a story to an audience and capture their attention, then it must have something in it. We can always write boring stories and send to someone, where as we cannot tell an uninspiring story successfully.

Liked this video about UI design

Reusability is a mindset

That is the learning of the day. After a long stint of coaching, today I had the opportunity to listen to a very experienced person about various aspects of software engineering. One of his catch phrase was ‘Reusability is a mindset’. That answered my dilemma of defining the reusable components. Should it be a module, a function, a template, error messages, test cases…it could be all of these and more. That is my learning for the day.

 

 

When the sprint fails…

Whenever I discuss about the need for ‘committed’ , ‘capable’, ‘motivated’, mutually respected teams as a pre-requisite for scrum, generally the body language of the recipient of this is that of cynicism. Unfortunately, in reality, based on my experience , agile frameworks, or any ‘knowledge related work’ is bound to fail without these basic human elements. Of these ‘mutual respect’ is the most important aspect. Without mutual respect, commitment will not happen. Without mutual respect, motivation will be affected. Everything starts from mutual respect, between team members, scrum master, product owner and the sponsor. The litmus test of ‘mutual respect’ is how gracefully we treat an agile team, during the sprint review meeting of a failing sprint.

Planned velocity is ’10’, achieved is ‘6’. If ‘6’ is not agreed upon by the product owner, then the sprint has failed. Will this lead to ‘release date’ slippage. That could be the immediate concern of the product owner. Answer is a ‘yes’ and ‘no’. This may affect the release date. This may not affect the release date if the velocity increases during the subsequent sprints. The most important aspect to be taken care of during these scenarios is to protect the ‘motivational’ aspect of the product owner, scrum master and the product owner. When the team is in the forming state, and working on a new technology / architecture, this is bound to happen. Patience is the key to deal with such situations. This is the time to invest heavily in production capability improvement, than hitting the roof for low productivity. Remember, great managers do not do much to motivate their teams, and at the same time, they do not demotivate their teams. One must protect the commitment, motivation and mutual respect, self respect aspects of self organizing knowledge workers throughout the assignment at any cost. This is applicable to all stakeholders including the development team members.

Recently we had a long project team meeting to resolve an issue. We invited some key team members for a critical meeting to get out of this do or die situation. They participated actively, we planned all the action items to be implemented the next day, and towards the fag end of the meeting the one key team member who was also part of the entire meeting turned up and said ‘I am on leave tomorrow‘, while waiting for the cab to go home at 10 pm. That really hurt, and still hurts me, the senior manager, who pitched in to help, even when it was not my key responsibility. I am not against someone taking leave for genuine reasons during the middle of the sprint. He could have told me about  leave upfront, which would have given me opportunities to plan other alternatives.  I am also human. Yes, respect has to me mutual. In agile teams, we motivate each other. The entire team must commit to the sprint goal and achieve it.

A word of caution about Transparency and predictability

Yes, I stick to the promise of scrum delivering better predictability and transparency. The flip side of this is what we see through the newly gained transparency. The reality could be bad news. Just by following scrum alone the productivity will not improve. This realization happened during the consulting assignment at a startup. I knew that engineering capabilities will not happen overnight in any organization where everything was happening ad-hoc,  which is the characteristic of almost every startup. They needed holistic approach to improve;

• pre-sales process
• project planning
• project tracking
• requirements management
• design / architecture
• estimation
• coding
• testing
• defect management

I did not want to reinvent another capability maturity model, because i felt it will be better if my client implement something proven and popular. That forced me to go back to the CMM-Dev model after two decades. That is a great opportunity to look at CMM-Dev from an agile perspective (not from the CMM assessment perspective. Here are the KPAs of the CMM-Dev latest ;

• Causal analysis and resolution
• Configuration management
• Decision analysis and resolution
• Integrated project management
• Measurement and analysis
• Organizational process definition
• Organizational process focus
• Organizational performance management
• Organizational performance management
• Organizational training
• Product integration
• Project monitoring and control
• Project planning
• Process and product quality assurance
• Quantitative project management
• Requirements definition
• Risk management
• Supplier agreement management
• Technical solution
• Validation
• Verification

This is in alphabetic order. To my surprise, the current level is almost 0 for most of these and 1 for some of them. I consider this as a good starting point. Still we believe in people more than processes and tools. We will ensure that nothing that does not add value will get rolled out.

‘Why do a car with automatic gear shift have a tachometer?’ …

Just completed another round of ‘Agile project management using scrum’ workshop for a team of young brilliant engineers from a leading multinational product company. Their intelligence and creativity was outstanding and inspiring. Thank you very much for giving me an opportunity to work with you for the last four days….Again, you did not answer my question ‘Why do a car with automatic gear shift have a tachometer?’ ….Any answers….