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?
“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.)
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.
In Lean Software Development Mary & Tom propose that software teams be motivated and empowered by having the financial impact of their decisions made visible to them. And elsewhere on various email lists I’ve seen discussion of the possibility of assigning a dollar business value to each feature/story. I think that in principle these are both good ideas, and I said so to Clarke last week.
Clarke raised a very good objection: Many, if not most, features have no value outwith the context of their release; how can they be assigned an individual value when they cannot stand alone?
Perhaps the answer can be found by subtraction? Assume we can assign a dollar value to the release as a whole, and suppose also we can calculate the gains and losses of delivering it earlier and/or later. Then maybe we can also calculate the loss in value the would occur if we shipped the release without feature X? Would this figure make sense as a kind of ‘derived value’ for the feature?
And finally, is there any merit in assigning a dollar value to each story anyway? Perhaps we should be content with an overall value for each release, and calculate variants on that only if the scope or release schedule are threatened…
One of the main planks of lean thinking is the elimination of waste from the process of delivering value to the customer. Hal Macomber writes a very interesting piece about waste in communication.
When applied to software development, this idea fits very well with the agile view that interaction and collaboration are to be valued more highly than documentation, for example. In Lean Software Development Mary & Tom Poppendieck classify the muda of document hand-off under Ohno’s original heading of extra processing steps, and I tend to agree. But maybe Hal is right, and Poor Communication (not listening, not speaking) genuinely is a new category of waste…
The more I think about it, the more convinced I become that selling agile at all is a mistake. Certainly as a coach/manager, what interests me most is the ‘process’ side of things, and agile is always an interesting and rewarding approach for both me and (I hope) the software team. But what interests my bosses is more often the business value delivered to the user base.
I’ve never been someone who believed that it works to simply plonk a methodology onto a team straight from a book. Every team is different, and every business is different; enforcing conformance to some pre-determined monolith is likely to bring out as many minuses as plusses. And I believe that’s true of the agile methods just as much as it is of the heavyweight ones. What’s more, the successes I’ve been associated with have all been due entirely to having the team grow their own processes – gradually, incrementally making the changes required by the current situation. Only when the current way of working is shown to fall short in some respect does the team call a review and work out a different approach. There is never any change simply for the sake of it.
Of course the agile movement directs and informs my thinking, and hence my coaching and management styles. And all of the teams I’ve coached have become increasingly agile over time, without any of them ever consciously adopting a ‘book’ method. The stakeholders get to learn that iterative and incremental delivery is better for everyone, that feedback loops must be short, that quality helps the team go faster, etc etc. But most will never hear the words ‘agile’, ‘SCRUM’ or ‘extreme’.
In the future though, I do expect I’ll be using the word ‘lean’ a lot…
Andy Lawrence and I are lucky enough to have been selected to run a workshop at XPday Benelux in November this year. The session will explore the ‘lean’ concept of muda (waste) in the context of software development processes. Should be great fun!
A couple of weeks ago I finished reading Gemba Kaizen by Masaaki Imai. Just like all the other books on lean manufacturing, I found it extremely rewarding and thought-provoking, while at the same time being somewhat longer and more repetitive than I might have wished (the second half comprises an interminable list of case studies, many of which add very little to the value of the book).
The main idea I took away from the book was that of 5S. This is basically rigorous and institutionalised house-keeping (translated as Sort, Straighten, Scrub, Systematize, Standardize). The idea is that an untidy or disorganised workplace can contribute significantly to reducing the throughput of value for the customer.
Can this concept be applied to software development? I believe so. All our tools have to be readily accessible when needed. Our codebase, workspace and CM system should all be well-organised, and should contain nothing that isn’t needed to add value or promote flow. Our build should be clean and automated, and driven only from components that are CM-controlled. And when we’re working as a team, all our processes and techniques should be standardized so that each person’s actions are understandable by all. Continue reading →