In this series of short excerpts from my book Kanban from the Inside we’ve reached chapter 13, on Agile. Following the pattern of the preceding two excerpts, we’re skipping the main content of the chapter and reproducing some of my main conclusions.
Kanban and Agile
Compatibility
We’re often asked, “Is Kanban Agile?” To anyone who understands Kanban as the start with what you do now method, that’s a slightly odd question, but still, it deserves a respectful response.
When “Agile” is used as an adjective like that, it’s worth drilling down a bit to find out what’s really meant by the question:
- Are the values of Kanban and Agile compatible? Yes, absolutely! There is a basis here not just for comparison but for integration.
- Can Kanban help “improve agility” or make things “more agile,” improving an existing software development process—explicitly Agile or otherwise—in directions entirely consistent with Agile values and principles? Not only is the answer to that question a resounding “yes,” it is what the method was first developed to do.
- Is Kanban, in the words of the manifesto, a way of developing software? No. We are splitting hairs, perhaps, but in this sense it is misleading to describe Kanban as an Agile method. It isn’t a development process (or any other kind of delivery process) at all; there is nothing in the definition of the method that ties it to software. It is a management method that is broadly applicable to creative knowledge work, with a particular focus on organizational change.
- Is Kanban part of the Agile movement? Kanban’s community identity makes sense both inside and outside the Agile movement (note that both communities have a similar relationship with Lean). Some people seem to be troubled by that ambiguity, but actually it’s helpful and necessary. Ideas find room to grow and flourish in their own communities, and when the time is right, there is ample opportunity for cross-fertilization. And to providers of supporting services (trainers, coaches, consultants, and so on), the ability to choose from multiple identities can be very convenient.
At the level of methods and practices:
- Does Kanban work with iterative methods, Scrum in particular? Yes, and in the case of Scrum, the combination even has a name—Scrumban (described in Chapter 16). Kanban can work both inside Scrum, where it mainly drives team-level improvement, and outside it, where it helps a deliberately team-centric framework address the challenges of scale.
- Doesn’t Kanban mean abandoning iterations and other elements of Scrum? This is a serious misconception. Kanban is the start with what you do now method; we would be the first to warn you not to drop aspects of your current process in an uncontrolled fashion. However, it would be dishonest of us to pretend that your pursuit of flow won’t at some point test your commitment to timeboxes, story points, and the like. How you and your organization deal with that will be a matter of choice.
- Do Agile and its methods and practices represent important models for Kanban practitioners? Most definitely yes—it seems almost unthinkable that an effective Kanban practitioner working in the software development domain would get very far without a deep understanding and respect for Agile.
When to Use Kanban
One question remains: In an Agile context, when and how might Kanban help? More questions about your current situation will help answer that:
• Is Agile’s principle of sustainable pace still just an aspiration? Are people still overburdened in a process that doesn’t seem to fit all that well? Could Kanban-styletransparency (Chapter 1) and balance (Chapter 2) provide some relief?
• Is your collaboration (Chapter 3) focused mainly inwardly? Does customer focus(Chapter 4) suffer as a result of over-protective intermediation around the team or of excessive internal focus on the technology, the product, or the team?
• Are team-centric and process-centric approaches failing to deliver needed gains in end-to-end flow (Chapter 5)? Are local gains even making things worse elsewhere?
• Are leadership (Chapter 6), understanding (Chapter 7), and agreement under-appreciated? Is respect (Chapter 9) too easily forgotten when the big decisions are being made?
It is hard to change how organizations tick. Agile adoptions face that challenge all the time, and it should come as no surprise that issues such as these arise. Whether you are just planning to set out down that road or are already well along the way, the start with what you do now method is there to help, not to judge.
If your wider organization is ready to make the kind of changes called for by a hard and disruptive [1] Agile adoption and you can be very sure of success, it’s possible that you might not need Kanban. For organizations unprepared to take that risk, Kanban offers an alternative path to agility, an open-ended journey of co-evolution in which better ways of doing things are waiting to be discovered.
The Agile Model
Don’t be fooled by [the preceding part of this chapter’s] necessarily process-centric treatment of FDD, XP, and Scrum. With any of these methods you can go through all the iterative motions and still find that:
- People serve the process, not the other way around.
- The product is driven by the loudest internal voices, not the emerging needs of actual customers.
- Lots of work gets done without the end product ever being used for real.
- Changes in direction cannot be contemplated, let alone accommodated
On its own, process gets you only so far. If the aim is to be Agile, the Agile values need to be evident. Technicalities aside, if it’s working neither for the team nor for the customer, call it something else!
Agile has been and still is a game-changer. It has legitimized evolutionary delivery, wresting control of swathes of the software industry away from a plan-driven style of project management that was often ill-equipped to deal with uncertainty. No self-respecting Kanban practitioner can afford to ignore it.
[1] http://www.controlchaos.com/storage/scrum-articles/Scrum Is Hard and Disruptive.pdf
