Making your retrospectives more effective
I just noticed that Bob Payne has posted an interview with Esther Derby on the Agile Toolkit Podcast. This interview took place at the end of the Agile 2008 Conference and covered a number of topics. The topic that I found most interesting and timely was that of retrospectives, and ways to make them actually accomplish something instead of just talking about the same things repeatedly.I wrote down a couple of notes while listening to it:
- Put your actions to improve on story cards and add them to the iteration backlog.
I wouldn’t want to give them story points (I also don’t like to give story points for engineering tasks), but this is a way to keep them visible and get them done. It also requires that they be actions, rather than just wishes.
- Ask people, not what is the biggest or most important problem, but what do they have the energy to improve.
The biggest problem is often too daunting to tackle. That’s why it seems the biggest. Instead, pick something that seems important, but doable.
This reminds me of the way I often approach the refactoring of large or old legacy code bases. Often I find that I can’t make any headway on what seems like the most fundamental problem with the code. When that happens, I start chipping away at smaller issues, isolating problem areas into relatively distinct chunks. Ultimately, when enough of these smaller issues have been tackled, the big unapproachable refactoring no longer looks so big.
There’s lots more there than what I’ve mentioned here. I recommend that you go give it a listen.