I’ve been reading a bunch of kanban and lean books recently as I work on my Pluralsight course on Introducing Kanban. The most recent one I’ve finished is Scrumban, Essays on Kanban Systems for Lean Software Development, by Corey Ladas (I’m 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 Anderson’s Kanban book first, followed by Benson and Barry’s 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 it’s 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 title’s byline, this book is a collection of essays – there isn’t 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 wouldn’t start off with this book if you’re just starting to learn about kanban and lean software development. I also don’t 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 can’t 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 I’d 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 you’ve 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 didn’t 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 it’s 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 they’ll save you if you’re just getting started. The book doesn’t 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 you’ve read the others and still want to learn more, there’s some great information here.

If you’re looking for a quick introduction to kanban for personal or team use, check out my Kanban Fundamentals course on Pluralsight.com.