Retrospective Deltas
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.
June 18th, 2007 at 1:19 pm
[...] Management Reading List Retrospective Deltas [...]
June 18th, 2007 at 8:02 pm
Is the list really getting bigger? I think we do a fair job of managing the size of the list. If we feel a delta from last week is still important/relevant, it gets added to this week’s deltas. If it isn’t important (no one thinks it delivers enough value) it gets dropped.
We review the deltas while we are prioritizing them and sometimes (from an engineering point of view) we identify them as something to be added to the slack page. Now that is something that is growing faster than we are removing items from. But since it isn’t seen as important as the deltas, I’m not too concerned with its size (which may be the size you are commenting on here?).
Where I am concerned is what I perceive to be a lack of commitment from the team on owning deltas and following through on doing something positive about the deltas. What the author of the article identifies as accountability. As a team, we still have lots of room to learn and grow in this respect.
This also highlights to me an issue with retrospectives. We seem to struggle a bit with remembering what happened in the last week for the retrospectives. We’ve talked about moving to a two week iteration which implies bi-weekly retrospectives. I see a potential problem here that we will need to address.