Friday, March 20, 2009

Kanban & Retrospectives

There’s been some chatter on the discussion lists and Twitterverse recently on the topic of whether Kanban practitioners view Retrospectives as waste (in Lean Thinking terms).

Heck, Kanban has already cocked a snoot at Agile Holy Grails such as time-boxed iterations, and planning and estimation, so why not retrospectives as well?

So the record needs to be set straight on this. Some clarity and signal needs introduced amongst the noise.

Some mature Kanban teams did drop the use of retrospectives. No one told them to do it. They just did. Retrospectives were not adding value in their lives and hence were seen as a wasteful activity that could be eliminated. How did this come about? Well, firstly the management (that’d be me) had encouraged a culture of continuous improvement and a focus on objective quantitative management. The organization was holding a monthly operations review to reflect on performance. So, there was already a monthly retrospective opportunity built in to the working lives of team members. Secondly, mature kanban teams were capable of releasing (or integrating in the case of major projects) every couple of weeks or so, with a negligible defect count. Things went very smoothly so there wasn’t much to discuss. And thirdly and most importantly, the institutionalization of a culture of continuous improvement had created what was known as the “after meeting”, when folks huddled together after the morning standup meeting to discuss issues that often led to improvement opportunities. These spontaneous meetings were equivalent to what in manufacturing is referred to as a spontaneous quality circle. This empowered self-organizing type of self-affiliating quality/improvement group has only been seen in some of the most Lean of companies. Kanban seems to facilitate it in software development.

So, to summarize… teams that were part of an organization that gathered objective data, held a monthly operations review (and walked the walk, not just talked the talk) on organizational performance, and teams that delivered with a mature regularity, reliably and predictably, and teams where the culture had matured sufficiently that spontaneous quality circles were forming after daily standup meetings, found iteration (or release) retrospectives to be of little added-value and dropped them from the process.

Teams that did not mature to this level tended to keep retrospectives as part of their process. While the very mature teams would still hold a retrospective when something extraordinary happened - such as a botched release. In this case, retrospectives were being used in an event driven manner to perform casual analysis and resolution.

So it’s horses for courses. Kanban can enable a team to reach a level of maturity where they may choose to eliminate retrospectives (or not.) It’s a choice! Every situation will be unique. The important thing is not to see elimination of retrospectives as wrong or bad or “not agile.” Equally, don’t rush in and eliminate retrospectives. Don’t proscribe retrospectives. Let the team make its own decision when it is ready and embrace the evolution of process that comes with continuous improvement. Technorati tag: David+Anderson, Agile+Management, Agile, Lean, kanban, Software+Engineering, Project+Management