Is Kanban Agile? Does It Even Matter?

There is an ongoing dispute in the Agile community focused on the question "Is Kanban Agile?". Isn't that funny? People argue and spend their time trying to classify the terminology to clarify what is inside the Agile universe and what is not. Where is the value in that?

Instead of approaching this question like a botanist who classifies plants based on their roots, stems, and leaves, let's center the value of Agile and Kanban in the discussion and approach the topic from this perspective.

So why do people think it is important if Kanban is Agile or not?

Focusing on the value Agile brings, it seems that the essential question we should be answering is: Can you become more Agile by applying Kanban?

The short answer is yes. The long answer follows.

The Origins of Agile and Kanban

Being Agile is becoming critical for the long-term success of companies.

While in early 2000, this was mainly true for the software development industry, today, Agile is seen as a new generation approach to project management and management in general in all knowledge work-related industries.

More and more businesses commit a lot of time and money to Agile transformation, aiming to reduce time to market, achieve higher overall project efficiency and productivity, improve the predictability of customer deliveries, and increase the transparency of project planning—in other words, to improve their organizational agility.

Long-term goals of Agile transformation processes, Source: https://www.researchgate.net/

According to the latest reports, the global enterprise Agile transformation services market was pegged at $15.44 billion in 2018 and is projected to garner $63.83 billion by 2026.

Clearly, Agile is more than just a trend. It has attracted a lot of attention, promising better business results for everyone who successfully applies its methods. So what hides behind the term?

Why the Name Agile?

Some people mistakenly think that the Agile manifesto represents the birth of all Agile-related methods. However, many of the methods and approaches considered today Agile (like Scrum and XP) existed and were applied before it was written in 2001.

An interesting question is why they specifically chose the term "Agile" to name the values and principles they outlined in the document. Martin Fowler, one of the seventeen names behind the manifesto, shares they all agreed to Agile as a new name because they felt it captured the adaptiveness and responsiveness to change that are so important to the approach they defined.

So, the core value behind the collective name Agile is the aim of becoming more adaptive and responding to changes quickly.

Kanban Meets Agile

The Kanban method emerged at the beginning of 2007, and its main purpose is "Defining, managing, and improving services that deliver knowledge work" (1).

Software developers, who tend to be early adopters of many new approaches and methods, also tried it. And for many of them, it worked. It helped them gain better visibility into their work, become more efficient, and therefore more flexible. Furthermore, they started combining it with Agile frameworks and methods they already used, which often led to significant process improvements (2).

Per definition, Kanban's main focus is to help people do the right work at the right time (2). Giving visibility into the work system also explicitly presents the highly critical tasks that need the most attention. This way, the risk of their incompletion sinks, and the flexibility amongst other tasks in the project increases.

A research paper, providing statistical analysis of the effects of Scrum and Kanban on software development projects came to the results that Kanban scores better than Scrum in the following aspects:

• Project teams are aware of the project status.
• Projects are delivered on time according to schedule.
• Project teams can adapt to the changes quickly.

Looking at the value it brings, it clearly enables teams to be more informed, efficient, and adaptive. Such results show that Kanban may not be Agile-brewed, but it is agility-oriented.

Agility in the DNA

From all said so far, I think it becomes clear, agility is the crossing point where Kanban and Agile meet. Looking at the desired results and outcomes, it is clear, teams and companies aim to be Agile to improve their performance and adaptability. On the other hand, applying Kanban brings all of that which ultimately leads to improved agility.

Kanban was even defined as "a 2nd generation Agile Method" by Alan Shalloway (2). Furthermore, its evolutionary approach, following the "Start with what you do now" principle, proves to cause less disruption and resistance from teams than other Agile methods or frameworks. The Kanban goal is gradual transformation and continuous improvement, which leads to teams introducing small j-curve effects (i.e., "little J" changes).

This leads to an incremental and evolutionary change to their current process rather than large j-curve effects (i.e., "big J" changes) that typically create a dip in performance - and ultimately morale - before any improvements are seen.

Focused on managed commitment and a balanced flow of work, Kanban allows companies and teams to change course quickly if customer requirements change or issues with dependencies arise (1). Furthermore, a well-functioning Kanban system delivers a new level of transparency in your projects and processes. Seeing the full picture clearly also enables you to unhide improvement potentials and evolve further continuously.

Knowing how central adaptability for Agile is, we should also discuss another aspect of the Kanban method - process tailoring. Allowing teams to modify and customize their processes, makes Kanban extremely adaptive to a different company or team structures and processes. Delivering these agility attributes, Kanban offers an evolutionary approach to Agile, making it one of the most flexible methods in the Agile space.

Bottom Line: Is Kanban Agile or Not? 

After all, is there a single answer to "Is Kanban Agile"?   

Considering there are so many different opinions on this topic in the Agile space, it will be tricky to give a simple "yes" or "no" answer.   

Actually, does it even matter? What really matters is how Kanban and Agile can work together to help teams get their work done better and enhance their agility and effectiveness in delivering value to customers.  

In fact, the answer to this question lies somewhere in between. 

If we set aside the fundamental differences and origins of Kanban and Agile for a moment and focus on the shared goal and the value they seek to deliver, it is easy to see that they form an ideal blend of principles and tools for managing work.  

How’s that? 

Kanban's emphasis on visualizing work, limiting work in progress, and optimizing flow aligns seamlessly with Agile values and practices, making it a natural fit within Agile methodologies. 

Everything said so far barely scratches the surface of the discussion of how and why using Kanban can help you achieve agility. Kanban enables adaptivity, nurtures improvement, allows teams to improve their efficiency, and gives visibility into projects and processes. It aims at agility like every other Agile method or framework known, so you can safely say the Kanban method paves the path towards agility. Even more, Kanban is built to help companies become resilient, meaning to stay competitive and adaptive in the long term.

At the end of the day, nobody should choose Kanban, Scrum, or something else so they can say, "I am doing Agile." So, do not focus on whether Kanban is Agile or not. Focus on what you want to achieve and choose how to become more flexible and improve your agility based on clear goals and the challenges you want to overcome.  
 
As Mike Burrows states in his book "Kanban from the Inside", "Kanban's development is a testament to the spirit of Agile - pragmatic, evolutionary, collaborative, and deeply customer-focused." 

Sources:
(1) D. Anderson, A. Carmichael: Essential Kanban Condensed, 2016
(2) D. Anderson: Kanban-Successful Evolutionary Change for Your Technology Business, 2010.