Most of us who are aware of agile principles, the 12th principle says
“At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly”
This is nothing but continuous improvement done at short intervals of time. I consider retrospective is very important. Agile retrospectives focus on right people, collaboratively work together to identify improvements about what has been done so far. In scrum, we call it “Inspect and Adapt”. This may also be called “Kaizen” in Lean principle language. If we look at our life, even in our life we become more effective if we constantly look at our past actions and identify where we did well, what we didn’t do well and improving the areas at different stages of our lives. Aiming improvements in small steps is the key than aiming for big improvements.
In agile we use similar approach and use retrospectives to look back at the previous iteration, discuss what went well and what didn’t. It is always better to know the root of the problem and hence we may spend some time on identify root causes about why the problem/pitfalls occurred. But it is not necessary to always have to identify the root cause. We believe in simplicity and think of small improvement or experiments to try in the upcoming iteration. The ultimate aim of retrospectives is to help change the team’s way of doing (team process).
The Scaled Agile Framework by Dean Lefingwell goes even one step further by classifying the improvements areas as “Quantitative” and “ Qualitative” areas. The quantitative review gathers and reviews any metrics the team is using to measure its performance.(eg: did we meet sprint goal?). The qualitative part discusses the various team practices, and the specific challenges that presented themselves in the course of the last iteration or two. When issues have been identified, root cause analysis is performed and potential corrective actions are discussed and recorded.
Who will participate in retrospectives?
- First part of the meeting, the team can take the inputs from the Product Owners and his people.
- Second part of the meeting where team members meet separately to discuss the improvement areas for the next sprint/iteration.
Time For Retrospectives:
As per the Agile Atlas defined by Scrum Alliance , The recommended time box for the Sprint Review is one hour per week of Sprint duration. The team should take care they don’t spend too long time, ultimately they need to take a call as they are empowered to take decisions.
Ways of capturing the feedback from the teams:
- Team collectively identifying at the end of iteration 1) What went well 2) What didn’t go well 3) What team wants to try in the next iteration
- Team Radar: The team gauge how well they are doing on a variety of measures,such as, engineering practices, team values, or other processes and rate them to a scale of 1 to 4. Then they discuss how to move to Scale 5 on the areas identified. 1 rated as low, 4 rated as high on the scale
- Conceptual – One word to describe the sprint
- SWOT Analysis- Here team identify their strengths(S), Weakness(W), Opportunity(O) and Threats(T)
- Fish Bone : Fishbone is a way to look at root causes. Draw a fishbone diagram and write the problem or issue at the fish’s head and Label the “bones” ofthe fish with categories.
Typical categories are as follows:
- Methods, Machines, Materials, Staffing (formerly known as Manpower)
- Place, Procedure, People, Policies
- Surroundings, Suppliers, Systems, Skills
Agile Retrospectives: Making Good Teams Great by Esther Derby and Diana Larsen is a great resource.
Some tips for holding successful iteration retrospectives:
- Keep the meeting time-boxed to 30 – 60 minutes. Remember, anyhow we do it frequently at the end of each iteration which shall not go beyond 1- 4 weeks and the goal is kept small and ensure continuous improvement steps.
- Pick only one or two things which can be done better next time than addressing all improvement areas. We can have improvement backlog items targeted for the subsequent steps.