I was recently reading a post on InfoQ, "Frequent Retrospectives Accelerate Learning and Improvement". As it's title suggests, the key messages in the article is about having frequent retrospectives to aid in the learning and improvement process.
When we adopted XP (eXtreme Programming) we undertook to have a retrospective at the beginning of each development iteration, preceding the planning game. With weekly iterations, we have a chance to reflect on the previous weeks pluses and to formulate some changes/improvements (deltas) identified from the week.
In the article the author made the following comment,
In fact, looking back is only half of the retrospective pattern. Reflection is not learning. To bring about learning and improvement, it is necessary to identify areas for improve and explicitly document a brief action plan for which the team becomes accountable.
We regularly come up with a number of delta's and then choose the highest priority ones to be tackled during the next iteration. We even assign someone to "own" the task. So we are on track to learn and improve however what we struggle with is when we have too many delta's to be done in a single iteration.
Currently we review the previous retrospective deltas at the beginning of the retrospective and copy any un-addressed ones to this retrospective's delta list. The problem with this is that the list is getting bigger.
I'm not really sure what the solution to this is yet so if you have an suggestions I'd love to hear them. For now, we'll continue to tackle the most pressing or productive delta's and keep reviewing the previous one.
Pingback: Hamstaa! » Blame has no place in retrospectives