Lean Software Strategies

Proven Techniques for Managers and Developers

Peter Middleton, James Sutton

• Editore: Productivity Press
• Anno: 2020
• ISBN:
  9781000077575
• Edizione: 1
• Argomento: Betriebswirtschaft
• Categoria: Produktion

Lean production, which has radically benefited traditional manufacturing, can greatly improve the software industry with similar methods and results. This transformation is possible because the same overarching principles that apply in other industries work equally well in software development. The software industry follows the same industrial concepts of production as those applied in manufacturing; however, the software industry perceives itself as being fundamentally different and has largely ignored what other industries have gained through the application of lean techniques.

Part One

What Kind of Industry is Software?

1

There’s Three Kinds of Industries

Over the course of its eventful history, industry has evolved through three paradigms. It began in an embryonic stage now often called craft production. Later, it metamorphosed into something quite different, which we now call mass production. In recent years, it has moved on to yet another incarnation, called lean production.

At any given point in time, the majority of enterprises in any particular industry will be operating under one of these three paradigms. Joel Arthur Barker states, “A Paradigm is a set of rules and regulations (written or unwritten) that does two things: 1) it establishes or defines boundaries; and 2) it tells you how to behave inside the boundaries in order to be successful.”¹ We’ll discuss how the main paradigm at work in an industry largely determines its business effectiveness. The force that drives industries to evolve through these stages is that each subsequent paradigm is more effective for achieving a company’s business goals than the previous one.

Craft production relies almost totally on the skill of individuals. There is little or no standardization or process definition. Craft production’s major practices are driven almost totally by the interests of the owners, with little thought for the concerns of the workers or the needs of the customers (though in a craft-production business, the workers are often also the owners, so in that case and sense, are considered).

Mass production places its greatest reliance on standardization and process rather than individual skill. Yet, its interests still lie almost exclusively with the owners . . . who, by the time a business has entered this paradigm, have usually gained possession through their investment of funds rather than by hands-on involvement in day-to-day operations.

Lean production shares some characteristics of each of the previous stages but compensates for their weaknesses and adds new strengths of its own. It greatly broadens the focus to include all stakeholders; owners and investors to be sure, but also customers (often even more strongly than owners), employees, and public concerns. More importantly, unlike craft and mass production, lean production removes waste from—and continuously improves industrial processes by—effectively utilizing employees, equipment, and capital to produce and deliver products that satisfy each customer.

In any given business, you may see aspects of more than one paradigm at work. Nevertheless, one paradigm will be dominant, and the characteristics of any others present will be muted in comparison.

Beware of How and What You Measure—A Sad Tale

In the last few years, all sorts of people have become very interested in measuring the condition of software organizations. The measurers include customers, academics, regulators, and governmental bodies. Though we are speculating on this, it seems likely that one of the reasons the measurers come from these groups, rather than from the software businesses themselves, is because the measurers are also the people who have been the most left out and poorly served by the software industry to date. They have a legitimate interest in finding out what’s going on.

Most types of software assessments today look for process maturity. A few evaluate technological sophistication. Unfortunately for both the businesses and the measurers, as we shall see, such criteria are practically useless for answering the questions that are most important to either the measurers—such as “Will the software organizations serve our true needs?”—or the software organizations—such as “Will our organization meet its financial goals?” “Will it satisfy our customers?” and “Will it be able to attract and retain the workers we need?”

What all sorts of industries other than software have discovered is that performance on these important questions correlates much more closely to industrial paradigms than to process maturity or technological sophistication. Once a company identifies its industrial paradigm, it develops a better predictive insight into how well the industry (or individual enterprise) will perform and what its major weaknesses will be. It stands to reason that this applies to software as well.

This brings us to a sad tale that demonstrates the old maxim that measuring the wrong things leads one to the wrong conclusions. In the mid-1980s, Jim Sutton watched at a slight distance (knowing some of the people involved) as an industry project broke all sorts of new ground in processes and technologies.² Even by today’s standards, you could consider this project advanced. The project’s product was an information-processing system. The scope was twenty developers for two years. Because of its size, the project institutionalized all its practices. Project management collected metrics and analyzed them to help them improve their decision making. The project used strong, tool-based configuration management that not only protected files but also had procedures for enforcing developer roles. It used a CASE (Computer-Aided Software Engineering) environment with a graphical interface: Unlike many early CASE environments, this one did its job as advertised.

