The writing can be a bit dull, the examples a bit too verbose, but this book contains a thorough description of Kanban, one of the newer techniques for agile software management.

Kanban for software development descends from the broader lean traditions that have been gaining greater prominence in the world of agile software. Lean in general, and Kanban in particular, focuses on the idea that there is not one best process that works for all teams. As such, Kanban is not a software development methodology -- it is a change management methodology. The tools of Kanban help teams figure out how they can customize their processes to improve their performance. Kanban flips the question from "How can we get more done?" to "What is blocking our ability to get more done?"

At the heart of Kanban (although not sufficient on its own) is work in progress limits. Limiting the work in progress to get more done may seem counterintuitive. The value of these limits flow from the assumption that the gains to be had from improving the process are greater than the productivity lost by not having everyone fully loaded all of the time. This plays out in several ways.

First, limiting the work in progress forces teams to acknowledge the parts of their process that are bottlenecks. Without strict limits, the parts of the process that are not bottlenecks can keep taking on more and more work, causing it to pile up once it gets to the bottleneck. With strict limits, the problems become obvious.

Limiting the work in progress forces teams to deal with blocked work items. Without strict limits, it is easy to let blockers delay the completion of a task for a long time. First, the part of the team not responsible for the task is not motivated to deal with the blocker because they can just ignore it. Second, the task owner may also not deal with the block as quickly as they might otherwise because they have other tasks to work on. When the work in progress is limited, blocks have to be addressed.

Limiting the work in progress optimizes for latency over throughput. Many teams aim to get tasks done as quickly as possible. In practice, urgent (but not necessarily more important) items tend to jump into the work queue as soon as they come up, and people juggle multiple projects. Limiting the work in progress forces a conversation about priorities: Do we have to take on this task right away, or can it be on the top of our list of things to tackle next? If we have to work on it right away and we're already working at our limit, what can we drop? (Note that this sort of dropping is already common at an individual level. However, it's not necessarily communicated to the team or the external stakeholders which leads to mismatched expectations about when work will get done.)

Finally, limiting parallel work decreases task switching overhead, both at the individual and team level. At the individual level, too much parallelism can make people feel overwhelmed. "Too much" varies from person to person, but everyone has a limit. At the team level, too much parallelism fragments knowledge and/or leads to higher communication overhead since people have to share a larger amount of context whenever they solicit input from someone working an unrelated task.

Of course, just limiting the work in progress on its own does not make things better. The bulk of Anderson's book describes other concepts needed to effectively monitor and improve a development process. A mature Kanban system has a lot of pieces -- pieces that can make it look a lot like a development process -- but the key to remember is that these mature systems developed by adding and tweaking and removing process as it was shown to be needed by the problems they had in practice. While teams with a mature process derived using Kanban may have some similar best practices, part of the power of this system is making sure that those practices evolved based on the needs of the team. These practices shouldn't be adopted without thought -- and if they are, they'll likely fail. ( )

Overly complex for something that should be even simpler than Scrum. It seems also somewhat disconnected from the fact that we are delivering software systems. Explanations are too generic. ( )

This book is very easy to read, and focuses on kanban (Japanense visual pull system), and Kanban (Davids Organisational Change Management Strategy). David does a great job of explaining the theory behind and practical advice on implementing all of the techniques that go with Kanban. His experience with this stuff is throughout the book and these examples help to explain the topics under discussion. I took a lot of value out the discussion around flow, limiting WIP, bottlenecks, and the history of Kanban. While I do not think that I would apply Kanban to teams/departments that build large features; I would certainly use it for maintenance/small feature teams. Either way the knowledge around flow, etc is very valuable. ( )