Retrospectives are a frequently overlooked aspect of scrum. Perhaps this is because they are “non-functional”, in the sense that they don’t contribute directly to the output of the team. I maintain, however, that good retrospectives are the key to a highly functioning team.
What is a retrospective?
A retrospective is a meeting where the team get to reflect on their current progress and process and decide how they can improve it.
What does it mean to improve progress and process?
It can mean absolutely anything … the team get to decide. Remember that the purpose of scrum is to build a team that can smoothly and effectively deliver business value on a regular basis. Anything which gets the team closer to this goal counts as an improvement.
It’s also important to point out that it is the team themselves which decide how they can improve. People such as managers, IT directors, agile coaches and so on can make suggestions, but the team needs to take ownership of their process. This is what it means for a team to be “self-organising” … an agile term which is bandied around a lot and is often misused. The self-organisation of a scrum team is the main points of retrospectives.
What’s the difference between a good and a bad retrospective?
Retrospectives, like a lot of things in agile, need to be judged on their outputs. A good retrospective will produce improvements that address important issues the team is facing. A poor retrospective will skirt around issues and address unimportant issues.
For instance, suppose a team is consistently releasing buggy software. A good retrospective will attempt to address the bugs, both in terms of fixing outstanding issues as well as attempting the underlying cause of the bugs. A bad retrospective would focus on other incidental issues, e.g. variable names not adhering to the agreed coding standards.
Poor retrospectives can happen for a number of reasons:
- they may be unaware of how well they are meeting business priorities (e.g. they don’t know that their software is buggy)
- the team may be unaware of business priorities (e.g. they may mistakenly think that the bugs have a minor impact)
- the team might not care about business priorities (e.g. they don’t care about their bugs)
- the team may be unwilling to talk about their problems
- the retrospective meeting might get side-tracked into addressing low priority issues
- … and so on
Some of these issues can be addressed by ensuring good communication between the team and the business. Some of these issues can be addressed by being careful with the retrospective meeting and its format. The retrospective meeting can be structured in such a way that it encourages the team to discover, explore and address their big issues.
What’s the format for a retrospective meeting?
There is no single format retrospective meeting, and there is no retrospective format which is best. Retrospectives can take many forms. In fact, the format of retrospectives should be changed from time to time, as this encourages people to think about their situation in new ways. A great resource for ideas about different formats is Agile Retrospectives, by Esther Derby and Diana Larsen. There are many other resources available on the web too.
What would you suggest as a starting point?
Here is a retrospective which I often use for teams that are new to retrospectives. Please do not use this without thinking about it and deciding how it will fit your team.
Some sort of icebreaker activity. For instance, everyone gives one word that for them sums up the sprint. It can be accompanied by explanation or not. Questions are not allowed at this point, since people should be thinking rather than talking.
2. Review previous actions
Look at the actions from the last retrospective. Decide which were completed, perhaps discuss how effective they were and decide which, if any, the team should carry on with.
3. Gathering data
Everyone writes post-it notes to fall into 2 categories - "What went well" and "What went not so well". The team gets 10-15 min to write the notes and then individuals take it in turns to stick them up onto a whiteboard. As they stick up a note they should introduce it to the team "I wrote xxx because I felt that ...". Some questioning is allowed here, but the point is really just to gather information. The use of post-it notes is a great equalizer and prevents dominant characters from dictating the course of the meeting.
4. Extracting insight
The facilitator then looks to group up the post-it notes into topics / themes. For instance, there may be a number that relate to daily standup meetings. Put these in a clump.
5. Decide on actions
The team now decide on actions to address the items that didn't work well. Start with the biggest clumps of post-its, since those are the issues that are causing the most pain. Generally it's not worth trying tackle all issues. When you have 4-8 actions then call time. There should be lots of discussion and brainstorming during this part of the retrospective. All actions should be specific and should have an owner who is prepared to take responsibility to see it implemented during the next sprint. If nobody volunteers to own an action, then throw it away because clearly nobody wants to see it implemented.
Actions which cannot be implemented by the team are not allowed, e.g. “business users must stop changing their mind”. Actions which are vague (e.g. “improve communication”) need to be explored more and made specific.