Email	Print Reprint
	add to:
	Del.icio.us Digg Google Furl	Slashdot Y! MyWeb Blink

About the time of the 1980 NBC documentary "If Japan Can, Why Can't We?," I was the system manager of a videocassette manufacturing plant, and our Japanese competition was selling superior products at much lower prices. We knew we needed to make dramatic changes or close up shop, but we didn't know what to change.

As far as we could tell, we were doing everything right. Optimized forecasting methods determined economic lot sizes, and the latest manufacturing requirement, planning software, launched the plant's daily schedules. A sophisticated computer system analyzed our quality control results and process parameters to pinpoint the causes of defects.

We did have some quality problems, and it took a month to fill most orders. Special orders were another matter, however: The division vice president would often call to expedite them for important customers.

We moved in-process videocassettes from one workstation to another on carts, and we used a lot of carts. There was never enough room to store them all at the next workstation, so carts full of inventory would get misplaced. Videocassettes piled up in front of testing stations. Whenever a process drifted out of control, it took a while to discover that we were producing a marginal product. We had plenty of rework stations.

All in all, we had about a month's worth of work-in-process inventory. At the time, we blamed our inability to rapidly fill orders on bad forecasts from marketing. Later, we were surprised to learn that the real culprit was our in-process inventory. Today, it's a truism that the average supply-chain shipping time is about the same as the average level of inventory in the chain.

Lean Production
In 1935, Kiichiro Toyoda, the son of brilliant inventor Sakichi Toyoda, founder of the Toyoda Spinning and Weaving Company Ltd., dreamed of providing vehicles to the general public. After a hiatus imposed by World War II, he chartered Taiichi Ohno to design an efficient production system for high-quality automobiles. Over the next 30 years, Ohno developed the Toyota Production System (the d morphed into a t when the company reached the import stage), now known worldwide as Lean Production (see The Machine That Changed the World: The Story of Lean Production, by James P. Womack, Daniel T. Jones and Daniel Roos, New York: Rawson and Associates, 1990). The foundation of Ohno's system is the absolute elimination of waste in both product and process.

Although Ohno learned from Henry Ford's pioneer work in assembly-line flow, he didn't have the customer base to imitate the U.S. practice of manufacturing in so-called "economic," or large lot sizes. Ohno was captivated by U.S. supermarkets, however, where a small quantity of every product was placed on shelves that were rapidly replenished. He decided to place inventory "supermarkets" throughout his plant, thus dramatically lowering the "waste" of in-process inventory. He named these inventory supermarkets kanban.

Because Ohno's automobile manufacturing plant evolved from the highly successful Toyoda spinning and weaving company, he already knew how to avoid making a bad product. Sakichi Toyoda had invented an automatic shut-off mechanism that stopped a weaving machine the minute it detected a flaw (such as a broken thread). Ohno expanded this concept into car manufacturing, insisting that each automobile part be examined as soon as it was processed, stopping the line immediately when a defect was found.

To maximize product flow, workers who knew the process—not desk-bound engineers—created standard work sheets, which included cycle times, kanban shelf space for each item and multilevel workflow. Production workers operated like a relay team, handing the baton to the next person in line. This "just-in-time" system required close teamwork and exquisite choreography: When the process stalled, teammates were expected to help each other reset a machine or recover from a malfunction.

Ohno's aggressive elimination of waste led him to the twin values of rapid product flow and built-in quality. Over time, he discovered that these two values led to the production of the highest quality, lowest cost, shortest lead-time products available.

Total Quality Management
At about the same time Ohno was revolutionizing auto production, American management guru W. Edwards Deming was teaching quality management in Japan. In fact, the Total Quality Management (TQM) movement that Deming spawned can't be separated from Ohno's Lean Production. Deming's photo hangs in the lobby of Toyota's headquarters—in a larger image than that of founder Sakichi Toyoda. Deming's "profound knowledge," Ohno's "lean production" and "flexible manufacturing," and Toyoda's spirit of creativity and invention have inspired a powerful management movement that revitalizes the business model for optimal efficiency.

Deming maintained that poor quality was engendered by systems that thwarted the workers' desire to do good work. He taught the Japanese managers how to empower production workers to investigate problems and systematically improve business processes, stressing teamwork and long-term, trust-based connections with suppliers. Deming's vision emphasized a culture of continuous improvement of both process and product.

