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