29 April 2013
Not respecting the prime directive
This is not a blame game ceremony. We are not looking for a scapegoat. We are looking for ways to improve our collaboration, not destroy it further by pointing fingers. The only reason why it may matter who did it, is that they might have a deeper understanding of why it went wrong. It’s up to the team to work together to discover ways to avoid this bad situation in the future. We must start from the simple agreement that everyone did the best they could, given the circumstances.
The wall of complaints
The retrospective is the most effective tool for continuous improvement in the agile world. It can only be this effective if we don’t let ourselves be sucked into a vortex of self-pity and whining. If you really want to bitch about all the things that are going wrong, you can do that over lunch or beers. The goal of the retrospective is that the team figures out how to improve their current system. You look into things that went unexpectedly well and try to find ways to reproduce this. You also go into things that went wrong and try to come up with ways of avoiding these situations. A couple of examples for doing this are by analyzing patterns in unplanned work, by investigating the amount of rework and by digging into the impediments that arose during the sprint.
Trying to address every good and bad thing that happened
It’s important to gather data about all the things that went unexpectedly good as well as bad, but it’s no use digging into the nitty gritty details of each and every one of them. We group items together to form themes and then pick one of those themes to explore further. This way we can ensure that we can at least come up with some ways of improving this one thing, instead of talking about all of them but not reaching any real actions on a single one of them. If you still have time after handling that one theme, you can continue to the next one. Preferably, you limit the amount of improvement actions to be found to 3 for a big team and adjust downwards for smaller teams.
Only focusing on actions for things that happen outside of the team’s circle of influence
It’s easy to come up with things other people can improve. If you’re not sure try to think about how many times this last week you said something like this to your partner: “hey honey, why can’t you just…?” or “Wouldn’t it make more sense if did this instead of that?” If something comes up that is outside of the team’s circle of influence, this will be parked for the time being and taken up by the scrum master later. We should really focus on what the team can do to improve their system, both for themselves as for everyone they are collaborating with. It’s perfectly possible that the condition of the chairs is so bad that it’s causing a drop in team morale, so the scrum master can take this up with HR. But what we are really looking for in the retrospective is how the team can increase the quality of the delivered features for instance.
No commitment on improvement actions
What’s the use of spending time to discuss improvement actions if nobody is willing to take them up? Right, none. So just agreeing on one to three actions to take is not enough. We, as a team, have a responsibility to take in improving our own system. So it’s our duty to make sure these actions are carried out during the next sprint.
