RESTROSPECTIVE - Agile software development “retrospectives” …

RESTROSPECTIVE - Agile software development “retrospectives” …

Definition:

“The techniques of communication and organization demand from the manager as much thought and as much experienced competence as the software technology itself”

Tim Mackinnon, Agile Coach at ThoughtWorks

5 Why's applied in a real retrospective

One particular problem was that planned Features were being descoped from each iteration as the last day approached. Here's the analysis:

Failure: Consistently fail to deliver all the Features to the Product Owner, that are planned during the iteration planning meeting.

• Why are Features being descoped towards the end of each iteration and not being delivered to the Product Owner? Because we run out of time.
• Why do you run out of time? Because most of the Features take longer than we estimated.
• Why do most of the Features take longer than your estimates? Because most of our estimates are bad.
• Why are most of your estimates bad? Because we don't fully understand enough of the details of a user story when we estimate. And although we triangulate to completed user stories, the task effort recorded for those completed stories differs significantly even though they have the same story points. (The tracking data showed that Features with 5 Technical features had tasks with a total recorded effort between 2 and 4 ideal days). [2 problems identified here]
• Why don't you fully understand enough of the details of a user story? Because we're not collaborating effectively with the customer during iteration planning.
• Why aren't you collaborating effectively with the customer during iteration planning? Because most of the story cards are a mess of notes, so we get the customer to read them to us. [Delta Deviation cause identified]
• Why is the tolerance on recorded effort so wide for Features with the same story point value? Because we're not revising the story point estimates.
• Why aren't you revising story point estimates? Because we focus on tracking the tasks in ideal days. [Another Delta Deviation identified]

To address the 2 Delta Deviations, the following fixes were applied in the next iteration:

• Encourage collaboration by using just a Feature name on the card (a technique suggested to Brian Marick by Rachel Davies). The customer rewrote the remaining Feature on the cards.
• At the end of the iteration planning meeting, each team member verbally state their commitment to deliver the planned Features to the product owner and the other team members. This made the developers spend sufficient time with the customer, beforehand, discussing the details of the Features to ensure they understood what was required before providing estimates.
• Start using ideal pair hours to estimate Features and record velocity rather than story points. It seemed nobody really liked story points. Since there was some confusion about what they really were or meant, the developers were never entirely confident about their estimates. The customer was happy to see time come back, although the concept of ideal time had to be explained.
• Stop tracking tasks and start tracking running tests features.
• As part of the collaboration between the customer and the developers, split the Features being planned for the iteration so that they would take between 1and 2 days to complete. Smaller units of work are easier to estimate.