• All
  • Agile
  • Agile Adoption
  • Agile Organisations
  • Coaching
  • JAFAC
  • KanbanFor1
  • Product Development
  • Product Owner
  • Retrospectives
  • Scrum Master
  • Self-Selection
  • User stories
Read More

Even done is never done

A “done” definition in an Agile project is a statement that the team use to measure whether they’ve met all of the requirements for completing a userstory / feature (and in some cases completing an iteration or release). Done is one of the major shifts from doing Agile to being Agile.

So, what is “done”? Is it the quality mantra for the team? Is it the way we communicate completeness to the customer? Is it a process for eliminating waste? Is it about how we would like to work to bring about that “potentially shippable” product? It’s all of this but crucially belongs to the team, is created by the team, and is used as a measure of success. A “done” definition may look similar between teams but is never the same.

Read More

A 5-why root cause analysis retrospective

The idea

For quite a while I have been waiting for an opportunity to try a 5-why root cause analysis in a sprint retrospective. 

The 5-why analysis has its origins within Toyota and lean manufacturing and is used to find the root cause of a problem through identifying a symptom and then repeating the question “Why?” five times. General wisdom and experience state that the nature of a problem and its solution usually become clear after 5 iterations of asking “Why?”.

Here’s an example from wikipedia: 

Problem: My car won’t start.

  • Why? – The battery is dead.
  • Why? – The alternator is not functioning.
  • Why? – The alternator belt has broken.
  • Why? – The alternator belt was well beyond its useful service life and has never been replaced.
  • Why? – I have not been maintaining my car according to the recommended service schedule.

Solution: I will start maintaining my car according to the recommended service schedule.

The plan

I have found 5-why root cause analysis very useful in the past but had never tried it with a group of people or a software development team. 

I “conspired” with our very talented Scrum Master and the plan was to share data from previous sprints, analyse the data as a team and see if we could identify a problem. If so, we would suggest a 5-why analysis to see whether it would point us towards a root cause and a solution.

The execution

1) We started by presenting velocity data:

The chart shows our planned (blue) and achieved (red) velocity over the last 10 sprints.