malvasia bianca

Driven by my recent mania for all thing lean, I just finished Lean Software Development, by Mary and Tom Poppendieck; I wish I’d read it a few years ago. I’d been aware of it for some time, but I passed it over when doing my initial tour of the agile literature. I had assumed that the book was proposing a methodology; back then (and to a fairly large extent, even now) I had no desire to learn about more methodologies. Learning about one or two can be useful, to see concrete examples of how people but the basic ideas into practice, but beyond that, I didn’t see the point. (Especially since I have yet to hear about anybody other than their founders using any agile methodology other than XP or Scrum.)

It is, however, not a methodology: it’s instead a book with a range of suggestions for what software development might learn from lean manufacturing. (Both authors have quite a bit of software development experience; the first author also has quite a bit of lean manufacturing experience, from her time with 3M.) As they say right at the start, software development is not manufacturing: manufacturing is about producing identical (or similar) objects as quickly and reliably as possible over and over again, while software development is about producing a single or a few related evolving products. The authors’ take on this is that software development is more like product development than like manufacturing, so they use lean product development as their inspiration. (It turns out that lean manufacturing companies do product development differently from other companies: Toyota has been better at bringing new models quickly to market than US car companies, for example, and 3M has effective product development strategies as well.)

So, while some of their recommendations were very familiar to me from the little reading I’ve done in lean manufacturing (e.g. the first chapter is “Eliminate Waste”), others weren’t. “Set-Based Development” is a good example: they recommend that, when developing a product, you explore the solution space for your various constraints by constructing a large number of alternatives meeting each constraint, and then see if you can use those alternatives to come up with a design that meets all your constraints. This is in contrast to “point-based development”: there, you start with one target solution, and repeatedly alter it based on feedback until everybody is satisfied. The authors claim that this takes a lot longer to reach a solution than the set-based approach, despite the fact that many fewer options overall are considered.

There are some useful counterpoints (and, at times, counterweights) to XP. I should spend some time thinking about the relation, if any, between the set-based approach and XP spikes, for example. And XP depends on a (to me) almost mystical notion of a Customer making a certain class of decisions; this book spends more time looking at what goes into decision making. The “Empower the Team” section also provides a nice collection of tools (“Self-Determination”, “Motivation”, “Leadership”, and “Expertise”) which acknowledges certain dynamics more explicitly than XP does. Given the lean focus on quality, I was somewhat surprised that there wasn’t more of a focus on testing – I’m used to that being focused on (productively, I should add) to an almost obsessive extent in agile books. And this book spends much more of its time further away from the software developers than many agile books do, e.g. in the discussion of contracts. Or maybe that’s my selection bias coming into play – I have more software development context and responsibilities, so I focus my readings there.

I’m not sure what concrete effects it will have on my work in the short-term; for now, I’m going to continue reading about lean, waiting for concepts to sink in and crystallize. I imagine that I’ll return to this book in a couple of years and find specific inspirations in it, and indeed that it will have subconsciously inspired me in the interim.