Some benefits of using this Lean technique are:
- Helps identify root cause of a problem
- Determine the relationship between different root causes of a problem
- Very simple to use without any statistical analysis
- Very useful when problems involve human factors or interactions
Asking 5 times WHY generally leads you to a root cause. In some cases you may reach in fewer iterations and in some it may take more than 5.
Now let’s apply this technique to our problem on hand.
Problem: Team failed in their sprint as they were not able to complete all the work committed.
Let’s see how Team A applies this to identify the root cause:
- Why did Sprint fail?
- Requirements were not clear. Each team member had different views of the requirement when they got to the implementation.
- Why did team have different views?
- Team were not able to clarify the requirements with product owner
- Why this was not possible?
- Because product owner was not available.
- Why Product Owner was not accessible?
- Product Owner is too busy with multiple teams and other responsibilities. Hence he is running very low on bandwidth.
Here you have reached to a root cause in 4th iteration. Solution in this case could be:
- To balance product owner load, so that he spends enough time with the team OR
- If your budget allows you to have a dedicated product owner, then it’s good. If not can someone on the team step-up and take more responsibilities to help product owner to groom and write acceptance criteria
- or you may come up with something else…..
Each problem can have multiple root causes and multiple solutions depending upon the situation you are in. Now let’s apply same technique to a different team which is also facing same problem.
Let’s see how Team B applies this to identify the root cause:
- Why did Sprint fail?
- Because team did not have enough time to test every feature developed
- Why did team have less time to test?
- Because team delivered most of the stories in last 2 days
- Why this was possible?
- Each team member was working on a different story
- Why each member was on different story?
- Because team thought this is the best way to approach implementation to finish all of them
- Why team thought this is the best approach?
- Each story was big enough to keep developer busy for full sprint
Solution in this case could be:
- Team did not try to break big stories to smaller ones. They could have used right techniques to split stories
- Multiple team members could have worked on one story and finished it earlier to give to testing
- more….
Asking WHY repeatedly will lead to a root cause. Sprint retrospective could be a good place where you can try this after you identified your list of issues.
Team can also benefit by applying this 5 Whys technique when they are too busy from sprints after sprints and are loosing bigger picture. You can check my earlier article on Lack of Big Picture Leads to Blind Man Product
Asking product owner why this user story is in this sprint leads to discussion on release goal–>again WHY leads to Product road map–> again why to Product vision –> and then to Business vision. Now team gets complete bigger picture of their work.
Identifying root cause is extremely important to agile teams which breathe Inspect and Adapt spirit.
Have you tried this technique? Do share your story.
5-whys is a lean technique which I consider a very good approach in identifying articulation and language which business understands. That happens with technical debt also. Developers are not able to articulate the problem which business understands… 5 whys or more can be the way to reach towards business value.
Agree Shrikant. Teams should use this technique effectively till they reach root cause. Few times team leave in-between and then it will give a false notion of root cause.
I’ve seen that most of the times Sprint failed due to the following reason:
1. Poorly written user stories – The user stories were incomplete and lacked substance in the acceptance criteria.
2. No Spikes for complex stories due to time-crunch – Team was over-optimistic in estimation and pulled a story in Sprint without doing any research in the area that was unknown to them (spike).
3. Having a team of mediocre people or lack of cross-function members in the team
4. Communication barriers – especially with the remote/distributed teams and bureaucracy
5. Last but not the least – Development manager acting as Scrum Master
Hi AVIENAASH – what a great article and these items hit the spot. Here’s the dilemma I have…
The small software dev company I work for is a train wreck. They are trying to combine waterfall with Agile whenever one or the other is convenient for them (e.g. sloppy work is passed off as “it’s Agile – we’ll fix it in the next iteration”).
My question to you is this… Can you combine waterfall and agile, or are they like oil and water? My opinion is that they are two completely different approaches/disciplines and if anything, trying to convenient use principles of one contradicts principles of the other. What are your thoughts?
Thanks Eric. I’m glad you liked it. Achieving agility within an organisation involves huge change in mindset. Agile if you dwell more is not just a methodology, it is a culture, thinking and newer approach to product development. It involves changes at all levels of the organisation from HR, sales, project teams and senior management etc. Hence this is called agile transformation.
Using agile as per convenience or passing sloppy work as “its agile” is not agile, it’s AD-HOC. Underlying principles in case of waterfall and agile is very different. Hence it does not make sense to compare them at all.
Your team might need some good trainings and coaching to fix this.
Avie
The major reasons of failures of sprints in my team is as follows:
1. Under estimation of an ambiguous task.
2. Ad hoc operational tasks taken after sprint planning. It reduces the effective developer’s time.
3. Unplanned meetings and discussions takes significant amount of time.