Scrumban: Essays on Kanban Systems for Lean Software Development

by Corey Ladas

Corey Ladas' groundbreaking paper "ScrumBan" has captured the imagination of the software development world. Scrum and agile methodologies have helped software development teams organize and become more efficient. Lean methods like kanban can extend these benefits. Kanban also provides a powerful mechanism to identify process improvement opportunities. This book covers some of the metrics and day-to-day management techniques that make continuous improvement an achievable outcome in the real world. ScrumBan the book provides a series of essays that give practitioners the background needed to create more robust practices combining the best of agile and lean.

Genres: Management, Business, Software, Nonfiction, Technical, Computer Science, Computers

161 pages, Kindle Edition

First published January 1, 2008

Reviews

[Matt · Rating 2 out of 5]

Presented here are a number of essays on lean software. Less an introduction to the concept, the book is more musings with a theme. That said, there are introductions to some of the aspects of Kanban and how they are being applied to software (after their original application to manufacturing). Also included are thoughts on the best ways to do things in a Kanban system - the proper layout of the big board, how big a team the system (and variations on the system) can support, how small a portion of work should be to keep things moving. Most of these concepts are built upon in a "try it, see what works, adjust, see what improves" manner.

That said, without some experience with software development systems going in, this book may be incomprehensible. Too often, terms are defined many pages after they're used and the author sometimes takes for granted that his audience has instant access to some knowlege that they may not. Essentially, as a series of linkified blog posts, this would be much easier to read, but as a published work, editing in some exposition might have made this easier reading.

[Robert Postill]

I feel bad in some ways for this book. It came just after reading the Kanban book and also the rspec book. So when I picked this book up I was looking forward to stretching my legs intellectually. Sadly, this book wasn't what I wanted. Too simple in some ways and not simple enough in others this book suffers from being an advanced book on agile (by requiring pre-knowledge of SCRUM/XP and Lean thinking) yet also rebuilding arguments eloquently made by others in setting the basis of the book. Some of the analogies seemed well-worn too (coffee-cup kanban example I'm looking at you).

As an aside, please, if you're writing a book about Kanban don't take any more pictures of the post-it notes! I get tokens but it makes it hard to read the damn tokens with your photography. Just do a diagram and have done.

It did help clarify some of my thinking on Kanban but was it worth the effort? Only just.

[David Snook · Rating 4 out of 5]

For a small book, it is surprisingly packed with software development process insights. It is also surprisingly applicable even nine years after it was published, which I partially attribute to how early the author was applying Lean concepts to software development (while everyone else was just starting to pick up on Scrum). A self-professed software "methodology geek", the author is not a process snob but instead takes an eclectic approach and shows how various approaches can be mixed-and-matched depending on the situation. I was particularly surprised to see the V Model from my Waterfall days being offered as a workflow option, along with eXtreme Programming and even a mention of the SEI Personal Software Process. I expect that I will spend some time tracking down the other intriguing allusions and references to other process approaches that I had never even heard of before, as I am reminded that no one approach has the perfect solution in every circumstance and there is value in a diversity of perspectives.

[Kevin · Rating 5 out of 5]

For those of you that have felt that Scrum was just a touch childish, this is definitely a perfect read. This books describes a "second generation" of Agile development processes, using Scrum as a foundation for evolution.

This book assumes detailed knowledge of Scrum, and at least a passing knowledge of Lean principles (don't expect to find a definition of "Kanban" in here); however, this just lets you get on with the important bit: why this all works (and, most interestingly, how Scrum grasps at but doesn't really optimally attain many of these ideas)! The read is quite quick, although there are definitely areas that are worth a second or third read.

Best methodolgy introduced: "Developer's Natural Authority: if you refuse to take responsibility for sequencing the work, then I will."

[Alejandro · Rating 3 out of 5]

Scrumban was on my reading list for some time. The book offers some tips and some useful approaches that can be experimented with software development teams and is a useful resource for team members interested in applying the Kanban Method.

Despite that, the book did no reach my expectations. Corey Ladas writes the essays with a technical orientation (I personally like this style), but the book is not self-contained enough to introduce the reader to Kanban.

I also believe that the name Scrumban gives the impression a new method will be introduced, and that's not the case.

This being said, I believe it's a good book to have as a complementary reading on Kanban.

[Nathalie Karasek · Rating 2 out of 5]

I was looking forward to reading this book as I was expecting some insight on how to combine scrum and kanban. I am now rather disappointed. The book is just a bunch of articles that I would rather expect to read on a blog. Some interesting things have been mentioned but to be honest I did not really understand some parts of it. Concepts/Methods/Tools have been mentioned without giving any explanation so without researching things on the internet I felt pretty lost. That is not a pleasant reading experience. I am still happy that I read through it, but well also somewhat disappointed

[Christophe Addinquy · Rating 4 out of 5]

This book is short, but the content is not. Many people spoke about merging Scrum and Kanban looking at this book. But this is not the purpose of the text. It's all about the nature of agile, about how to move the development model while the team maturity progress. The whole book is in fact a compilation of blog post, but it's worth reading !
ma note de lecture en français ici

[Erin · Rating 2 out of 5]

Some interesting ideas in the book but his writing style amounted to an insiders club of kanban and project management jargon that he never bothers explaining.

[Flavius · Rating 3 out of 5]

Not really about Scrum AND Kanban, but about Kanban INSTEAD OF Scrum. This book is a series of essays on lean principles, agile processes, Scrum (mostly ridicule) and Kanban.

I've taken from the book the thought to better analyze software development workflows. The author argues convincingly that the de facto Scrum workflow (to do, doing, done) is not sufficient.

The book is also useful if you need an incremental approach for switching from Scrum to Kanban.

[Katharina Joos · Rating 2 out of 5]

Found this book quite difficult to read and had to re-read bits. Am dipping into it occasionally for reference purposes.

[Patty · Rating 2 out of 5]

Never got that "aha!" Moment I was looking for. Nothing too Earth-shattering here.

[Maksym Karazieiev · Rating 3 out of 5]

Some essays and theory on kanban and lean. Couple of good examples but nothing outstanding

[Kirill Klimov]

Great agile reading. Not entry level. Super value/volume ratio.

[Mike Fowler · Rating 3 out of 5]

Several interesting ideas and observations. Good refresher on Kanban with critiques of other Agile methodologies.

[zoagli · Rating 5 out of 5]

More than a decade after its publication, this is still a brilliant book. It may be collated from a series of blog posts, but it feels like a cohesive whole.

[Matthew · Rating 3 out of 5]

For its age, it's still pretty useful in describing the technical reasons why agile and lean development are and were relevant. A good mix of common sense wisdom -- "you can't do more work than you have the capacity to do work, without taking longer to do it" -- and technical, quasi-mathematical analyses of the reasons why such statements are valid. Recommended, but feels like it could have been sewn into a more complete, coherent whole, rather than a bit of a mishmash of somewhat related essays.