I’ve heard Kanban oftentimes be referred to as an Agile Method, but I don’t think that this is correct at all. I think there are some parallels between Agile and Kanban, but Kanban is not actually an Agile method, but instead it is a way to achieve agility. In this post, we’ll consider the two and see if you can agree that they are different.
Agile Methods refer to methods stemming from the writing of the “Manifesto for Agile Software Development“. There were many contributing methods as part of this discussion that were previously often referred to as “lightweight methods”. These include things such as the Scrum Framework, Feature Driven Development, Extreme Programming and Crystal Methods. At the time of drafting the Agile Manifesto, Kanban hadn’t yet been part of this conversation and really hadn’t solidified as a method itself. Thus Kanban was never really a part of that significant meeting at a point in time that was the coming together and coining of the term “Agile” and “Agile Methods”.
Apart from time, the most significant factor is that even though Kanban may be used for software delivery, it is not a software development method. Key to agile was “uncovering better ways of developing software”. Kanban is different to this – it is a management method. We use kanban to help us manage and improve the delivery of services – those services could be in technology, marketing, HR, legal or any other service in your organisation.
Lets consider the values in the Agile Manifesto:
- Responding to change over following a plan – Kanban is responsive to change. The mechanism of limiting WiP, having defined commit and delivery points are all important to this assist in reducing lead times and creating greater responsiveness.
- Customer collaboration – as teams improve their maturity in Kanban, there is a deeper connection with customers and an understanding of customer needs.
- Individuals and interactions – the kanban cadences are very important and regular interactions between individuals. The outcomes are often improved processes (system policies) or tools, but the interactions are well known to be a great reflection mechanism that cause this change. In Kanban terms this is often referred to in values such as transparency, collaboration, understanding, agreement and respect.
- Working Software – Kanban doesn’t relate to software, it’s a management method to improve service delivery, so it clearly fails this important point.
Thus, even though there are some similarities between what’s in the Kanban Method and the manifesto, there clearly are some key differences that set it apart.
Another significant difference between “Agile Methods” and Kanban is the way that they approach change. Kanban is very much about “Start with what you do right now” and “Agree to pursue improvement through evolutionary change“. These change principles encourage a continuous improvement mode of operation, rather than larger disruptive changes that “Agile transformations” have been known for. Consider these examples:
- Scrum – you need to introduce roles, introduce cadences and artefacts to support this. This can be quite disruptive to existing teams / processes.
- Extreme Programming – there are a lot of skills that need to come together for this, such as pair programming, test driven development, working in iterations etc. These can take quite some time to learn and adjust to and for XP to work effectively they need to be used together. This makes the learning curve very steep and starting can be difficult.
- SAFe – although this came after the manifesto, it has subsumed many of the other agile methods. In this example, you need to reorganise teams into release trains and launch them and all of the practices cadences that support it. These are large and disruptive changes and oftentimes it just involves the technology teams and maybe a periphery of the remainder of the organisation.
Kanban can, however, help you to achieve agility. In our Kanban System Design class, we discuss the XIT case study where they reduced lead time to less than 10% of what it was originally. We often see significant improvements like this in kanban implementations – not just lead times, but throughput and quality as well. Kanban continually strives to create services that are “fit for purpose” for its customers. Naturally with this continuous improvement pathway, we do see greater agility emerge in organisations. With results like these organisations can respond more rapidly to changing customer needs, have greater focus and even survive dramatic shifts in the market. But this is often beyond just software – it’s about making the whole organisation work together more effectively for greater customer and strategic outcomes.
Whilst most people consider Kanban an Agile Method, I think that Kanban is so much more than that for organisations that lumping it in with Agile Methods is holding back the results you can get. It creates a mistaken impression that large, interruptive changes are required and also may create the impression that this is just for technology groups. I hope that you would now agree that Kanban is not an Agile Method, but a way that you can achieve greater agility across your whole organisation in a non-disruptive way to create far greater outcomes.