I’ll start by coming clean. I’m more guilty than most. I read the Womack and Jones books on Lean Thinking. Goldratt’s the Goal. The Poppendiecks lean software stuff. David ‘Kanban’ Anderson. I loved them all. I ran into the office looking for “waste” everywhere. Show me the next constraint. How to get flow? To all those I inflicted this bullshit on, I’m sorry. Really sorry.

The problem is, what people do in manufacturing and what people do in software development, is pretty much a polar opposite. Even that doesn’t really cover it. Opposites after all have something in common, some axis along which the two extremes can be placed upon. Not then apples and pears, more apples vs. beach towels.

I’m guessing at this point I risk losing you. What is this guy ranting on about? To borrow a phrase. It’s the work stupid!

Manufacturing is about the production of finished goods. Usually at scale. These are physical objects. Of course the lean guru will talk about one-piece flow. Different products from the same production line. Different models of car. Different vacuum cleaners. Never a truck, followed by a smart phone, followed by a beach towel.

Lean is a reaction against the status quo. A fight against the efficiency driven, economy of scale, batch style of thinking that characterises the manufacturing industry. It is reductive. Their work item is a finished good, bound by the laws of physics. Inventory piles up. Failure gets binned. Every type of Muda is visible. Takt time can be measured. Each is independent of the others. You can touch, smell, feel, see each finished work item.

Therein lies the rub. The key assumption that sits behind all of this is deeply flawed. That a request for work entering a software development team is equivalent to a request from a customer for a finished good entering a factory. Clearly if this assertion can hold the pay off is huge. Suddenly the software development community can tap into a wealth of hard won knowledge about optimising the flow of work within manufacturing. Books can be written. Conferences booked. Careers made.

Mixing my metaphors for a moment. What we thought was the shoulder of a giant, turns out to be a house of cards.

Software development isn’t constrained by physical laws. You can’t pick it up in your hands and weigh it. You can’t see it. I won’t get started on what it does to statistical analysis. Each work item has a mass of dependencies on all others. Even the idea you can reduce software development to an atomic unit like a user story is deeply flawed. Software is inherently holistic in nature.

The only real connection I can now see to manufacturing is that the software we write has more in common with the factory than with the finished goods produced. The software being robots that produce something called a user experience. One customer getting a series of interactions that make up our “product”. Perhaps but I’m clutching at straws. Either way this looks very unlike anything we see today.

So how bad is it? For now we have a lot of very clever people keeping the assumption in place. The focus is on making our work items fit the manufacturing model. That way we get some value at least from the model. But it will get harder and harder to maintain the fallacy. Everyone can see the cracks appearing. My advice is simple look at the work. Love it and learn to see it. Challenge every assumption about it. After all if you run your software developments teams using a manufacturing mindset you’ll end up with a factory feel to the work, perhaps we can do a whole lot better than that?