One of the many benefits of agile software development is the ability to continuously improve.
Early and frequent feedback loops allow for the adoption of improvements in the software being built. Sprint retrospectives allow the team to grow and improve the processes around development too.
I like to keep sprint retrospectives focussed and under 30 minutes where possible. Everyone on the team takes turns to contribute without interruptions. In order to make this a reality it's a good idea for the team to come prepared with a couple of talking points, remembering that it's just as important to celebrate the things that are going well as to talk about what needs to change.
The meeting can be broken into three 10 minute sections to facilitate focus. Starting with what went well, moving into what didn’t go well and then finally taking action.
What went well
On even the most challenging of projects there are wins to celebrate. Be sure to take the time to focus on the positive and remember to keep doing the things that are working.
What didn’t go well
Now is the time to focus on what the team wants to change. Keep the comments constructive and ask for examples so that everyone fully understands the nature of the challenge.
Too many times I’ve witnessed a meeting run out of time and this crucial section squeezed in almost as an afterthought. This section is the whole point of your retrospective so give it space.
The meeting facilitator can help the process along by asking each individual to provide their feedback, ensuring everyone takes a turn. Often there will be a comment that is repeated, and in this case a simple +1 is a good way to track the feedback and avoid really cumbersome notes. I prefer the method of asking everyone to take a turn, rather than an open discussion because its easy for one or two voices to dominate in a free-for-all.
More on taking action
- It's not always possible to fix everything, try focussing on 3 key points.
- Hopefully some of the positive feedback will turn into an action to ‘keep on doing…’ which makes solution-finding a breeze!
- Work as a team to find solutions for areas to improve and be sure to assign them to team members for implementation.
- Follow-up is crucial and the Project Manager or Scrum Master can check on the action items after an agreed number of days have passed.
In a sprint 1 retrospective with a project team yesterday I was really blown away to hear that some of the problem areas had been worked through and solved prior to the end of the sprint, thus we could celebrate them as ‘what went well’.
Problem solving doesn’t need to wait for the retrospective meeting, but in cases where it does, it is reassuring to know that the entire team will be working together to fix it.
Sharing the retrospective notes outside the confines of the project team can really help an organisation to grow and evolve. Start by sharing the notes with functional leads and with the Project Management Office if you have one. Continuous improvement can happen at both the micro and macro level.
Maybe some of the actions involve training for individuals, or perhaps they are at the organisational level and require external teams and stakeholders. I see the sprint retrospective as true bottom-up leadership, and a space where all team members have an equal voice in making both the project and general work environment better.