The project trained everyone consistently and sufficiently. It enforced common methodologies, and applied consistent standards and structured peer reviews to ensure the quality of the products. It used structured data flow analysis to develop its requirements. As you probably know, this type of analysis is still in use as part of several object-oriented methodologies; and when employed in the proper context, is still considered an appropriate choice for this type of system.

In today’s terms, we’d say the project was “repeatable,” “defined,” and even in many respects “managed” (using the terms of the SEI CMM³). If an entire company followed these practices, it would be at the very doorstep of a CMM level 4 out of a possible 5. And all this happened long before the earliest widespread CMM industry assessments showed that most software organizations were only at SEI level 1, i.e., that their processes were usually almost completely undefined.

From the beginning, the project personnel made trips to the customer’s site to discuss the customer’s needs. The first major design review occurred a year and a half into the two-year project. It was scheduled to last three days. The team was confident that the thoroughness of its work would make the review a mere formality. They were set for rapid coding and testing, to easily meet their scheduled delivery date.

A few hours into the first day of presentations, the customer interrupted the presenter: “You have decomposed my requirements in a way that cannot be allocated to the hardware architecture of my system. Come back when you have something that can possibly be implemented.” The project team was thunderstruck. At first, they couldn’t believe the customer knew what he was talking about . . . but a little more investigation showed he was right. They could not implement the proposed system.

What followed was an astounding example of process-maturity reversion. With only six months left to go before scheduled delivery, the project let go of most of its people. It then assigned its two best developers as “superprogrammers” to “get the system out.” After six months of eighty-plus hour weeks in a dark room with an unending supply of prepackaged pastries, they succeeded. The customer accepted the new system, though he was not happy since his confidence had been largely shattered at the review.

The postscript to this tale is that, over time, it became clear that the delivered system was incomplete and that the project had still overlooked several crucial (to the customer) but unstated requirements. The system was also practically unmaintainable except by the superprogrammers, who had—of course—moved on to other projects and were no longer available. Shortly after taking delivery, the customer abandoned the software. The organization lost the next contract, and the next, and never received another contract from that source. They forever lost a good customer who had given them a lot of lucrative business in the past.

IThe ndustrial Paradigm Determines the Business Effectiveness

If having a mature process and using high technology leads to business success, as is assumed by most software-assessment approaches, the sad tale project would have been one of the major success stories of the 1980s. Instead, it was one of the major disaster stories in the history of the software profession. Why? We only need look at other industries to find the answer.

Process maturity and high technology as standards for measuring and assessing industrial capabilities have never assured long-term success. They are usually not even particularly good indicators of short-term success. Detroit had mature processes in the 1960s, yet it lost much of its market share to the greater value and quality of the Japanese automobiles of the 1970s and 1980s. Detroit’s famous robotic-automation and other technology experiments of the latter period did nothing to help it reclaim its market or profitability. Even the German automaker Porsche’s technological prowess did not shield it from a serious slump from 1989 to 1992, in which it lost 72 percent of its unit sales.

Japan’s superior achievements in autos during that same period were based not on process definition nor on high technology, but on having a more powerful idea of what industry itself is all about. Indeed, from the time that Japan laid its foundations for beating Detroit (beginning in the 1950s), Japan’s technologies were largely inferior to those of the U.S. manufacturers: “The war-ravaged Japanese economy was starved for capital . . . massive purchases of the latest Western production technology were quite impossible.”⁴ Japan could not rely on technology to gain its advantage. Detroit could not count on technology to keep it. Detroit began stabilizing its business base against the Japanese only when it started adopting their lean worldview and practices.

You win or lose the business game through your choice of industrial paradigm. Given a level playing field, a mass producer will beat a craft one, and a lean producer will beat them both. This result is practically independent of the producer’s relative process maturities and technologies. “Lean production vs. mass production requires: ½ the human effort in the factory, ½ the manufacturing space, ½ the investment tools, ½ the engineering hours, ½ the time to develop new products.”⁵

This leaves the legitimate ques...