Last week I not only finally managed to get my beloved reading lamp repaired, of course an Artemide Tolomeo , but also to utilize the newly provided cozily, brightly, and energy-savingly lit space to finish the book I had started the week before. And because I am excited about it, let me share my excitement with you:

The book title “Scrumban” is the combination of Scrum and Kanban, two management methods. Scrum is one of the predominant inhabitants of the Agile management method zoo, while Kanban originates from the lean management revolution attributed to the car manufacturer Toyota.

The author makes the case that it indeed is worthwhile to learn from the lean management practices, and that it is also possible to transfer the methods from production into the knowledge-work based software development.

Especially interesting I found his observation that the iteration length in agile methods is one of the artcificial parameters which need to be defined (2 week iterations, 4 weeks? one week or just a day?) and usually is intensly debated in Agile teams, but the switch to a lean method with its focus on Just-In-Time production can actually render the whole iterative concept superflouous. Instead, lean methods are described as pull models – whenever something needs to be produced, the inventory-producing task for this get triggered to deliver just in time. Inventory that is not needed yet is considered waste, and – now the hop to software development – even specifications that are written but are not being implemented yet are inventory, and thus waste. (Important note: Don’t read this as specifications are waste! Just those that are produced up-front and not being needed for the foreseeable future are according to Corey).

There are some very interesting conclusions and some real-life examples on how to put this into practice in the book, and the author does a good job (much better than I do here) to put out the arguments on why lean works for software. At least for me, reading Corey’s book was an eye-opener and did confirm some subliminal, not-yet formulated doubts about Scrum in particular and other agile methods in general I was hatching since the good of two years, working in a Scrum-like environment. I feel as relieved finding those doubts in somebody else’s writings as I was reading XP Refactored many years ago, a book in which much of the hype around extreme programming was put into a more sober perspective.

Corey’s book is short enough to be read completely front-to-back in one evening (with a good reading light). I already have marked it to be read again by me in 6 months, because there was too much information in there to stomach in the first run, and certainly when putting lean software production into practice I will refer to it again!