Well-informed practitioners of Agile sometimes talk with me about the Kanban method and ask me whether Kanban is better than Scrum and which one I use (the Japanese word kanban means signboard or signal card). Interestingly enough, I've been going to more and more conferences that have leaders who speak about Kanban. I write a lot about Scrum because it's what I've been using and have found successful with my clients. I am, however, a very big proponent of Kanban if a mature organization can use it wisely and effectively, and if the business and technology units can work cohesively. Sound too ideological for you? Maybe, but for Kanban to be successful, the wheels of an organization must be well-greased and communication channels must be wide open and transparent.
The main difference between Kanban and Scrum is that Scrum development moves to the rhythm of Timeboxed increments, usually two to four weeks, and are bookended by meetings and a sprint review. Kanban, on the other hand, does not have Timeboxed increments or any task estimates. Scrum tracks velocity, while Kanban tracks the flow of items moving through the work in process (WIP) and the total cycle time for an item to move through the development cycle to deployment. (See Figure 24.1.) In Scrum, a master owns the process; in Kanban, the team owns the process. The people who are proponents of Scrum are looking for a consistent cadence in the sprints, and those using Kanban look at the flow of minimal ...