Paradigm Shift
When we first heard about Lean Production at the videocassette manufacturing plant, we thought it was a hoax. Get rid of safety stock, don't run machines at full capacity and have suppliers deliver small lots on a daily basis? Though it went against the wisdom of the day, we were desperate enough to give Lean Production a try. In the end, it saved our business.

The critical step was a carefully planned changeover from push scheduling to pull scheduling. We decided that we couldn't do it partway—we had to switch cold turkey, over a weekend. The entire plant held its collective breath as the pull system went into effect, but the workers knew what to do—they had developed the methods themselves. The first week packout accuracy was 92 percent, and it improved from then on. We were able to fill special orders in two weeks, so the vice president could stop expediting them. We had lots of extra space, and quality had never been better.

Simple Rules
In a January 2001 Harvard Business Review article titled "Strategy as Simple Rules," Kathleen Eisenhardt describes how smart companies thrive in a complex business environment: by establishing a set of rules that define—not confine—direction. She suggests that instead of complex processes, simple communication strategies can best enable people to seize fleeting opportunities in rapidly changing markets.

The basic practices of Lean Production and TQM might be summed up in these 10 points:

1. Eliminate waste.
2. Minimize inventory.
3. Maximize flow.
4. Pull from demand.
5. Meet customer requirements.
6. Do it right the first time.
7. Empower workers.
8. Ban local optimization.
9. Partner with suppliers.
10. Create a culture of continuous improvement.

These rules, adapted to logistics, customer service, healthcare, finance and even construction over the last two decades, have proven their worth. More recently, they have found their way into software project management.

Lean Programming
Lightweight methodologies, adaptive software development and Kent Beck's Extreme Programming techniques have, in effect, applied the simple rules of Lean Production to software development. The results, which I call Lean Programming, can be as dramatic as the improvements in manufacturing engendered by the Ohno- and Deming-based efficiency movements of the 1980s. The Chrysler C3 project, which used Extreme Programming, with its characteristic focus on teamwork, customer feedback and continual reintegration, is a prime example of this new methodology.

Lean Rule #1: Eliminate Waste
The first rule of Lean Programming is to eliminate waste. A value stream analysis identifies all activities in the process and delineates the specific value they add to the final product. The value analysis then attempts to find a different, more efficient way to produce the same value.

The documents, diagrams and models produced as part of a software development project are often consumables—aids used to produce a system, but not necessarily a part of the final product. Once a working system is delivered, the user may care little about the intermediate consumables. Lean principles suggest that every consumable is a candidate for scrutiny. The burden is on the artifact to prove not only that it adds value to the final product, but also that it is the most efficient way of achieving that value.

Lean Rule #2: Minimize Inventory
Contrary to popular belief, inventory is wasteful: It consumes resources, slows response time, hides quality problems, gets lost, degrades and becomes obsolete. The inventory of software development is documentation that isn't a part of the final program. Take requirements and design documents, for example. How important are they to the final product? If you compare them to in-process inventory, it's striking to note that the hours expended to create these documents form a major component of the product's cycle time. Just as inventory must be diminished to maximize manufacturing flow, so, too, must requirements and design documents be reduced to maximize development flow.

There are many wastes associated with excess documentation: the squandering of time spent creating and reviewing reports, and the unnecessary work involved in change requests and associated evaluations, priority setting and system changes. But the biggest waste of all is that of building the wrong system if the documentation doesn't correctly and completely capture the user's requirements.

We know that users are relatively inefficient at envisioning the details of a system from most documents, and are even less likely to correctly perceive how a system will work in their environment until they actually use it. Even if users could predict exactly how the system should operate, it's unlikely that the way the system is supposed to work months before it's delivered will be exactly the way users need it to work throughout its life span. All of these factors must be considered when we evaluate the value of documentation.

Lean Rule #3: Maximize Flow (Reduce System Response Time)
In the 1980s, TQM principles taught us how to make products in hours instead of days or weeks. Indeed, rapid product flow shortened cycle times by several orders of magnitude. During the 1990s, e-commerce projects were often able to accomplish in weeks what used to take months or years in the traditional software development world. Yes, in some sense they cheated, exploiting the absence of an established customer base, which allowed unchecked expansion built upon sometimes shoddy components. And many paid the price for this gold rush: A number of the early e-commerce firms, funded largely by speculation, died natural deaths brought on by poor management, code that was anything but robust and lack of discipline. Nevertheless, in the last five years, an abundance of useful software with extremely short cycle times has been deployed.

