Good agile teams rely on retrospectives to maintain their edge. Not-so-good agile teams often ignore retrospectives. (Come to think of it, the same is true of traditional software process teams.)
I don’t know about you, but I find that intriguing. Retrospectives attempt to answer a few simple questions and use the answers to improve the team.
- What did we do well that we want to incorporate into our future efforts?
- What did we not do so well and what did we learn from the experience?
- What should we do differently next time even if only to try a different approach?
- What still challenges or puzzles us and how can we better understand it?
Simple questions with complex answers. Good agile teams keep asking these questions — after every sprint. They strive to get better and better.
So why don’t all teams conduct retrospectives? Don’t they all want to improve?
Yes, but…incorporating retrospectives into the software development cycle implies an admission that the process you’re following needs improvement. Many traditional command-and-control managers have trouble with that. They want to define a rigorous process and stick to it.
The other hindrance is that conducting a good retrospective is tough. The team needs to be open, honest and non-confrontational. It’s easy to fall into the trap of blaming someone for what went wrong. As soon as that happens, everyone retrenches and gets defensive. The meeting is over.
Want to be a better agile software development team? Include retrospectives at the end of every iteration/sprint.
Try asking just two or three of the questions above at first — until you get comfortable with the process. Limit yourself to improving two or three issues at any given time. Don’t take on too much.
Retrospectives really work. Give them a try and be more agile.