Our Kanban journey began early in 2010 when we decided that we would build a product in the Kanban space that would address some of the basic issues we saw our prospects face in adoption of Agile methods such as Scrum and XP within their organizations that were historically used to doing waterfall or iterative or some hybrid Agile method that combined more than one type of processes.
While the presence of established competitors was a strong reason to look beyond the ‘popular’ Agile methods, we also felt a strong appeal for Kanban existed because of its focus on 3 key fundamentals:
- Evolutionary change
- Improvement of existing processes
- Engineering rather than Management processes
We have seen numerous organizations and teams take on large (revolutionary) process improvement initiatives – be it 6-Sigma or CMMi or even Agile. We have seen them become consumed with “the task of process improvement” over and over again. As a result, while there is improvement in the interim, in terms of consistency with which a process is followed in the team or the organization, the overall magnitude in terms of the time, effort and cost, of making the transition becomes huge and management begins to question the benefits! Kanban, with its promise of evolutionary change, with one stroke, takes care of this fundamental issue. It allows teams to take on only those aspects of change that they can comfortably handle.
Secondly, with an evolutionary approach, Kanban necessarily tackles current processes in an organization and helps improve them, rather than force a range of new processes on it. This is fundamental to understanding how Kanban can be applied not just to traditional software processes – but also to popular Agile processes such as Scrum and indeed, to non-software processes – bet they within IT or in general business functions such as Sales or Marketing or Legal! So besides being attractive to software teams, their pull for non-software teams, presented us with a much bigger opportunity, which we are already starting to see materialize!
However, the one aspect of Kanban that excites more than others is that it forces teams to focus on the “engineering” or the “delivery” processes rather than the “management” processes. This is where, I feel, Kanban truly distinguishes itself from its ‘competitors’, if one may terms them as that. Through the use of statistical control charts, Kanban helps teams identify their normal performance and their deviations from the normal – the outliers. Rather than advise teams to simply do better documentation or better management or better reviews, it encourages teams to do better root-cause analysis – and attack root causes for poor performance – be that better or more specific testing, better development or design practices or better collaboration and requirements elicitation from customers. And in doing so, I believe Kanban shows itself to be far more effective than any other framework to start making incremental, lasting improvements in the final quality of the product or service being delivered.
Far too often, after initial gains have been realized through ‘traditional’ Process Improvement initiatives, teams start to question the extra overhead of ‘following process’ and wonder ‘what is in it for them’. With Kanban, these teams are much more likely to realize lasting gains through evolutionary, (incremental) improvements to basic existing delivery/ engineering processes and measuring their own performance in a much more meaningful manner.