silk and spinach

This week’s April meeting of the AgileNorth group was a book review. Kevin Dockerill reviewed Mary Poppendieck’s Lean Software Development and Ken Schwaber’s Agile Software Development with Scrum. We spent about forty-five minutes discussing each book, and then half and hour or so comparing the two methods, particularly in relation to applying them in Kevin’s own small team.

While reading the books in preparation for the meeting, Kevin had created a little summary leaflet for each. Each leaflet was in two parts: the first stepped through the book’s chapters picking out the main points, while the second provided Kevin’s commentary and opinion. (In the case of the Scrum book, Kevin also rated each chapter out of 10 - from which we discovered that the first half was much more to his taste than the second!) The format of Kevin’s little leaflets worked extremely well, and I would recommend this kind of approach for any subsequent book review. I particularly liked the idea of chapter ratings, which gave us an at-a-glance view of Kevin’s opinion and also highlighted the two very different halves of the Scrum book.

As the meeting progressed, the discussion moved away from the books and on to comparing and contrasting the two methods - Scrum vs. lean. I was too engaged for taking notes, but I recall some main themes emerging in the opinion of the group as a whole:

• Scrum is likely to serve well in a traditional, structured, command-and-control organisation, where strong project management and reporting lines reign. Whereas the Lean book offers a bag of tools, and so will probably appeal to more ‘fluid’ organisations.
• The mapping of software development to manufacturing is not helpful to organisations that aren’t used to growing their own processes and adapting them regularly.
• The Lean book maps specific practices from lean manufacturing into software development, without providing enough background on why those practices are appropriate.
• It seems unlikely that many software projects could go 30 days without changing their requirements; so Scrum seems to be targeted at bigger projects.

This was an enjoyable evening, made very productive by Kevin’s thorough and thoughful preparation. I’m looking forward to the next one, on May 15th!

What were your first impressions when you read these two books?

Many thanks to everyone who emailed me with details of books I missed from my lean manufacturing reading list. To pick out just a couple:

“The best source on ‘lean’ (in the broad sense) for product / software development is Reinertsen’s Managing the Design Factory. It’s fantastic. Lot of Mary and Tom’s stuff is from it.” — Clarke Ching

“Thinking Beyond Lean is about the product development model of car manufacturers and how Toyota completely overhauled their product development process, at a time when some of their competitors were starting to copy Toyota’s process. See here for a first stab at mapping the ideas in the book to agile software development.” — Pascal van Cauwenberghe

Any others you can recommend?

David Carlton emailed me to ask:

“I’d been thinking that I should read more about lean manufacturing; what are your favorite books on the topic? And am I correct in assuming that the Poppendieck book is where to start for lean software development?”

Lean manufacturing is indeed a fascinating topic, particularly in the week that Ford in the US seems to have completely failed to understand it…

I guess I began by going to the horse’s mouth to read Taichi Ohno’s Toyota Production System. After that there’s a wealth of material out there. Many of the most approachable are those written by Westerners for Westerners: such as The Machine that Changed the World or Lean Thinking by Womack & Jones, or Liker’s The Toyota Way. Others are more specialised, such as Imai’s Gemba Kaizen.

Lean manufacturing concepts - such as pull, jidoka, gemba etc - can be applied to software development with positive effect (see Lean Software Development by the Poppendiecks). However, beware of drawing parallels between software development and manufacturing. In a software production business, the “manufacturing” step is largely about packaging and burning CDs etc, whereas software development itself is what folks in hard engineering call “Product Development” or “Engineering”. Toyota’s approach to product development is often termed Knowledge Management or the Learning Organisation, and their performance there is perhaps even more startling than it is in manufacturing. Yet there’s little approachable material available. I began with Kennedy’s Product Development for the Lean Enterprise.

There is a growing body of information available about knowledge management and learning organisations - I’m currently working my way through Takeuchi & Nonaka’s Hitotsubashi on Knowledge Management. However, with the exception of influences in the Poppendiecks’ book I know of very little material mapping these concepts directly onto software development.

(Inevitably my reading has been patchy and is woefully incomplete. So please let me know if you’ve read books I’ve missed here - particularly any that deal more explicitly with mapping software development to knowledge management and learning organisations.)

In comp.software.extreme-programming yesterday Laurent Bossavit produced out of the hat the following quote from Donald Finkel’s book Teaching with your Mouth Shut:

