I have been encouraged by Eric Willeke and Alan Shalloway via the kanbandev group to share my thoughts on Donald Reinertsen’s new book Principles of Product Development Flow and I promised a review that would also serve as something of a personal retrospective. As book reviews go the result is probably a mess, but you can read clean & tidy book reviews elsewhere!
Why the retrospective? As past readers of my blog will know, I’ve recently undergone some significant change of late. I left behind a 12 year career in the City, took a very welcome 3 month break from work, and at the end of that time made something of a lifestyle change by moving well away from London to live in a cottage in the picturesque Derbyshire Dales. At the time we committed ourselves to the move I didn’t know exactly would come next but there was sure to be a Lean flavour to it, and during my time out I quickly fell in with the Kanban crowd. When I landed my new role it was clear that Kanban would feature prominently from day 1; two months have since passed…
Back to the book: it’s not about Kanban (though it is mentioned). Neither is it a book about software development (it’s much more general than that, though the specifics of software development occur frequently throughout the book). It is however a book that has shone light on both subjects for me – not as another methodology book, but by strengthening significantly my understanding of how development processes work in general, helping me to really understand why I’ve seen what I’ve seen in past projects (good and bad, mine and others’), and by helping me to crystallise how I can deal in an economically justifiable way with things that appear on the surface to be completely intangible.
To be more specific with that last thought, what excited me most about the book was the way it ties the management of queues – covered very well in their own right – to economics. This happens early in the book, changes (or at least changed for me) the way the rest of the book is read, and hugely increases its value. It may sound academic, but I found it motivating (if occasionally uncomfortable) that I could link so directly the way I run projects past, present and future to business performance. And making that link was straightforward; it’s a book that is free of hand-waving and its examples ring true to my own experience.
Let’s get down to details with some quotes:
The issue is not queues, it is the economics of queues (p17)
We can define waste as a failure to optimize [globally] our economics (p33)
Optimum queue size is an economic trade-off (p68)
Focus on the wrong queue can actually create push rather than pull. Why (speaking in retrospect with embarrassment at my own stupidity, not to criticise the jargon of certain branded methods) emphasise the development backlog when you haven’t achieved flow downstream? Are all of your queues even visible (always, to all, on the wall)? Do you have any idea – even roughly – of your cost of delay (“COD”) and consciously optimise (portfolio-wide) to minimise it? I’m beginning to get a handle on my COD, and the numbers are staggering, especially when I’m tempted to apply a P/E multiple to the answer!
But other queues may not matter so much. On my Kanban wall I have a “Proposed” column preceding “Prioritised” and it’s my job to move items between the two. I don’t lie awake feeling overwhelmed by the large number of proposed items – in fact quite the reverse: it feels good to deny attention to work (even whole projects) that would only add delay to work actually in progress. Is the movement between the two columns push or pull in nature? Probably a bit of both, but it’s one part of the process that won’t get reduced to a system of rules – the sequencing and regulation of work going into the process is far too important for that, and I have the book to thank for giving me a fresh perspective on my personal responsibilities toward both the process and the end result.
Use CFDs to monitor queues (p71)
Cumulative Flow Diagrams (CFDs) can be done independently of Kanban but they make most sense done together – just log each day the number of work items held in each column and chart cumulatively over time – easy! What does my chart reveal? I work a pattern of alternate weeks, one week with the team in Budapest and one at home and this is reflected very clearly in the chart. Most re-planning happens when I’m in Budapest (near both team and customer), leading quite naturally to a 2-week cadence for the whole team. The CFD does hint at the cost of being apart and we work hard collectively to mitigate it, but my data collection gets a little patchy when I’m away so I haven’t properly quantified it yet. I check the CFD regularly to measure lead times, to look for any signs of growing bottlenecks that aren’t already glaing at me from the wall, and I plan to use it as a presentation tool in future management meetings.
It’s nice to discover that one can monitor lead times so easily and I’m prepared even to read some predictive power into the chart without ever requiring development estimates. In fact estimates have become yet another thing to be added the ever-growing list of supposedly indispensible things that I’m simply not missing. And let’s face it: so often they’re rubbish anyway!
Create [decentralized] systems to harvest the early cheap opportunities (p40)
Understanding decentralisation and delegation is especially important when running distributed development. Here’s a technical example (though the point isn’t the technique): I don’t (can’t!) review every line of code that gets committed but it is easily decentralized. Not only can developers review each other’s code, but my loathing of duplication in code has been communicated strongly, along with a counterbalancing worry about breaking working code without economic justification. As a result, the kinds of refactorings that lead to a smaller codebase and consequently to a smaller maintenance headache happen regularly without my direct involvement, and (thanks also to investments in unit tests and a CI system) seemingly without too much pain. But is this really a “cheap opportunity”? Yes, one has to be concerned about overdoing the up-front investment, but in our case it has already made for a more comfortable and productive environment and I’m happy that the pay-back period is short enough to make this a no-brainer.
Onwards and upwards
All of this has been drawn from or prompted by just the first three chapters, there being nine in total. Reinertsen goes on to discuss variability, batch sizes, WIP constraints, controllability and feedback before taking an interesting turn with a chapter on decentralisation, drawing heavily from military theory. All of it is excellent, some of it very quotable, some of it very valuable reference material (and no less readable for that). I make no apologies though for emphasising the core concept Don surely intends to keep at the fore as we continue with the rest of the book.
Nits to pick? Only one springs to mind, and it’s not a problem, just a minor missed opportunity. It follows from the book’s analysis of the economics of the timing of decisions that an un-made decision has real economic value, but this could have been made explicit. A link to Real Options Theory would have been very nice here, and it might have informed some of the later parts of the book. I have a vague recollection that Real Options do get mentioned, but I couldn’t find it in the index.
I have two concluding remarks to make. The first is about Kanban, and it is to restate a comment I made on one of the mailing lists: implementing Kanban was undoubtedly one of my better professional decisions in a 20-something year career as developer, project and program manager and now the senior IT guy in my new organisation. The second is about the book: quite simply it’s brilliant; buy it!