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!