15 Lean Failure Lessons from Software Development, 1/3

Reading the Atlantic Monthly article The Coming Software Apocalypse helped me see the question of “Why do lean transformations fail?” in a new context. This question is usually preceded by statements like “95% of lean transformations fail” and some prescriptions against failures. Nobody so far has cited a source to back up those numbers, nor do they adequately define the terms “lean transformation” or “failure.” Semantics aside, it’s true that people struggle more than they ought to in putting lean practices in place and making them stick.

What light can an article about how software is written shed on the question of why Lean transformations often fail? Quite a lot, as it turns out. This post is triple the length of a typical one, so I am presenting it as a 3-week series.

Without further ado…

Lesson #1 It’s Complicated

There is a lot to building a Lean management system. Such a system needs to operate across the entire enterprise, engage people in customer-focused problem solving and innovation, for the long-term. It requires more than a sketch of a floor, two pillars and a roof on a whiteboard, or what can be delivered in a 45 minute motivational keynote presentation. “The problem is that we are attempting to build systems that are beyond our ability to intellectually manage,” the MIT professor of aeronautics and astronautics Nancy Leveson is quoted in the article. It’s complicated, in other words. If we oversell, oversimplify and dive into Lean thinking with a lot of enthusiasm but little grasp of the what it takes to make all of the pieces work together, we are inviting failure.

Lesson #2 Blueprints Before Hammers

“Architects draw detailed plans before a brick is laid or a nail is hammered,” says Leslie Lamport, a Turing Award–winning computer scientist, “but few programmers write even a rough sketch of what their programs will do before they start coding.” In other words, software is full of bugs because programmers jump straight to writing code. People start doing Lean, whether it is A3 problem solving, 2 second improvement ideas, kaizen events, kata, value stream events, etc. before they have a clear idea of what they are building. This results in a lot of rework, backtracking, or “learning” if we are to be polite. Whether because of a lack of will or budget to invest in architects, the oversold “lean is simple” message, or just a bias for action that serves us poorly, the hammer swung without a blueprint is often a feature of Lean failures.

Lesson #3 Not Seeing the System for the Tools

Lean management requires us to solve problems, but also to be aware of the problem solving process and whether we are doing it right rather than just jumping to solutions. Furthermore, we need to reflect on why people still make mental shortcuts or fall into bad habits while solving problems, and what to do about that next. From the article

Code makes you miss the forest for the trees: It draws your attention to the working of individual pieces, rather than to the bigger picture of how your program fits together, or what it’s supposed to do—and whether it actually does what you think.

We need to use tools to deliver results, and to learn as we practice. But they can take focus away from the high-level structure of a system and its essential logic. When we don’t, we create islands of excellence that don’t connect to sustainable results, a harbinger of Lean failure.

Lesson #4 Scope Creep

According to the article, software grows without bound ,”Because it can be changed cheaply, software is constantly changed; and because it’s unmoored from anything physical—a program that is a thousand times more complex than another takes up the same actual space.”

Even when we start small, Lean thinking is difficult to practice in small, contained areas because everything is interconnected when we deliver goods and services. After a process is improved, adjacent processes must also be improved in order for the first gains to be sustainable. The scope must grow, but few management teams truly grasp their capacity to plan and execute complex projects, which by definition will run late and over budget. Projects and initiatives take up no physical space, other than as wallpaper in the war room. Failing Lean deployments tend to maximize project lists at the expense of execution.

Lesson #5 Ease of Testing Our Systems

“When we had electromechanical systems, we used to be able to test them exhaustively,” says Professor Nancy Leveson at MIT. We could think through all possible configurations and interlocks controlling train movements, put them on a few sheets of paper, and run physical trains through these configurations. We could build, test and know exactly what we were dealing with.  Lean is a system of human behaviors, which are not as reliable as electromechanical systems. We can’t exhaustively test how people will react in each new situation they encounter. When we build a lean management system, there will be bugs. If we expect people to always act rationally, we are in for a Lean failure.

To be continued.

---