“No thought, no idea, can possibly be conveyed as an idea from one person to another. When it is told, it is, to the one to whom it is told, another given fact, not an idea. The communication may stimulate the other person to realize the question for himself and to think out a like idea, or it may smother his intellectual interest and suppress his dawning effort at thought. But what he directly gets cannot be an idea. Only by wrestling with the conditions of the problem at first hand, seeking and finding his own way out, does he think.”

This is Laurent’s support for the idea of learning the craft of programming via kata, and for me it hits the nail right on the head. Finkel’s method seems also to be supported by NLP (neuro-linguistic programming) philosophy, in which the meaning of what one person says is defined as the impact it has on the listener…

For years now I’ve been looking for that one book that would provide good background reading material to help teach object-oriented software development. Currently I’m reading Extreme Programming Adventures in C# by Ron Jeffries, and I think this book comes closest to fitting my needs. I’m sure not everyone will appreciate the very informal style, in which Ron takes us along for the ride while he develops a new application and learns a new language. But I find the lessons he learns along the way - and the development process he promotes - fascinating. I have yet to find a better introduction to object-oriented design and development.

Sometimes memes strike me as simply childish. But here’s one (via The Vision Thing) that may reveal just a little about the people taking part. The meme is this:

1. Grab the nearest book.
2. Open the book to page 123.
3. Find the fifth sentence.
4. Post the text of the sentence in your journal along with these instructions.
5. Don’t search around and look for the “coolest” book you can find. Do what’s actually next to you.

I read that blog post while sitting on one of the sofas in our conservatory, which we’ve reserved as a child-free adults’ reading room. On the cushion next to me was the book I’m currently reading - Getting Things Done by David Allen. Spookily, the book was already open at page 123, which is precisely where I had read upto yesterday. Counting the sidebar, the fifth sentence reads thus:

“The in-basket is a processing station, not a storage bin.”

This is really one of the central messages of the GTD school of self-management. By removing the pressure created by having a full in-tray, Allen claims we can release our creative energy and thereby accomplish much more. I’m very optimistic that this system will work for me, and I’ll be implementing it during the upcoming Easter break. I’ll let you know how I get on…

I must get myself a copy of Rules of Thumb 2! (I always wondered why my potato salads never turned out quite right…)

I recently finished reading Lean Software Development by the Poppendiecks. This book has a lot to offer in terms of practical tools to help software coaches and teams “go lean.” But I was left with an uneasy feeling at the end, which I think may be attributable to two (related) causes.

First, the approach and tools are presented as if they somehow represent “the” mapping from lean manufacturing into the software world. But surely the seven principles and twenty-two tools are only one way to perform leaner software development. And while the authors never suggest that these are in any way canonical, one is left with an impression that absolutely everyone should start from this tool-kit, and that to not do so would be to fly in the face of Toyota wisdom.

Second, the metaphor used by the Poppendiecks to relate software development to manufacturing is not explored. Can software development really be treated as an analogue to manufacturing? I believe that there is some combination of the “classic” set of manufacturing business processes that can be mapped onto software development. But that mapping is non-trivial, and when complete will not necessarily yield the picture painted by this book.

Based on Clarke’s recommendation I’ve just finished reading Crucial Conversations. And I have to agree - this is a terrific book. It contains three or four critical ideas that help to make those difficult, emotional conversations a lot more easy to understand - and hopefully then to master…

I must admit, though, to being somewhat irritated by the cutesy names the authors use for the various techniques - ABC, CRIB, STATE my path etc. Useful and important as they are, I won’t remember them in that form, so I’ll need to find another set of names for them.

While reading, I found myself comparing it to the equally excellent Getting to Yes by Fisher, Ury and Patton. Some of the same ground is covered in both books (getting away from emotions and back to basics), and I would certainly recommend reading both together. So now, when faced with an important discussion, should I treat it as a crucial conversation or as a negotiation? Or both?

On Clarke’s recommendation I just finished reading Critical Chain by Eli Goldratt. This is another of his “novels”, in which this time he applies the ideas of TOC to project management. I liked the book’s use of the TOC thinking tools. And I also liked the discussion in the last couple of pages, about using dollar-days as the unit to measure investment - although I need to think about it a lot more before I’ll come close to understanding it.

The main thrusts of the book are that managing slack at the project level is better than managing it per task, and that the critical path/chain is the bottleneck in a project, and therefore needs to be protected. Again, I need to think about this a lot before I can fully see how - or whether - these ideas will apply to an agile software project…