Review of: "Kanban" by David Anderson


Review posted on amazon.com:


I was looking forward to David Anderson's book. While I wasn't enthusiastic about his previous book: Agile Management, I liked his new work and the balanced view on change he is promoting. It all made me curious.

I've not been disappointed. Kanban is a readable and balanced book which introduces the Kanban method of bringing improvement and change to organizations. It is well written (better than his previous book, IMHO) and well-argued with many cases from David's own experience and from other people in the growing Kanban community. It is and will probably stay the definitive reference for the SW Kanban method.

The book consists of four parts. The first part is a short introduction to the subject. The second part is called "benefits of Kanban," but it better describes its history (from David's perspective). The third part is more of less a description of the Kanban method itself (called "implementing Kanban") and the last part contains several background improvement theories which the reader ought to know about when implementing Kanban.

Part two is called "benefits of Kanban" and is more or less a history of how Kanban has evolved. Chapter three is what the author calls "the recipe of success" and its David's opinion on what you need to do in order to build good and predictable software. I didn't like this chapter too much as it had a "just do this and everything will be ok" tone which I also found in his previous book. Chapter 4 introduces the work David has been done at Microsoft and how he improved a team without changing the process but by managing the WIP, an interesting story. Chapter 5 described David's work at Corbis where he continued his earlier Microsoft experiences and extended (or actually created) SW Kanban.

Part three describes the different aspects of Kanban. It starts with analyzing the existing processes, visualize it and then decide the boundaries of what is inside the Kanban scope and what is considered the outside world. The "outside world" works with the Kanban team based on SLA and releases based on a steady cadence (chapter 8 and 9). From chapter 12 the book covers less known Kanban topics such as classes of service, different reporting, scaling and operational reviews. Chapter 15 is then the actual "implementing Kanban" that suggests how you can move forward and implement these ideas in practice.

Part four covers broadly said three different improvement models: Theory of Constraints, Lean, and Deming. Each chapter provides a minimum introduction into the subject and suggests the reader to use these different models for making the gradual improvements in their processes. Chapter 20, the last chapter, discusses handling obstacles that need to be resolved quickly in order to make improvements.

There were a couple of things I liked a lot about this book... and a couple of things I didn't like and disagreed with the author. One of the things I disagreed with was the hidden suggestion that the problem of building quality software has been a solved problem. I got this feeling from the way he mentions things like professional testers, CMMi as obvious and barely covers e.g. integration. The book contains very little (nothing) about the actual development of software. But, as this isn't the main topic of the book, it doesn't matter that much... The thing that did bothered me was the suggestion that all works flows sequentially and that one activity has one purpose. I got this feeling from the way e.g. analysis topics were handled or how the last chapters talked about an activity being waste or not... for example estimation. Though, I agree that estimation might/might not be waste, during the process of estimating there is often requirement discovery ongoing, which is very valuable. However the side-effect of activities wasn't covered well and, I felt, it was assume that activities have one purpose and flow sequentially. That said, it might not have been the author's intention and just my sensitivity to this.

Then, the things I liked a lot about the book. One thing I really liked is how David positioned Kanban not as a SW development method but as an incremental (evolutionary) improvement paradigm. This book definitively challenged my own assumptions about change and how change ought to happen. Kanban tries to avoid change resistance by not making the change, visualizing the current processes and then making the change obvious to the people involved. I do think it has some drawbacks, but definitively like the approach. This message isn't given at one particular point, but it is the common theme of the book and of the Kanban method. Well thought of and also... well written. Another things I liked about the book is how David constantly refers back to his own experiences. This is not a book that says "hey, I got an idea, lets try this", but its a book where the author reflects on his history (together with the reader) and uses that to explain how he got to certain conclusions. Well done.

All in all, this book will definitively be the standard reference for Kanban. I was thinking between a four and a five star rating. I decided to go with four stars for the couple of things I didn't like. Anyways, definitively recommended for anyone who wants to know more about SW Kanban.


Read more

Scrum master ทำแค่เนี๊ยะ

Scrum master ทำแค่เนี๊ยะ

เวลามีคนถามว่า Scrum master ทำอะไร แล้วผมตอบว่าทำให้ Scrum เวิร์คสำหรับทั้งองค์กร ซึ่ง โฟกัสหลัก ๆ 4 อย่างก็จะอยู่ที่ Product owner, ทีม, engineering practices และ องค์กร บางครั้งที่ผมจะได้ยินเสียงตอบกลับมาเบา ๆ ว่า “แค่เนี๊ยะ?” ในฐานะ

By Chokchai
how to สร้าง Knowledge Management

how to สร้าง Knowledge Management

ตอนเรียน Large Scale Scrum กับ Jurgen de Smet สิ่งหนึ่งที่ผมได้เรียนรู้ คือ ปัจจัยสำคัญหนึ่งที่ทำให้องค์กรหนึ่ง ๆ จะเร็วขึ้นได้ คือ จะต้องเรียนรู้ไปพร้อม ๆ กันได้ ซึ่งถ้าอยากทำแบบนั้นได้ก็จะต้อง share ownership

By Chokchai
โลกการเขียนโค้ด ตอน ซามูไรกับสปาตั้น

โลกการเขียนโค้ด ตอน ซามูไรกับสปาตั้น

ซามูไรที่ได้รับความไว้วางใจให้แก้ core logic จะมีสัญชาตญาณซามูไร คือแก้ตรงนี้ จับยามสามตาแล้วรู้เลยว่าจะไประเบิดตรงโน้น แล้ววิ่งไปสกัดบั๊กไว้ก่อนความเสียหายจะเกิด (ถ้าเป็นในหนัง ตอนนี้เป็นบทที่บั๊กร้องว่า “มืงรู้ได้ไง?!” :D) หลังจากที

By Chokchai
ประสบการณ์ TDD

ประสบการณ์ TDD

มันมีบางชั่วขณะ ที่ผมอินกับ Test-Driven Development (TDD) มาก จนอยากจะแนะนำทักษะนี้ให้คนเขียนโค้ดทั่วโลกที่สนใจเลย ผมคิดว่า ทักษะนี้มีผลเยอะมาก ๆ กับความรู้ความชำนาญในการเขียนโค้ดของผมทุกวันนี้ แต่ที่ผมไม่เคยอธิบายเป็นคำพูดออกมาได้คือ ทำไมนะ? เมื่อเช้าตอนกำลังอ่านเกี

By Chokchai