For some years, now, David Anderson has vocally separated Kanban from “agile” or “agile methodologies” like Scrum, XP, and so on. I never really understood why this was. Although obviously Lean is found in several industries as is the use of various elements we find in Kanban, easily the most common place to find Kanban in the wild is in software development, and specifically software development teams trying to become more agile.
Also, you have to understand that I came to Kanban as a progression of sorts from Scrum. Scrum helped me achieve a lot of the things I was trying to get out of a more agile software development experience, and when I came across Kanban, I saw it as (in my opinion) a better way to get at those same things. But I didn’t see it so much as a different kind of thing from Scrum; just something that did some of the same things better. So, in my head, Scrum, DSDM, XP, Kanban – these were all the same kind of thing, just with varying approaches and doing some things better than others.
But now, after having engineered the use of Kanban in a few different organizations and observed its power and value, as well as doing research trying to accumulate something intelligent to say about its differences with SAFe as it bulldozes its way into the market like a hyperactive wrecking ball that just demolished a Pixy Stix factory, I think I’m beginning to see what David’s been on about.
Agile and agile-ish methodologies can link their spiritual heritage to the concepts that became embodied in the Agile Manifesto – the signatories of which are names that you’d recognize in the field, like Ron Jeffries of XP fame and Darth Sidious of Scrum. This Manifesto articulated principles and concepts of what agility was looking like in software development (and specifically software development, I might add – it says right there in the preamble). People began to create and collate practices and systems that, in their minds, did good jobs of expressing in practice and technique those agile principles. You do these things, and you are getting closer to expressing those principles more fully and more comprehensively.
What I have been discovering over time, though, is that Kanban actually makes nothing more agile, nor does it improve anything.
Rather, Kanban is an efficient, effective way to show you where you can improve, the best places to improve, and what the impact will be. In other words, Kanban gives you everything you need to improve quickly, efficiently, predictably, and get the most bang for your buck.
When I was a kid, dentists would sometimes give you these red tablets for you to swirl around in your mouth after you brushed your teeth. They tasted like they were made from Hell’s own brimstone and the ground up bones of dentists that had passed on, and perhaps they were, but when you spit the stuff out, there would be red areas on the surfaces of your teeth that you missed while brushing. They didn’t clean your teeth; you had to do that. But the red tablets drew your focus immediately and visibly to the areas that needed your attention and the severity of your lack of attention.
Kanban is like that.
Making your work visible, limiting your work in progress, measuring the flow of your work, making policies explicit, and managing to flow are all designed to give you exactly what you need to apply your improvement brainpower. Where do these improvements come from? From you, of course. Nobody knows how to do the work better than the people doing the work; not an agile coach, not a consulting company, not a manager of the people doing the work – the actual people doing the work are your best source of ideas for improvement.
Organizations usually don’t lack opinions about how to improve; what they lack are ways to get their work situation under control so they can meaningfully study it, ways to sift through the good ideas from the not-so-good ones, ways to know what their priorities should be, ways to project the impact on the work, and ways to measure the actual impact to see where adjustments to the good ideas need to be made.
So, why is Kanban not agile? Because Kanban doesn’t increase your team’s agility one single iota. What it does it create the conditions and foundations necessary and provide you with all the intelligence you need for kaizen – an ongoing journey of improvement, driven by the people doing the work, but always viewing how it improves the system as a whole.