Ive been reading a bunch of kanban and lean books recently as I work on my Pluralsight course on Introducing Kanban (not published yet will link to it when it is). The most recent one Ive finished is Scrumban, Essays on Kanban Systems for Lean Software Development, by Corey Ladas (Im doing the reviews in LIFO order). I made a bunch of notes while reading this book, and it has a great deal of useful information. I read David Andersons Kanban book first, followed by Benson and Barrys Personal Kanban. I think reading Scrumban last was definitely the right choice, though if I were recommending these books today I would most likely suggest someone start with Personal Kanban, as its the lightest weight of the three.
One thing that sets Scrumban apart from the other books is the narrative style and organization of the book. As it says in the titles byline, this book is a collection of essays there isnt a great deal of cohesion or a consistent narrative guiding you through the book. It also tends to assume a fair bit of of knowledge on the part of the reader, which is one reason why I wouldnt start off with this book if youre just starting to learn about kanban and lean software development. I also dont think the title is particularly fitting, since there is only one essay that deals with scrum and mentions the term scrumban in the whole book. I have a feeling the title was chosen mainly because it was short and would leverage the popularity of scrum to drive up book sales whether this was the case or was successful I cant say.
I found a great deal of value in the book, and it is certainly no rehash of the other two kanban titles listed above. There are some very important, basic concepts covered here such as the analogy of kanban tokens to money in one of the first essays. Corey does a great job of examining multiple different approaches to processes and showing their pros and cons. Things like methods for synchronizing different handoffs between related up- and downstream collaborators in a process are explained clearly and are honestly things Id never given much thought previously. The book also does a great job of reinforcing the notion that time-boxed iterations are a stepping stone to an even more streamlined process. If youve ever considered the logical progression of moving from infrequent software builds, to having a daily build, to having continuous integration, you can see the same logic being applied to moving from large project phases and handoffs (e.g. waterfall) to many smaller and iterative iterations (sprints), to continuous software delivery and one piece flow (ideal).
One criticism I do have of the book is that it often didnt define new terms and acronyms as they were introduced. I noted a bunch of them:
AHP prioritization
takt time
heijunka board
andon lights
axiomatic design
There were probably more that I missed because I was already familiar with the term, and of course its possible some of these were covered somewhere in the book and I missed them, but these were my google these later notes. The links above are the result of my google-fu after-the-fact.
The latter 2/3 of the book shows a bunch of different ways to model processes using task boards, and the effects of each of these designs. The analysis from these areas of the book are easily worth the price of the whole book, considering how much time theyll save you if youre just getting started. The book doesnt propose one right way to go about implementing such systems, but it does a very good job of showing the pros and cons of a number of approaches.
Overall, I thought the book had some great information, but could have been organized better. I would give it 3 or 4 stars on Amazon and would recommend other books first, but if youve read the others and still want to learn more, theres some great information here.