In his article, "Reducing Cycle Time" (Management Forum, Aug. 2000), Dennis Frailey proposes trimming software development cycle time using the same techniques employed to reduce manufacturing cycle time. He suggests looking for and reducing accumulations of work in process, or WIP. Just as in manufacturing, if you reduce WIP, you trim the cycle time. To do this, Frailey recommends using the familiar Lean Production "small batch" and "smooth flow" principles.

Iterative development is basically the application of these principles to programming. In this method, small but complete portions of a system are designed and delivered throughout the development cycle, with each iteration taking on an additional set of features. From start to finish, cycle time of any iteration varies from a few weeks to a few months, and each iteration engages the entire development process, from gathering requirements to acceptance testing.

Lean Rule #4: Pull From Demand (Make Decisions as Late as Possible)
In our videocassette manufacturing plant, we used to think that it would be ideal if our marketing department could forecast exact market requirements. A lot of work went into sophisticated techniques to more accurately predict the future. Then one day we realized that we were doing the wrong thing: It would not be ideal if we had a perfect forecast. Instead, we should relinquish our dependence on forecasts by reducing system response time so dramatically that the system could adequately respond to change, obviating the need for prediction.

In a market in which volatile technology requires constant product upgrades, Dell Computer has a huge advantage over its keenest competitors because it doesn't forecast demand; rather, it responds to it by making-to-order in an average of 10 days. While Dell holds only days' worth of inventory, its competitors maintain weeks' worth. Dell's ability to make decisions as late as possible gives the company a significant competitive edge in a fast-moving market.

Software development practices that keep requirements flexible as close to system delivery as possible provide a competitive advantage. In a volatile business environment, users can't accurately forecast their future needs. Freezing the design early in a development project is just as speculative as forecasting. Software systems should be designed to respond to change, not predict it.

Lean Rule #5: Meet Customer Requirements (Now and in the Future)
In his 1979 book, Quality Is Free, Philip Crosby defines quality as "conformance to requirements." The 1994 Standish Group study "Charting the Seas of Information Technology—Chaos" notes that the most common cause of failed projects is missing, incomplete or incorrect requirements. The software development world has responded to this risk by amplifying the practice of gathering detailed user requirements and getting user sign-off prior to proceeding with system design. However, this approach to defining user requirements is deeply flawed.

I worked on one project in which the customer wanted a complex system delivered in 10 months. Time was of the essence—10 months or bust. Yet, because the project emanated from a government agency, the contract required sign-off on an external design document before internal design and coding could begin. Several users were involved, and they dragged their feet on signing the documents, concerned that they might endorse something that would later prove to be a mistake. Since there was no easy way to change things after the design documents were signed, they took two months to approve the design. And who can blame them? Their jobs depended on getting it right. So, halfway into a very tight schedule, over two months of time and a lot of paper were wasted in obtaining user sign-off on design documents.

Instead of encouraging user involvement, user sign-off tends to create an adversarial relationship between developers and users. Users are required to make decisions early in the development process and are not allowed to change their minds, even when they do not have a clear concept of how the system will work or how their business situation may develop in the future. Understandably reluctant to make these commitments, users will instinctively delay decisions to as late in the process as possible. Note that this instinct is in line with Lean Rule #4: Make decisions as late as possible.

The most effective way to accurately capture user requirements is through iterative system development. Developing core features early and obtaining customer feedback in usability demonstrations of each iteration results in a far more correct definition of customer requirements. If we realize that requirements will necessarily change over time, systems must be designed to evolve as necessary.

Coming Soon
Next month, I'll explain Lean Rules #6 through 10. These points are: do it right the first time by providing for change, empower workers and drive out fear, declare measurements the enemy by banning local optimization, partner with suppliers and, finally, create a culture of continuous improvement.

RELATED ARTICLES Using LINQ-to-SQL XML Mapping Files Identifying Weaknesses In Network-accessible Programs Hardware Mash-ups and Bug Lab's Bug CodeGear Delphi 2009, C++ Builder 2009 Released Data Centers: Focusing on Sustainability		TOP 5 ARTICLES No Top Articles.