Rob's Guide to Effective Retrospectives
Retrospective facilitation is a skill
I'm continually surprised by the number of people I speak to who facilitate retrospectives, but haven't read Derby and Larson's Agile Retrospectives: Making good Teams Great (or similar material on effective facilitation, see External Resources). Making sure the meeting is not being driven by whoever shouts the loudest or ending up as a long ineffectual rambling debate takes thought and practice. The first three chapters of Derby and Larson's book are essential reading.
Rotate the facilitator role
Are you finding your team aren't particularly enthusiastic or engaged in your retrospectives? One common reason I see for this is it being one person's job (typically a scrum master or project manager) to facilitate/lead them. This can result in bias towards one person's point of view and also prevent a team from feeling empowered to solve their own problems. Whilst it may be one person's job to make sure they happen, that doesn't (and shouldn'tt) mean they also have to run every retrospective too.
Instead try and get everyone to take turns facilitating. Not only does this ensure no one feels retrospectives are being driven by one person's agenda, there are many other side benefits, including:
- Learning how to facilitate is great for developing communication skills and generally how to have effective meetings.
- The burden of planning retrospectives is shared across multiple people.
- Retrospectives are less likely to become dull or repetitive.
Get someone outside of the team to facilitate
Really easy to do if you have more than one team - ask for someone from another team to facilitate your retrospective and when it's their turn return the favour. This is a great technique to avoid the risk of facilitator bias (face it, we're all biased whether we believe it or not!) and even better has the wonderful side-effect of being a great way to cross-pollinate ideas between teams.
Achievable actions and owners for each action
A common failing with retrospectives is either not taking actions away or the actions not being completed. My first tip here is make your actions small, really small. Big vague goals like "write more unit tests" are pointless. A great retrospective to encourage small achievable actions is the Plan of Action retrospective.
Once you have your achievable actions make sure someone is responsible for each and every one you choose to take away. This doesn't have to be the person who is going to do the work, just the person who is responsible for making sure it happens before the next retrospective.
Track the actions as you would with the rest of the activity in your team in your favourite work tracking tool
Start each retrospective by going through the actions from the previous one
Before doing anything else, begin the retrospective by going through the actions from the previous retrospective have been completed. If not, why not? Time box this to 5 minutes.
If the team took 5 actions but completed none, agree to take fewer actions away from this retrospective. Once the team has got better at completing the actions they've committed to then maybe they can increase the amount of actions they take away.
Who is Rob?
I'm Rob Bowley, the person who set up this wiki.