15 Lean Failure Lessons from Software Development, 3/3

By Jon Miller Updated on October 29th, 2017

Some say that as many as 95% of Lean transformations fail. How could this be? An article The Coming Software Apocalypse in the Atlantic Monthly about the software development world offers insights. This post is the third of a 3-part exploration.

Lesson #11 Invisible Complexity

Unlike physical things, software is invisible. So is the complexity. This makes problems invisible also. A tires that is flat looks flat, while broken software looks like any other software. Lean fails when problems are not vigorously exposed, seen but dismissed, or hidden.

Lesson #12 Broken Escalation Systems

How would it work if we connected the andon lamp,  or the signal for an abnormality, to the same power source it was supposed to alert us was out? We would never get the signal. The situation with software is that the failsafes and problem alerts are also software, which are buggy and not fail safe. It would be like putting our least reliable, least bought-in, most traditional, looking-for-another-job-and-don’t-care-when-I-get-fired managers at every point in the problem escalation chain. Lean wouldn’t last long.

Lesson #13 Distance from Problem Solving

We need to be able to ask people, “What problem are we trying to solve?” and get the same answer if we want to build a lean management system together.  In the case of software, programmers are too wrapped up in writing instructions for a machine and getting their code to work. “The problem is that software engineers don’t understand the problem they’re trying to solve, and don’t care to,” according to Leveson, a software-safety expert at MIT. They are one or more steps removed from the problem that the software is intended so solve. The more distance we put between us and our problems, the less likely we are to understand and solve them, a recipe for Lean failure.

Lesson #14 Create Tools that Make Coding Unnecessary

Eric Bantégnie, founder of Esterel Technologies, a developer of tools for building safety-critical software, observes “I’m not sure that programming has to exist at all. Or at least software developers.” For him a software developer’s role was to create tools that removed the need for software developers. He likened it to building cars by hand, as we did 100 years ago, because our engineers had yet to build fixtures, work-assist devices, and power tools. Software at 10,000 lines of code could be crafted manually but at 30 million lines, no longer. The parallel to Lean management is very clear. The role of leadership in successful Lean transformations is to build adopt and adapt the TPS tools and models that reduce complexity, provide people with resources they need to succeed and build a base of reusable knowledge specific to the organization.

Lesson #15 Why We Don’t Plan for Failures

On the question of why people choose not to make complex software reliable in so many areas even though we know how, the article offers the insight that “human intuition is poor at estimating the true probability of supposedly ‘extremely rare’ combinations of events in systems” operating at a very large scales and volumes. We overestimate our chance at success, in other words. The code faithfully implements the intended design, but the design failed to account handle a particular ‘rare’ scenario. Lean management that grows complacent, stops challenging itself, and does not leave capacity to respond to unforeseen changes is apt to fail.

Hopefully a few of these insights will spark conversations that lead to avoiding these causes of Lean failure.

Have something to say?

Leave your comment and let's talk!

Start your Lean & Six Sigma training today.