Building high performance
Retrospectives are one of the most powerful parts of Scrum, and something that can easily be applied in everyday life as well. I believe they can deliver huge value to teams and organisations, but many people don’t understand how to maximise the value they deliver. There is a simple framework from the wonderful Agile Retrospectives book by Diana Larsen and Esther Derby, that solves these problems, and that is what I’d like to discuss today.
Continuous improvement (Kaizen) is something we could probably all do with a little of, but achieving it is no easy matter. Many teams that I’ve observed use just one type of retrospective – ‘What went well/Not so well/Any Changes’; this can be fine from time to time, but my experience suggests if you keep trying the same thing, you will keep getting the same results (Albert Einsteins definition of insanity}.
If you mix up your retrospective types you will cause you teams to think more and begin to elicit different information. You will start to expose some other areas that previously lay hidden under the surface. Certainly once you are working with a high performing team you need to get to these corner areas to be able to continuously improve.
If you can understand this retrospective framework, and the value that each stage delivers, you can begin to think of your own ideas to try out with your own teams that will help them continuously improve, and lead to you becoming a better Scrum Master as well.
1) Setting the stage
The aim here is to create a good, safe environment to get everyone participating in the retrospective. Getting people involved early makes them far more likely to contribute later on, and will produce a much more valuable experience for all involved.
There are a number of activities you can try here, the key is creating that great environment to get everyone involved. Here is an example you might like to try:
Picture the mood – ask everyone to draw a summary of the previous sprint (with a timebox of course” }. Some examples I’ve seen include boats crashing into icebergs and rocketships taking off. Following on from the drawing, get a very brief explanation (1-2 sentences” } on the mood they are getting across.
Other common types include the ‘check in‘ where you ask a simple question (eg. what are you hoping to get from this retrospective” } in order to get people to contribute early on.
2) Gather data
Once you’ve created the great mood, it’s time to dig into the details. You want to elicit as much information from the group as possible, which you will shortly process into action points. There is no such thing as bad information here. Get ideas from everyone so you can truly understand the mood of the team.
You can try a number of different methods for gathering data – even a simple brainstorm can works wonders (one idea per sticky!” }.
Another method I enjoy is the timeline/moodline. Plot out a timeline of your previous sprint on the x-axis, and the mood (both positive and negative” } on the y-axis. You can map out your feelings over the previous sprint, and see the different things that have been affecting the team over this time period. A useful tip here: take notes of the key points people are mentioning (again, one per sticky!” } or ask them to mark the key points on their timeline before explaining them to the group.
3) Generate insights
Once you’ve gathered the essential details, it’s time to figure out what this information means. One of the teams I’ve worked with would frequently list environment as one of their big painpoints. What we realised after some discussion was that the problem was twofold; uncomfortable seats (easily resolved with a quick online shopping session” }, and a kitten in the office – which became less of a problem as it grew up.
You want to establish patterns and figure out trends in this stage. If there is something that is having an undue influence on the team (pesky co-workers or missing product owners, for example” } you want to work out exactly what it is. Only if you recognise there is a problem can you begin to resolve it.
One of the simplest ways to do this is simply grouping the ideas that you came up with in the previous step, which also helps you observe the larger patterns at work.
4) Decide what to do
Now that you have figured out what the problems are you have to do something about them so they don’t cause any issues or delays again in the future. Simple idea, right?
Rather than creating a laundry list of ideas, it’s best to focus on the big wins, however you define that. Some teams go for easy changes, and some go for big impact. The key is picking two or three actions (that you can complete within one sprint – if it’s bigger than one sprint, break it down into smaller, bite sized pieces” }, and making sure they happen.
Using the ‘What, Who, When’ framework makes this pretty simple. You know what is going to happen, who is going to be responsible for making it happen, and when it is going to be done by. This is a volunteer process (we are self-managing after all!” }, and you don’t have to punish people if things are done. Sometimes you may realise that the things that didn’t happen weren’t really so important after all.
5) Closing the retrospective
Now that we’ve achieved all of these fantastic insights and come up with steps to resolve our problems, we want to wrap things up. There are several things you may discuss here: what went well in the retrospective (maybe you tried a new type” }, or any changes people might like to make.
‘Appreciations’ is another good type to close with – just mentioning the things you appreciate about other members of the team. This is all part of maintaining the magic ratio to good relationships.
Whatever method you go with, you should thank the team members for their time. It’s always great when people come along and make positive contributions about improving the team, project and business.
Hopefully you are all convinced of the value of continuous improvement and desperate for some further reading. Here are some resources you should check out:
- For those of you in Shanghai, come along to our Scrum User Group and share your ideas with an enthusiastic Scrum community
- InfoQ has some great tips and tricks on running retrospectives
- There is an entire wiki dedicated to running retrospectives at retrospectiveswiki.org
- And don’t forget the Agile Retrospectives book, it simply can’t be beat