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.
Mahesh Singh
Co-founder, Sr. VP – Product
