One reason is simply satisfaction with the status quo, and lack of curiosity about alternatives, despite overwhelming evidence that traditional management is bad fit with today’s mercurial marketplace. Whether managers realize it or not, becoming Agile is becoming the price of survival.

Another is the lack of coverage in business journals: you can search Harvard Business Review without finding a single significant article on Agile. Agile, it seems, is something strange going on in the inscrutable world of software development, a subject for low-level case discussion, but of little relevance to the C-suite or management in general.

What exactly is Agile?

A further reason is that the Agile software development community has had little outreach beyond software and, as Michael Sahota writes in his interesting new book, An Agile Adoption and Transformation Survival Guide, an e-book available here, sometimes lacks clarity about the nature of Agile.

The Agile community suffers a significant confusion between adoption and transformation. Sadly, change agents talk of adopting Agile and not about transforming the culture of a company to support the Agile mindset. The sad consequence of this myopia is of change agents accidentally undertaking a transformation without full buy-in or understanding of the organizational consequences. The typical result is failure.

In effect, there is a confusion between Agile as a set ofpractices and Agile as something more. As Sahota writes:

Well, what is Agile? The consensus definition is provided by the decade old Agile Manifesto. Agile is an idea supported by a set of values and beliefs. In other words Agile defines a target culture for successful delivery of software.

Agile, Sahota says, is more than a process.

Agile is commonly described as a process or a family of processes. This is true, but a dangerous and incorrect abstraction. Sadly, I have communicated this misleading message out of ignorance many times. If Agile were just a process family, then we wouldn’t be seeing culture as a prevalent problem.

Agile is also more than a product:

All too commonly, Agile is bought and sold as a product. Companies have problems such as too slow time to market or poor quality and want a solution. Agile benefits are touted and a project is kicked off with Agile as the solution. Dave Thomas coined the concept of the Agile Tooth Fairy where Agile coaches can swoop in and sprinkle magic dust on troubled projects to correct years of atrophy and neglect. This is a myth: Agile is not a silver bullet.

As I suggested in yesterday’s article, Scrum as the most dominant variety of Agile embodies both the practices and values of Agile. As Sahota writes:

Agile is about a fundamental shift in thinking. Tobias Mayer has written that Scrum is much more about changing the way we think than it is a process. Bob Hartman has a great presentation on this topic – Doing Agile isn’t the same as being Agile. The essential point is that we are “Doing Agile” when we follow practices and we are “Being Agile” when we act with an Agile mindset. Experienced practitioners know the practices are a means to an end.

As a result, Scrum is difficult to implement in a traditional culture, precisely because the values implicit in Scrum are in conflict with the values of a command-and-control hierarchical bureaucracy. Sahota concludes, I think correctly, that attempts to introduce Scrum into such a culture may achieve some success for a while, but that ultimately they will not endure, so long as the traditional culture endures.

By contrast, one attraction of Kanban is that it is a set of practices that can be implemented even with traditional culture of command-and-control hierarchical bureaucracy. It doesn’t necessarily challenge the existing culture. It can work within the existing culture, whatever it happens to be.

This is because Kanban is principally about making work flow visible. It revolves around a visual board for managing work in progress and making flow—constraints to flow—visible. The basic idea is tasks start on the left side of the board and move across the board through the phases of development they need to go through to be considered “done”. Finished tasks, ready to release into production, pile up at the end. The Kanban board is used to limit the amount of work in progress and so enhance overall productivity. (For those unfamiliar with Kanban, go here for very useful introduction by Jeff Patton.)

Is Kanban truly Agile?

The ability of Kanban to work within a traditional command-and-control culture however leads on to Sahota’s interesting question: is Kanban truly Agile? Sahota writes:

I used to think so. I don’t any more. I can see now how the belief - that Kanban is Agile - is harmful since the cultural biases are different.”

This is interesting because the conventional wisdom tends to the opposite viewpoint: namely that Kanban, along with Scrum and XP, finds its place among the principal ways of implementing the Agile Manifesto of 2001.

Sahota considers the argument that Kanban can be used as a “Trojan Horse” or “Gateway Drug”

The gateway drug theory states that softer drugs (Kanban) can lead to harder drugs (Scrum, XP)… With Kanban, there are documented cases of teams spontaneously collaborating, learning, and noticing/solving problems. This has been my experience as well and would confirm the hypothesis of Kanban as a Trojan horse (containing Agile on the inside).

It is good when people work to improve their environments at a steady pace. Many organizations are not ready for a radical overhaul (even though they may desperately need one). For companies like these, Kanban is a great place to start. Getting off the sofa and going for a marathon (Scrum) may cause a heart attack; for many it may be better to start by jogging around the block (Kanban). We will explore this topic subject further through an exploration of adoption and transformation.

Sahota argues that “Kanban+Agile = Agile”. If Agile values are combined with Kanban practices, then Kanban can lead to Agile.

It is possible to practice an Agile mindset with Kanban as a starting place for evolving the process. In this situation, the focus is around Agile values and principles where policies and processes are used to support people’s work. Such an approach may be appropriate where Scrum or XP are not a good fit for the environment. See CrystalBan as an option for integrating people into Kanban [Scotland – “Crystallising Kanban”].

Olaf Lewitz argues that Kanban can and should be used just as Agile is - to challenge the status quo. It’s primary purpose is to provide a sense-respond loop that can be used to drive change in organizations. He argues that “the people are the system” and that any change program must involve them as a central component.

In the end, the definitional question whether Kanban is truly Agile is subordinate to the substantive question whether Agile values are in place. If Agile values are in place, Agile can flourish. If not, it won't.