Following a couple of threads recently on the kanbandev Yahoo! group, I thought I’d try and put down my experiences and thoughts on the subject.
In a timebox-based agile process, such as Scrum or XP, the retrospective typically happens at the end of the iteration, and is one of the items coupled to the iteration cadence. Removing the iteration, and de-coupling all the cadences, forces the question of where the retrospective fits in.
At Yahoo! we found that Stop the Line moments happened spontaneously, and for a while we stopped doing retrospective for a few months. However, after a while, we realised that we were missing something. Stop the Line events are great for immediately solving problems, while the information and context are most fresh. But sometimes we found that some more subtle trends were occurring that a more structured retrospective could help surface and solve. In addition, I think retrospective can help celebrate success, and enable an appreciative enquiry approach to process improvement. So a regular retrospective cadence can add value, especially when tied in with an Operations Review (as described by David Anderson). We also included a retrospective element in our quarterly cadence, where we spent more time looking at the value stream and the bigger picture.
So to summarise, a basic starting point would be:
- Stop the Line for special cause problems
- Monthly Retrospectives with Operations Reviews for common cause problems
- Quarterly Value Stream Mapping to reassess the whole value stream
Hi Karl, I read this post a while back. Reading it again the thoughts I had then still seem relevant so here they are. I would be interested to know what you think.
It seems to me that generally many of our problems result from simply not being very good at remembering or capturing what happened in the past in any meaningful way. To create and retain any knowledge we need a suitable framework into which we can place related information. I feel that a subtle benefit of looking at an iteration in retrospect is that it gives you a context in which to reflect and compare. A history of regular iterations reaching back over many months creates such a ‘knowledge structure’ and helps everyone to identify and reason about the short and longer term trends in our behaviour and performance. Without it, will it not be harder to learn lessons from our past?
I would emphasise your point by saying that making the most of every opportunity to celebrating success is tremendously important. In the longer term, iterations help to the team to look back and visualise how far they have come and what has been achieved. Something else that I feel is important is to recognise that human beings can find months of relentless process driven development very fatiguing. We found that we settled into a routine of holding the Sprint Review on a Wednesday afternoon the Retrospective on Thursday morning and the Planning Meeting for the next iteration on the Friday morning. This time was used to clarify the new Stories arising from the Sprint Review and the Retrospective but it also gave the team a well deserved break from the process and the opportunity to explore ideas that they had had during the iteration, investigate potentially useful tools and technology or make improvements to our development platform. This simple measure had a very positive effect on the team. It also seemed to create a sense of anticipation regarding the next iteration. I would be interested in hearing about your experiences of team fatigue with Kanban (or Scrum) for that matter.
Regards,
Adam
[…] many people over the years have noted, celebrating success in teams is important, and a natural place to […]
[…] a comment » As many people over the years have noted, celebrating success in teams is important, and a natural place to […]