business processes

The excellent book Lean Thinking by Womack and Jones lists the primary processes of any manufacturing business as product development, order-taking and manufacturing. Later in the same book they spend a great deal of time analysing the servicing/parts process of Toyota, without relating it to the earlier three main processes. And they later do the same with sales and distribution.

So let’s assume there are six main business processes – how would these relate to the activities of a software production team? I guess the bulk of the work they do is in the product development category, while the build and test activities relate to manufacturing. Order-taking relates to requirements gathering at the highest level (pull/kanban = story-card), and sales and distribution are probably not relevant here.

That leaves servicing/parts, which I would like to map to help desks and bug-fixing. But in hard engineering, the supply of spares is a manufacturing job, while in software the supply of bug-fixes is more of a design job. In a sense, the bugfix often creates a custom product, since spares are usually not feasibly distributed. (I need to come back to this another time…) So for now the key observations are that the build/test processes equate to manufacturing (and are therefore eminently suited to kaikaku and kaizen activities), while the remainder of software development is a product development activity.

Interestingly, in all of the case studies in Lean Thinking, the usual means by which design/development departments are ‘leaned’ is by creating small co-located multi-skilled teams and leaving them alone with a customer representative until they’re done! So if we want to apply lean thinking to software design, we have a more or less clean slate!

lean software development

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.

everything in its place

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

entrenched positions

It seems to me that one of the principal reasons for the apparent rapid rise of agile methods in software development is the romanticized battle between programmers and managers. Spend any time reading any extreme programming discussion group, for example, and eventually the topic of adopting XP in the face of management resistance will crop up. Agile methods, and XP in particular, would appear to be the saviour of the oppressed programmer; finally the evil tyranny of the waterfall and the heavyweight methodology are crumbling in the face of guerilla resistance from programmers who knew they were right all along! Or that’s how it seems to them.

Does the extreme (sic) zealotry of the programmers represent years of pent-up frustration with the situation in which they found themselves? Do they blame management for controlling them, for keeping them strait-jacketed in heavyweight methods for so many years? If that’s the reason, why were such methods of control deemed necessary in the first place? Two words: manufacturing metaphor.
Continue reading