Now, I am not an expert on manufacturing, but I have seen some. Software development is not manufacturing. I don't think that it's even very much like manufacturing. Manufacturing is about achieving uniformity across huge numbers of multiples and making some trade-off between the highest and the most economic rate of production of those multiples.
Software development is about making one.
I believe that software development is more like product development than manufacturing.
I'm not an expert in product development either, but I work for a company that, amongst other things, does develop products. Product development is very different from manufacturing (which we don't do), although the two are very closely related. A big part of product development is to arrive at a design that can be effectively manufactured.
Unfortunately a lot of our clients don't want you to know that we designed their products, so I can't brag too much. Which is a shame as a lot of them are waaaay cool. However, this flier[pdf] is public and describes one episode of product development. The flier mentions PEP, our process for developing products. As a deliberate policy we try to keep the processes that we use to develop products and the processes we use to execute software development projects as closely aligned as possible.
Both are iterative. Both involve exploration. Both are adapted to circumstances while maintaining certain principles (such as actively managing risk). Both have delivered a very high success rate over many, many engagements. So I feel on fairly firm ground in claiming this similarity between software development and product development.
As Steve Freeman points out, by a strict Lean interpretation of the manufacturing school product development looks wasteful. And it is. And that's OK because it isn't manufacturing. The economics and the goals are different.
Its worth noting that the highly-publicised Lean successes seem to be concerned largely with operational activities: never-ending, on-going care and feeding of an existing system. To the extent that your activities are like that, a more Lean approach is likely to work well for you, I think. I've yet to hear of a success story of strict Lean (no iterations, no retrospectives, all the rest of it) run in a project setting to produce a new product.
I don't say it can't be done, but I've not heard of it. If you have, I'd love to.
7 comments:
I think "Lean" is becoming a bit of a strawman in this round. I'm not convinced by a "Strict Lean" that rejects retrospectives and iterations (at least for release). I suspect this is to do with early enthusiasm and discovering the boundaries. That said, there are parts of the development process that should be mechanical and reliable.
Steve, which bit the "strict Lean" are you unconvinced of? That people are doing it? Some claim to. That Lean experts recommend it? Some seem to.
I'm certain that it doesn't work well, but I'm not sure how many people do it in practice. And I don't know how many believe it enough to try...
This one is way cool too!
Health care isn't manufacturing either and yet this is one of the major movements in Lean today.
What carries most is the essence of problem-solving, engaging everyone, continuous improvement, and a focus on quality from the perspective of the customer.
I would suggest that there is a lot of confusion caused because "Lean" as described by the "kanban software movement" is quite tool-focused and assuming a maintenance type situation. This is still very useful because there is a lot of "business-as-usual" activity out there, definitely more so than new product development.
But looking at something that is not manufacturing and dropping in manufacturing tools without thinking is not "strictly Lean", it's strictly LAME.
Yes, the Kanban crowd are making the most noise so getting the most attention, I guess.
That community seems to have a really sad failure mode whereby the strong impression is given that if only you're clever enough about scheduling the work everything will work out fine and what the work is or how it's done is largely irrelevant. Demur to this and one can expect a slap in the face with Little's Law and a vague accusation that you're stealing from your customer by deliberately committing Waste.
Of course some people say stupid things when they're picking up a new idea that seems to work. But the people I know in the "kanban crowd" are a bit more sophisticated than that. Sometimes this discussion feels a bit like something out of The Life of Brian.
Post a Comment