FOCUS: LEAN SOFTWARE DEVELOPMENT Sloan Management Review, I sum- Lean Software marized my findings while Krafcik at- tempted to generalize Toyota’s man- agement philosophy and presented his own data showing Japanese superior- Development: ity. Krafcik coined the term “lean” as a contrast to a Ford-style “buffered” A Tutorial mass production system.2 Toyota’s techniques dramatically reduced in-process and final invento- Mary Poppendieck, Poppendieck.LLC ries, expanding worker responsibili- ties to operate more machines, as well Michael A. Cusumano, Massachusetts Institute of Technology as enabling more assembly line work- ers to build in quality. A key element was that Toyota reversed the flow of information signals (then in the form // This tutorial describes where lean software of Kanban cards) controlling produc- tion operations. This change gave To- development comes from, what it means, how it yota factories the ability to make small relates to well-known agile development practices, batches of components “just in time” (JIT) for final assembly and shipment and how it is likely to evolve in the future. // to dealers, while eliminating most of the “just in case” in-process and fi- nal inventories. The basic philosophy was to “pull” materials and compo- nents through the production system as needed in a continuous flow, rather than “push” them through and stock- pile using fully predetermined produc- tion plans. The terms “lean” and “JIT” were later popularized by MIT’s global best-seller The Machine That Changed THE TERm “LEAN” was first applied and thesis under my (Michael’s) super- the World (Rawson, 1990). The au- publicly to a production management vision, after I had just published The thors used the term “lean” to describe process and then to product develop- Japanese Automobile Industry in 1985. any efficient management practice that ment at MIT during the mid-1980s I had reported that Toyota, using tech- minimized waste, including in prod- (for a history of lean in the operations niques that had evolved since the late uct development, where Japanese au- management literature, see Matthias 1940s, was producing automobiles tomakers had achieved shorter leader Holweg’s “The Genealogy of Lean Pro- with roughly half the number of labor times (by about one-third) and fewer duction”1). John Krafcik, currently the hours as the Big Three US automakers engineering hours (by about half) com- CEO of Hyundai Motor America, was with much faster inventory turns and pared to US and European projects. the first American engineer hired by higher quality. Nissan was not far be- (The more detailed research was done Toyota to work in the NUMMI (New hind Toyota. Encouraged by MIT’s at Harvard Business School by IMVP United Motor Manufacturing, Inc.) as- International Motor Vehicle Program research affiliates Kim Clark and Taka- sembly plant in California, a joint ven- (IMVP) research director, James Wom- hiro Fujimoto, published as Product ture with General Motors. He came ack, Krafcik launched a survey to com- Development Performance [Harvard to the MIT Sloan School of Manage- pare auto assembly plants around the Business School, 1991].) ment in 1986 to do a master’s degree world. In 1988 companion articles in Some similarities between Japanese 26 IEEE SOFTWARE | PUBLisHED BY THE IEEE COMPUTER SOCieTY 0740-7459/12/$31.00 © 2012 IEEE management and PC-style software Process comparison of Toyota and Microsoft. development were becoming apparent by the mid-1990s. For example, in Mi- Toyota-style “lean” production 1990s Microsoft-style “agile” development (manual demand-pull with Kanban cards) (daily builds with evolving features) crosoft Secrets (Free Press, 1995), we (Michael and coauthor Richard Selby) 1 ABLE JIT “small lot” production Development by small-scale features noted a similarity in the philosophy T Minimal in-process inventories Short cycles and milestone intervals behind Microsoft’s daily builds, where engineers had to stop and fix bugs on a Geographic concentration—production Geographic concentration—development daily basis (we dubbed this the “synch Production leveling Scheduling by features and milestones and stabilize” process), and Toyota’s JIT production philosophy, where Rapid setup Automated build tools and quick tests workers stopped assembly lines when- Machine and line rationalization Focus on small, multifunctional teams ever they detected problems to fix them immediately. This book did not use Work standardization Design, coding, and testing standards the term “lean” for software develop- Foolproof automation devices Builds and continuous integration testing ment; we were thinking mainly about the common application of a JIT engi- Multiskilled workers Overlapping responsibilities neering and quality-control practice, Selective use of automation Computer-aided tools, but no code generators as well as the reduced levels of bureau- cracy and staffing in Microsoft com- Continuous improvement Postmortems, process evolution pared to companies such as IBM. To Source: M. Cusumano, Staying Power, Oxford, 2010, p. 197. dive deeper into product development in the auto industry, along with an MIT doctoral student (Kentaro Nobeoka) I (Michael) launched another major re- book, Lean Software Development or agile development (before the Win- search effort, summarized in the book (Addison-Wesley, 2003). In common dows teams became inordinately large Thinking beyond Lean (Free Press, with the MIT and IMVP researchers, in the late 1990s and early 2000s), 1998). This book also built on a pub- we also emphasized eliminating waste even when we look at specific prac- lication by James Womack and Daniel and bureaucracy in product develop- tices. My (Michael’s) 2010 book sum- Jones, Lean Thinking (Simon & Schus- ment, encouraged learning through marized some of these similarities un- ter, 1996), which attempted to gener- short cycles and frequent builds, and der the principle of “pull, don’t just alize lean practices and applications. promoted late changes and fast itera- push” (see Table 1). Thinking beyond Lean focused on tions, with feedback pulling changes Early use of the term “lean” no newer approaches to product develop- into a product, rather than require- doubt leveraged the popularity of Jap- ment, emphasizing the systematic reuse ments documents and rigid plans push- anese management techniques, but the of product platforms and major com- ing development work forward. emphasis has always been on reducing ponents, as well as other techniques, Authors who have used the term waste in terms of time and staffing, fo- such as short, overlapping phases (con- “lean” with reference to software de- cusing on value for the customer, the current engineering) to reduce calendar velopment all seem to have stressed product, and the enterprise, as well as time and engineering hours, but it only the difference between older and more stressing the benefits of a more flex- included a brief discussion of software labor-intensive, bureaucratic, push- ible, iterative, lightweight development development. style methods, initially associated with process. We also see this orientation The popularization of the term the mainframe computer business, in XP and Scrum.3 These approaches, “lean” and its association with “ag- and newer, less bureaucratic, iterative referred to as iterative, incremen- ile” for software product develop- or incremental, and flexible methods. tal, or agile, encompass a set of tech- ment seems to have come mainly from There clearly are many common ele- niques for software development that later efforts, such as those of one of us ments between Toyota-style lean pro- are less sequential or “waterfall-ish” (Mary) and Tom Poppendieck in the duction and Microsoft-style iterative as well as bureaucratic and slow, and SEPTEMBER/OCTOBER 2012 | IEEE SOFTWARE 27 FOCUS: LEAN SOFTWARE DEVELOPMENT have become commonplace around the on how to use IT to create value for the process, and so on. Moreover, the value world owing to the benefits they offer.4 customers…. Thus lean development is of software isn’t derived solely from not a software engineering methodol- the development phase; design and de- Lean Software ogy in the conventional sense. It’s re- ployment are fundamental to its value. Development ally a synthesis of a system of practices, Finally, the value of software is rarely This leads to the more general issue principles, and philosophy for building limited to a single time-bound effort; of whether or not it is even appropri- software systems for a customer’s use.” the capability to modify a code base ate to apply the principles behind lean In the book, Lean Software De- over time tends to be a dominant factor production to product development velopment (Addison-Wesley, 2003) in its overall value. or software engineering. In fact, we we (Mary and coauthor Tom) also Eliminate Waste In lean terms, “waste” is anything that If lean is thought of as a set of practices, doesn’t either add customer value di- rectly or add knowledge about how it doesn’t translate well from operational to deliver that value more effectively. to development environments. Some of the biggest causes of waste in software development are unnecessary features, lost knowledge, partially done work, handovers, and multitasking, not have frequently encountered nega- emphasized seven principles of lean to mention the 40 to 50 percent of de- tive reactions to this with comments software development (which we later velopment time spent finding and fix- such as, “Development is not at all modified slightly, based on subse- ing defects. Many of these wastes have like manufacturing.” And, indeed, if quent experience): their roots in the large batches of par- lean is thought of as a set of practices, tially done work created in sequential it doesn’t translate well from opera- • optimize the whole, development processes, in the bound- tional to development environments. • eliminate waste, aries between different functions, and However, if lean is thought of as a set • build quality in, in the delays and knowledge lost when of principles rather than practices, then • learn constantly, work crosses these boundaries.