Just now I finished David J. Anderson's recent book, Kanban - Successful Evolutionary Change for Your Technology Business, in between trips to the kids who are supposed to be asleep but keep calling for water, books, hugs, ...

To do this review I'll use the rules from The Perfection Game to guide me. So, here goes:

I give the book a 9 on a scale from 1-10 (hint: I really like it a lot).

What I liked about the book was (not an exhaustive list)

• how well the first chapter described David's searches for sustainable pace and successful change management, and how it took me by surprise with its very humane message of giving the team back a social- and family life.
• David's Recipe for Success for the Technical Manager
  • Focus on Quality
  • Reduced Work-in-Progress
  • Deliver Often
  • Balance Demand against Throughput
  • Prioritize
  • Attack Sources of Variability to Improve Predictability
• the great stories from his own time at Motorola, Microsoft and Corbis.
• David's insistence on making the meaning of words bandied about in Agile/Lean cirlces very clear before proceeding to tell you it's great and you must have it. For instance, his fabulous description of Kaizen culture on pp. 49-50 where he dives deep into why Western culture's win-lose mentality makes it so hard for us to establish a win-win Kaizen culture in our workplaces.
• in general I find that David writes well and very much to the point which I really appreciate.
• that the book contains an extremely practical guide to implementing Kanban, as well as going into the more advanced techniques, such as how to deal with non-linear workflows, classes of service, scaling Kanban, and others.
• the Operations Review chapter, as it was a revelation to me to read about how a business unit of 100 or more people could retrospect every month in only 2 hours and get good results from it.
• the sections on the goals for doing Kanban are great because it exemplifies how David keeps himself and the reader grounded in reality, and makes sure to keep the business needs in mind at all times.
• David's intense focus on science and asking why.
• how David always ties every practice or guidance with a higher level goal.

For me to give the book a 10 the following improvements would have had to have been made:

• tell more good stories like he does in the first part of the book to counterbalance the very clinical vocabulary of the whole text.
• Provide a better explanation for the reasoning behind the advice to delay improving requirements prioritization (the PO process as I think of it) until the team "is capable of focusing on quality, limiting WIP, delivering often and balancing demand against throughput". I have a hard time swallowing that advice and agreeing with David's view that "[p]rioritization is rightly the job of the business sector, not the technology organization..." I agree that biz should prioritize, but I read these words as too black and white where biz designs the product and IT just implements what the biz comes up with.
• Instead of using the word 'resource' to describe a human being, use 'person' or something similarly animate-sounding.

To summarize: A brilliant book from a brilliant guy that all IT people should read, especially managers and team leads.