Kanban – the alternative path to agility
“Is Kanban an Agile Method?” is a perennial question that comes up in our training classes. It ought to be an irrelevant question. Who cares whether Kanban is Agile or not? It shouldn’t matter. What should matter is whether Kanban helps business improve their capabilities and customer satisfaction? Whether Kanban improves the economic and sociological outcomes for those adopting it? The answer to these questions is irrefutably, “yes, it does” and there is lots of reported, empirical evidence, much of it documented in the archives of the Lean Kanban conferences over the past 4 years. So why should it matter whether is Kanban is Agile or not? Meanwhile, an assessment of the question doesn’t result in a simple binary answer or “yes” or “no”. The picture isn’t black or white but answers come in various shades of grey. We prefer to position Kanban as “an alternative path to agility.” Read on to learn why…
An Alternative to Failing Agile Methods
Kanban was, as I described on Wednesday, developed as a reaction to resistance to adoption of Agile methods at larger scale. The idea that Kanban replaced Agile methods or was somehow better than Agile was hugely threatening to some in the Agile community as Kanban came to noteriety in 2007 and early 2008. Kanban abandons a number of practices that many agilists hold to be core to their belief system. Kanban does not use fixed timebox batch delivery (or “iterations” as they are incorrectly called in Agile literature.) Timeboxed increments are actually not described in the Agile Manifesto but they were core to almost all first generation Agile methods. As most people evaluate practices without thinking deeply about underlying principles or values, they had come to associate “iterations” as a core Agile practice. After presenting Kanban at the March 2008 QCon in London, a number of European leaders of the Agile movement, including Rachel Davies approached me as I came off stage. Rachel’s comment was that “much of what you presented today will scare the daylights out of Agile community.”
Several early Kanban implementations were done with organizations using a traditional SDLC and project management approach. These organizations hadn’t abandoned Agile method adoption, they had either never considered it or dismissed Agile as something unsuitable for them. Kanban was introduced as a way of improving their agility without the large scale change and inevitable resistance that would come with a switch to Agile. These early example, allowed leading Agilists and winners of the Agile Alliance’s Gordon Pask Award to label Kanban as “not Agile” or “Waterfall.” This suited the community who wanted to reject it as the Agile tribe felt attacked by something that was underpinned by the notion that large scale adoption (of Agile) was prone to failure.
Over time, thoughtful people, including most, but not all, of the Gordon Pask Award winners have come to understand what is really happening with Kanban. Kanban is something you do to an existing process. It is a method for catalyzing changes in processes. It isn’t a software development or project management process in itself. Hence, labeling it “waterfall” or otherwise is wrong.
The Agile Alliance has settled for diminishing Kanban to “Kanban Board – an Agile practice.” This entirely wrong definition of Kanban suits the Agile tribe’s need to embrace Kanban in a non-threatening fashion. It is, however, completely in denial of the fact that Kanban is named for its use of virtual kanban systems and visual boards are, in fact, optional, and early implementations did not use a visual board at all. The fact that the Agile Alliance has refused to correct this mistake despite repeated requests to do so, is reprehensible and shows that as an organization it remains ethically challenged. The Agile Alliance prefers to mislead the public about Kanban rather than face up to the fact that large scale adoption of its methods meet with resistance and are prone to failure.
Kanban in the Marketplace
The question of whether Kanban is Agile or not has become increasingly important in the marketplace. Larger firms and governments have decided to “go Agile.” These decisions seem to be based mostly in superstition. No one appears to be measuring whether or not it is doing any good. Buyers seem to have lost focus on outcomes and attend entirely to practice adoption. Measurement is focused on adoption of Agile practices rather what really matters – is our business improving?
Given that we know that Kanban really does help businesses improve, many practitioners of Kanban around the world would prefer that corporations and public sector organizations did actually choose Kanban as part of a move toward Agile. Hence, getting Kanban accepted as an Agile method is important economically for both the sellers and the buyers.
So, is Kanban Agile or not?
If we were to assess Kanban against the Agile Manifesto, we would conclude that Kanban’s deferred commitment is aligned with “responding to change over following a plan” but the other three statements of the manifesto are largely orthogonal concerns to the implementation and use of the Kanban Method.
In my 2008 Agile Conference main stage talk, and many subsequent appearances, I have sought to interpret the Agile movement in a way that resonates with senior executives, by defining Agile principles as: make progress with imperfect information; build a high trust culture; treat work-in-progress as a liability rather than an asset and focus on reducing lead times; foster a craftsmanship ethic and a focus on quality and pride of workmanship. If we use this set of criteria we would say that Kanban directly enables two of the four and is agnostic to the other two, namely, making progress with imperfect information, and fostering a craftsmanship ethic.
The earliest book directly associated with the Agile movement is Jim Highsmith’s Adaptive Software Development. If there was something that all first generation Agile methods had in common, it was that they were capable of adapting to changing requirements. Kent Beck asked us to “embrace change” with the sub-title of his book on Extreme Programming. Agile methods enabled us to make progress with imperfect information and adapt as new information arrived.
Kanban, on the other hand, is a method to enable an adaptive organization. Kanban is explicitly focused on evolving the organizations workflows and processes. So it fits the adaptive mold that early Agile pioneers were pursuing but it isn’t focused on adapting to changing requirements, but rather adapting to changing business conditions, market risks and levels of service demand.
Defining Agility
Recently, I’ve taken to defining business agility by asking: how often can a service-delivery organization interact with its customers to make selection and prioritization decisions about what to work on next?; how quickly can the work be completed from making a commitment to do it?; and how often can new completed work be delivered and operational? These are the three cadences we describe in Kanban literature: of queue replenishment; lead time; and delivery. In first-generation Agile methods these are all coupled together with the fixed timebox of incremental delivery. It is becoming evident that perhaps 95% of businesses benefit from decoupling the rhythms of work selection, lead time, and delivery. When we evaluate business agility by how frequently can we make decisions and how quicly can we turn that decision into reality, then Kanban is shown to be a strong enabler of business agility – stronger than first generation Agile methods.
Kanban – a 2nd Generation Agile Method
So Kanban is a method for organizational adaptation and improved business agility. Given this, I think Alan Shalloway’s assessment that Kanban is a “2nd Generation Agile Method” is justifiable and appropriate. Meanwhile, we will be marketing Kanban as an “alternative path to agility.” We want to emphasize Kanban’s roots as a reaction to the resistance to and failure of large scale Agile adoptions. Challenged large scale Agile adoptions continue to be the “elephant in the Agile room.” Perhaps 50% of people attending Kanban training state there reason for being there is to look for an alternative to their challenged and troublesome attempts with Agile methods. Kanban is a different approach based on a different philosophy for introduction. Kanban takes a management and cultural approach to create evolutionary change and gradually improvement of business agility. It discards the notion of a process-centric approach and the adoption of a prescribed or designed process definition. Kanban doesn’t require a transition initiative that may be prone to failure. Kanban replaces managed transition with with a kaizen culture.
For this reason Kanban remains hugely threatening to those who make a living from Agile consulting. Kanban challenges the business model of most firms offering to sell you Agile. Kanban is the secret that the Agile community doesn’t want you to know about! They would prefer you continued to think it’s just the practice of hanging a board on your wall!
The Kanban Method was conceived as an alternative path to agility – as a means to improve responsiveness and adaptability without any significant revolution or reorganization in your way or working or political structure of your business. Lean Kanban University has recently introduced a series of training classes developed and evolved from older, tried and tested curriculum to ease adoption of Kanban and communicate the full scope and scale of what is possible when you fully embrace Kanban as a way to manage your modern professional services business.
This table shows The Kanban Method and the alternative path to agility is a single graphic. From left to right you progress from basic introductory shallow kanban boards to full enterprise scale, Enterprise Services Planning.
In September our new training facility, the Anderson School of Management opens in Seattle conveniently located near Seattle Center at 200 First Avenue West. We will be offering the full suite of Kanban and Enterprise Services Planning classes every month. Browse our schedule via our training listings.
