Evolutionary Change

Definition

Kanban is a change-management method, not a software-development lifecycle: it starts with whatever process a team already runs and evolves it in small steps, rather than replacing it with a defined template that must be imposed and retrained into place. Because it leaves existing roles and workflow largely intact, it meets far less resistance than a "revolutionary" changeover. Anderson frames the Kanban Method as "giving people permission to think for themselves" about their own process, rather than dictating one.

In the Book

Chapter 1 opens with Anderson's own dilemma at Motorola and Sprint PCS: he had no positional power to impose Agile methods across teams, and every team resisted changes that hadn't been shown to relieve their specific constraint. He concluded that "every situation was unique" and that a process imposed out of context would be rejected by the people who understood that context — a one-size-fits-all methodology doesn't work (Figure 1.1). This led him from Goldratt's Drum-Buffer-Rope pull system (implemented at Microsoft's XIT team, detailed in chapter 4) to the simpler, more teachable vocabulary of "kanban." Chapter 2's "Kanban as a Permission Giver" section makes the contrast explicit: when visitors asked how Anderson coped with seven different kanban boards on seven different floors of Corbis, each following a different process, his answer was "Of course! Each team's situation is different." He contrasts this with practice-conformity assessments like Scrum's "Nokia Test," designed to "drive conformity and deny the need for context-based adaptation." Kanban, by contrast, "requires that some process is already in place" — it has nothing to say about what that process should be, only how to change it incrementally.

Why It Matters

This distinguishes two fundamentally different playbooks for organizational change: redesign-and-impose (define a target state, retrain everyone onto it, absorb the resistance) versus instrument-and-evolve (make the current system's problems visible and let people improve it one step at a time from wherever they stand). The second path trades speed of transformation for durability of adoption — it is the relevant model anywhere a change has to survive contact with entrenched local expertise and genuine variation in context, not just software teams.