Anda di halaman 1dari 9

years.

As the world’s largest producer of PC software, methods by themselves have caused the company’s
with approximately 20,500 employees, 250 products, great financial success. We are saying there are sev-
and annual revenues of $8.7 billion (fiscal year ending eral lessons to be learned from how Microsoft builds
June 1996), Microsoft has probably tackled more PC software products, some of which apply to other
software projects than any other company in the organizations, some of which do not. Software devel-
industry. The complexity of some of its products, such opers and managers from other organizations can
as Windows 95 (which contains more than 11 million decide which ideas may apply to them after consid-
lines of code and required a development team of ering such factors as their company’s goals, market-
more than 200 programmers and testers), rivals that ing strategies, resource constraints, software
of many systems for mainframe computers and reliability requirements, and development culture.1
telecommunication systems.
Microsoft’s philosophy for product development Frequent Synchronizations and
has been to cultivate its roots as a highly flexible, Periodic Stabilizations
entrepreneurial company and not to adopt too many We label Microsoft’s style of product development
of the structured software-engineering practices the “synch-and-stabilize” approach. The essence is
commonly promoted by such organizations as the simple: Continually synchronize what people are
Software Engineering doing as individuals
Institute and the and as members of
International Stan-
dards Organization
Without parallel teams, and
periodically stabilize
[6]. Rather, Microsoft
has tried to “scale up”
its synch-and-stabilize the product in incre-
ments as a project pro-
a loosely structured
small-team (some
structured approach, ceeds, rather than once
at the end of a project.
might say hacker)
style of product devel-
Microsoft would Microsoft people refer
to their techniques
opment. The objective
is to get many small
probably never have variously as the “mile-
stone,” “daily build,”
parallel teams (three
to eight developers
been able to design, “nightly build,” or
“zero-defect” process.
each) or individual
programmers to work
build, and ship the (The term build refers
to the act of putting
together as a single
relatively large team
products it offers now together partially
completed or finished
in order to build large
products relatively
and plans to offer pieces of a software
product during the
quickly while still
allowing individual
in the future. development process
to see what functions
programmers and teams freedom to evolve their work and what problems exist, usually by com-
designs and operate nearly autonomously. These pletely recompiling the source code and executing
small parallel teams evolve features and whole prod- automated regression tests.) Whatever the label,
ucts incrementally while occasionally introducing these techniques address a problem common to
new concepts and technologies. However, because many firms in highly competitive, rapidly changing
developers are free to innovate as they go along, they industries: Two or three people can no longer build
must synchronize their changes frequently so prod- many of the new, highly complex products; such
uct components all work together. products require much larger teams that must
We will summarize how Microsoft uses various invent and innovate as they develop the product.
techniques and melds them into an overall approach Team members need to create components that are
that balances flexibility and structure in software interdependent, but such components are difficult to
product development. We are not suggesting that define accurately in the early stages of the develop-
the Microsoft-style development approach is appro- ment cycle. In these situations, projects must pro-
priate for all types of software development or that 1This article is based on the authors’ Microsoft Secrets: How the World’s Most Powerful
Microsoft “invented” these development ideas. Nor Software Company Creates Technology, Shapes Markets, and Manages People, The Free
do we suggest Microsoft’s software development Press/Simon & Schuster, New York, 1995.

54 June 1997/Vol. 40, No. 6 COMMUNICATIONS OF THE ACM


System
Requirements

Figure 1. Waterfall development process model


Software
Requirements

Preliminary
Document No. 1 Program
Software Design
Requirements
Document No. 3
Test Plan
Analysis Design (Spec)
ceed by Document No. 2
finding Preliminary
Design (Spec) Program Document No. 4
ways that Design Final Design
structure (As Built)
and coordinate what the
individual members do Document No. 3
while allowing them Interface Coding
Design (Spec) Document No. 5
enough flexibility to be Test Plan (Spec)
creative and evolve the Test Results
product’s details in Document No. 4
stages. The development Final Testing
approach must also have Design (Spec)
a mechanism that allows
developers to test the product with cus- Operations
..

tomers and refine their designs during the Document No. 6


Final
.

development process. Design (Spec)


In a variety of industries, many compa-
Document No. 6
nies now use prototyping as well as multiple Operating
cycles of concurrent design, build, and test activities Instructions
to control iterations as well as to make incremental
changes in product development [12]. In the soft- seek to “freeze” a product specification, create a
ware community, researchers and managers have design, build components, and then merge the com-
talked about “iterative enhancement,” a “spiral ponents—primarily at the end of the project in one
model” for iteration among the phases in project large integration and testing phase (see Figure 1). This
usumano – Figure 1
development, and “concurrent development” of mul- approach to software development was common in the
tiple phases and activities for the past 20 years [1, 2, 1970s and 1980s [8]. It also remains a basic model for
3]. However, many companies have been slow to for- project planning in many industries [11]. The water-
mally adopt these recommendations. Nonetheless, fall model has gradually lost favor, however, because
the basic idea shared by these approaches is that companies usually build better products if they can
users’ needs for many types of software are so difficult change specifications and designs, get feedback from
to understand and that changes in hardware and soft- customers, and continually test components as the
ware technologies are so continuous and rapid, it is products are evolving. As a result, a growing number
unwise to attempt to design a software system com- of companies in software and other industries—
pletely in advance. Instead, projects may need to iter- including Microsoft—now follow a process that iter-
ate while concurrently managing many design, ates among design, building components, and testing,
build, and testing cycles to move forward toward and also overlaps these phases and contains more inter-
completing a product. actions with customers during development. Many
This iterative as well as incremental and concur- companies also ship preliminary versions of their prod-
rent-engineering style contrasts with a more sequen- ucts, incrementally adding features or functionality
tial, or “waterfall,” approach to product over time in various product releases. In addition,
development. In the waterfall approach, projects many companies frequently integrate pieces of their

COMMUNICATIONS OF THE ACM June 1997/Vol. 40, No. 6 55


products together Planning Phase Define product vision, specification,
representing completion
(usually not daily, but and schedule points for major por-
often on a biweekly or tions of the product (see
monthly basis). Fre- • Vision Statement Product and program management Figure 3). All the fea-
use extensive customer input to identify and priority-order
quent integrations product features. ture teams go through a
help determine what complete cycle of devel-
does and does not work • Specification Document Based on vision statement, opment, feature integra-
program management and development group define
without waiting until feature functionality, architectural issues, and component tion, testing, and fixing
the end of the pro- interdependencies. problems in each mile-
ject—which may be • Schedule and Feature Team Formation Based on
stone subproject. More-
several years away. specification document, program management coordinates over, throughout an
schedule and arranges feature teams that each contain entire project, the fea-
approximately 1 program manager, 3–8 developers, and
Strategies and 3 – 8 testers (who work in parallel 1:1 with developers). ture teams synchronize
Principles their work by building
We observed Micro- the product
soft over a two-and-a-half year Development Phase Feature development in 3 or 4 and by finding
period ending mid-1995, con- sequential subprojects that each results in a milestone release and fixing
ducted in-depth interviews with Program managers coordinate evolution of specification. errors on a
38 key people (including chair- Developers design, code, and debug. Testers pair with daily and
man and CEO Bill Gates), and developers for continuous testing. weekly basis.
reviewed thousands of pages of • Subproject I First 1/3 of features (Most critical features At the end of a
confidential project documenta- and shared components) milestone sub-
tion and postmortem reports. • Subproject II Second 1/3 of features project, the
Through this research, we identi- developers fix
fied two strategies for defining • Subproject III Final 1/3 of features (Least critical almost all the
features)
products as well as development errors detected
processes and sets of principles
that seem critical to making the synch-and- Stabilization Phase Comprehensive internal and
stabilize style of product development. external testing, final product stabilization, and ship
Microsoft teams begin the process of prod-
Program managers coordinate OEMs and ISVs and monitor
uct development by creating a “vision state- customer feedback. Developers perform final debugging and
ment” defining the goals for a new product code stabilization. Testers recreate and isolate errors.
and orders the user activities that need to be • Internal Testing Thorough testing of complete product
supported by the product features (see Figure within the company
2). Product managers (marketing specialists)
• External Testing Thotough testing of complete product
take charge of this task while consulting pro- outside the company by "beta" sites, such as OEMs, ISVs,
gram managers who specialize in writing up and end users
functional specifications of the product. The • Release preparation Prepare final release of "golden
program managers, in consultation with devel- master" disks and documentation for manufacturing
opers, then write a functional specification out-
lining the product features in sufficient depth to organize Figure 2. Overview of the synch-and-stabilize
schedules and staffing allocations. But the initial speci- development approach
fication document does not try to cover all Cusumano – Figure 2
the details
of each feature or lock the project into the original set in the evolving product. These error corrections sta-
of features. During product development, the team bilize the product and enable the team to have a
members revise the feature set and feature details as clear understanding of which portions of the product
they learn more about what should be in the product. have been completed. The development team may
Experience at Microsoft suggests that the feature set then proceed to the next milestone and, eventually,
in a specification document may change by 30% or to the ship date.
more.
The project managers then divide the product and Defining Products and
the project into parts (features and small feature Development Processes
teams) and divide the project schedule into three or To define products and organize the development
four milestone junctures (sequential subprojects) process, leading Microsoft product groups follow a

56 June 1997/Vol. 40, No. 6 COMMUNICATIONS OF THE ACM


strategy we describe as Milestone 1 (first 1/3 features) they cannot determine in advance every-
“focus creativity by evolv- Development (design, coding, prototyping) thing developers need to do to build a
ing features and ‘fixing’ Usability Lab good product. This approach leaves
resources.” Teams imple- Private Release Testing developers and program managers room
ment this strategy Daily Builds to innovate or adapt to changed or
through five specific prin- Feature Debugging unforeseen competitive opportunities and
Feature Integration
ciples: Code Stabilization (no severe bugs)
threats. Particularly for applications
Buffer time (20%–50%) products, because development teams try
• Divide large projects to come up with features that map
into multiple milestone directly to activities typical cus-
cycles with buffer time Milestone 2 (next1/3) tomers perform, the teams need to
(20%–50% of total project Development carry out continual observation and
Usability Lab
time) and no separate product Private Release Testing
testing with users during develop-
maintenance group. Daily Builds ment.
• Use a “vision statement” and Feature Debugging Most product designs have
outline feature specifications Feature Intergration modular architectures allowing
to guide projects. Code Stabilization teams to incrementally add or com-
• Base feature selection and Buffer Time bine features in a straightforward,
priority order on user activi- predictable manner. In addi-
ties and data. Milestone 3 (last set) tion, managers allow team
• Evolve a modular and horizontal Development members to set their own
design architecture, mirroring the Usability Lab schedules, but only after the
product structure in the project Private Release Testing developers have analyzed
structure. Daily Builds tasks in detail (for example,
• Control by individual commitments Feature Debugging half-day to three-day chunks)
to small tasks and “fixed” project Feature Intergration and have been asked to per-
resources. Feature Complete sonally commit to the sched-
Code Complete
Code Stabilization
ules they set. Managers then
These principles are significant for Buffer Time “fix” project resources by
several reasons. Employing creative Zero Bug Release limiting the number of peo-
people in high-tech companies is cer- Release to Manufacturing ple they allocate to each pro-
tainly important, but directing their ject. They also try to limit
creativity is often more important. the time spent on projects,
Managers can do this by getting devel- Figure 3. Milestones in especially for applications like
opment personnel to think about the the synch-and-stabilize approach (each Office and multimedia prod-
Cusumano – Figure 3
features large numbers of customers taking two to four months) ucts, so teams can delete fea-
will pay money for and by pressuring tures if they fall too far
projects by limiting the resources, such as staffing behind. (However, cutting features to save schedule
and schedule, the company will invest in their devel- time is not always possible with operating systems pro-
opment. Otherwise, software developers risk never jects in which reliability is more important than fea-
shipping anything to market. This risk is especially tures and in which many features are closely coupled
troublesome in fast-moving industries in which and cannot easily be deleted individually.)
individuals or teams have unfocused or highly
volatile user requirements, frequently change inter- Developing and Shipping Products
dependent components during a project, or fail to To manage the process of developing and shipping
synchronize their work. products, Microsoft follows another strategy we
Microsoft gets around these problems by structur- describe as “do everything in parallel with frequent
ing projects into sequential subprojects containing synchronization.” Teams implement this strategy by
priority-ordered features; buffer time within each following another set of five principles:
subproject gives people time to respond to changes
and to unexpected difficulties or delays. Microsoft • Work in parallel teams but “synch up” and debug
projects use vision statements and outline specifica- daily.
tions rather than detailed designs and complete prod- • Always have a product you can ship, with ver-
uct specifications before coding, because teams realize sions for every major platform and market.

COMMUNICATIONS OF THE ACM June 1997/Vol. 40, No. 6 57


Opened
Resolved
Fixed
Active

Opened/
Resolved
Bugs

19 20 21 22 23 24 25 26 27 28 29 30 31 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
1/18 2/1
Source: Microsoft internal document

Figure 4. Milestone 2: Bug data and daily builds from Excel/Graph

• Speak a “common language” on a single develop- responsibilities and work in small, nimble teams.
ment site. What Microsoft tries to do is allow many small
• Continuously test the product as you build it. teams and individuals enough freedom to work in
• Use metric data to determine milestone comple- parallel yet still function as a single large team, so
tion and product release. they can build large-scale products relatively quickly
and cheaply. The teams also adhere to a few rigid
These principles bring considerable discipline to rules that enforce a high degree of coordination and
the development process without the need to control communication.
every moment of every developer’s day. For example, For example, one of the few rules developers must
managers in many different companies talk about follow is that, on whatever day they decide to “check
making their companies less bureaucratic, more in,” or enter their pieces of code into the product
innovative, and faster to react through organization database, they must do so by a particular time, say, 2
and process “re-engineering” and “restructuring” to p.m. or 5 p.m. This rule allows the project team to
speed product development. But complex products assemble available components, completely recom-
often require large teams of hundreds of people, not pile the product source code, and create a new
small teams of a dozen or fewer engineers; and large “build” of the evolving product by the end of the day
teams can make communication and coordination or by the next morning and then start testing and
extremely difficult and slow. Large-scale projects are debugging immediately. (This rule is analogous to
simpler to schedule and manage if they proceed with telling children that they can do whatever they want
clearly defined functional groups, sequential phases, all day, but they must be in bed at 9 p.m.) Another
and precise rules and controls. This approach, how- rule is that if developers check in code that “breaks”
ever, may restrain innovation and undervalue the the build by preventing it from completing the
importance of frequently synchronizing work. Com- recompilation, they must fix the defect immediately.
munication and coordination difficulties across the (This rule resembles Toyota’s famous production sys-
functions and phases may also result in a project’s tem, in which factory workers are encouraged to stop
taking more time and people to complete than pro- the manufacturing lines whenever they notice a
jects that overlap tasks and require that people share defect in a car they are assembling [4].)

58 June 1997/Vol. 40, No. 6 COMMUNICATIONS OF THE ACM


Microsoft’s daily build process has several steps. development tools. A common site and common lan-
First, in order to develop a feature for a product, guage and tools help teams communicate, debate
developers can check out private copies of source design ideas, and resolve problems face to face. Pro-
code files from a centralized master version of the ject teams also use a small set of quantitative metrics
source code. They implement their features by mak- to guide decisions, such as when to move forward in
ing changes to their private copies of the source code a project and when to ship a product to market. For
files. The developers then create a private build of example, managers rigorously track progress of the
the product containing the new feature and test it. daily builds by monitoring how many bugs are newly
They then check in the changes from their private opened, resolved (such as by eliminating duplicates or
copies of the source code files to the master version of deferring fixes), fixed, and active (see Figure 4).
the source code. The check-in process includes an
automated regression test to help ensure that their The Hacker Approach
changes to the source code files do not cause errors Some people may argue that Microsoft’s key practices
elsewhere in the product. Developers usually check in product development—daily synchronization
in their code back to the master copy at least twice a through product builds, periodic milestone stabiliza-
week but may check it in daily. tions, and continual testing—are no more than
Regardless of how often individual developers process and technical fixes for a hacker software orga-
check in their changes nization now building
to the source code, a huge software systems.
designated developer,
called the project build
No PC software We do not really dis-
agree, but we also think
master, generates a
complete build of the
company has done a that Microsoft has some
insightful ideas on how
product on a daily basis
using the master ver-
better job of keeping to combine structure
with flexibility in prod-
sion of the source code.
Generating a build for a
some basic elements uct development. It is
worthwhile to note that
product consists of exe-
cuting an automated
of the hacker culture the term hacker is not
necessarily a bad word in
sequence of commands
called a “build script.”
while adding just the PC industry. It goes
back to the early days of
This daily build creates
a new internal release of
enough structure to computer programming
in the 1960s, when long-
the product
includes many steps
and build today’s, and haired, unkempt techni-
cal wizards would work
that compile source
code. The build process
probably tomorrow’s, at their computers with
no formal plans, designs,
also automatically
translates the source
PC software products. or processes, and just
“bang on a keyboard”
code for a product into and “hack away” at cod-
one or more executable files and may create various ing [7]. This approach worked for relatively small
library files, allowing end users to customize the computer programs that one person or several people
product. The new internal release of the product built could write, such as the earliest versions of DOS,
each day is the daily build. Daily builds are generated Lotus 1-2-3, WordPerfect, Word, and Excel. It
for each platform, such as Windows and Macintosh, became unworkable as PC software programs grew
and for each market, such as the U.S., and for the into hundreds of thousands and then millions of lines
major international versions. of code.
Product teams also test features as they build them Formal plans and processes were first used in the
from multiple perspectives, including bringing in mainframe computer industry where software systems
customers “off the street” to try prototypes in a had grown to the million-line-plus size by the end of the
Microsoft usability lab. In addition, nearly all 1960s [5]. PC software companies have been unwilling
Microsoft teams work at a single physical site with to completely give up their traditions and cultures. Nor
common development languages (primarily C and would it be wise for them to do so, given the rapid pace
C++), common coding styles, and standardized of change in PC hardware and software technologies

COMMUNICATIONS OF THE ACM June 1997/Vol. 40, No. 6 59


and the need for continual innovation. that accumulating historical metric data is useful for
No company has taken advantage of the exploding analyzing bug trends and establishing realistic project
demand for PC software better than Microsoft. Simi- schedules [9]). Microsoft is distinctive, however, in the
larly, no PC software company has done a better job of degree to which it has introduced a structured hacker-
keeping some basic elements of the hacker culture like approach to software product development that
while adding just enough structure to build today’s, works reasonably well for both small- and large-scale
and probably tomorrow’s, PC software products. It products. Furthermore, Microsoft is a fascinating exam-
continues to be a challenge
for Microsoft to make Table 1. Synch-and-stabilize vs. sequential development
products reliable enough
for companies to buy, pow- Synch-and-Stablize Sequential Development
erful enough so the prod-
ucts’ features solve Product development and testing Separate phases done in sequence
real-world problems, and done in parallel
simple enough for novice
Vision statement and evolving Complete "frozen" specification and
consumers to understand. specification detailed design before building the
To achieve these somewhat product
conflicting goals for a vari-
ety of markets, Microsoft Features prioritized and built in Trying to build all pieces of a product
still encourages some 3 or 4 milestone subprojects simultaneously
teams to experiment and
make lots of changes with- Frequent synchronizations (daily One late and large integration and
out much up-front plan- builds) and intermediate system test phase at the project's
stabilizations (milestones) end
ning. Projects generally
remain under control "Fixed" release and ship dates and Aiming for feature and product
because teams of program- multiple release cycles "perfection" in each project cycle
mers and testers frequently
synchronize and periodi- Customer feedback continuous in Feedback primarily after development
cally stabilize their the development process as inputs for future projects
changes.
Product and process design so large Working primarily as a large group
Since the late 1980s, teams work like small teams of individuals in a separate functional
Microsoft has used varia- department
tions of the synch-and-sta-
bilize approach to build
Excel, Office, Publisher, Windows 95, Windows NT, ple of how culture and competitive strategy can drive
Word, Works, and other products. However, the product development and the innovation process. The
synch-and-stabilize process does not guarantee on- Microsoft culture centers around fervently antibureau-
time or bug-free products. Creating new, large-scale cratic PC programmers who do not like a lot of rules,
software products on a precisely predicted schedule structure, or planning. Its competitive strategy revolves
and with no major defects is an extremely difficult around identifying mass markets quickly, introducing
goal in the PC industry. Microsoft and other PC soft- products that are “good enough” (rather than waiting
ware companies also try to replace products quickly until something is “perfect”), improving these products
and usually announce overly ambitious deadlines, by incrementally evolving their features, and then sell-
contributing to the appearance of being chronically ing multiple product versions and upgrades to cus-
late. Nonetheless, without its synch-and-stabilize tomers around the world.
structured approach, Microsoft would probably never
have been able to design, build, and ship the products A Semblance of Order
it offers now and plans to offer in the future. The principles behind the synch-and-stabilize phi-
Microsoft resembles companies from many industries losophy add a semblance of order to the fast-moving,
that do incremental or iterative product development as often chaotic world of PC software development.
well as concurrent engineering. It has also adapted soft- There are no silver bullets here that solve major
ware-engineering practices introduced earlier by other problems with a single simple solution. Rather,
companies (such as various testing techniques) and rein- there are specific approaches, tools, and techniques;
vented the wheel on many occasions (such as concluding a few rigid rules; and highly skilled people whose

60 June 1997/Vol. 40, No. 6 COMMUNICATIONS OF THE ACM


culture aligns with this approach. As we have sug- for organizations and managers in many industries.
gested, several elements distinguish synch-and-sta- The synch-and-stabilize approach used at Microsoft
bilize from older, more traditional sequential and is especially suited to fast-paced markets with com-
rigid styles of product development (see Table 1). plex systems products, short lifecycles, and competi-
Microsoft also has weaknesses. The company now tion based around evolving product features and de
needs to pay more attention to, for example, product facto technical standards. In particular, coordinating
architectures, defect prevention mechanisms, and the work of a large team building many interdepen-
some more conventional engineering practices, such dent components that are continually changing
as more formal design and code reviews. New prod- requires a constant and high level of communication
uct areas also pose new challenges for its develop- and coordination. It is difficult to ensure that such
ment methods. For example, some new areas, such as communication and coordination take place while
video on demand, have many tightly linked compo- still allowing designers, engineers, and marketing
nents with real-time constraints that require precise people the freedom to be creative. Achieving this
mathematical models of when video/audio/user data balance is perhaps the central dilemma that man-
can be delivered reliably and on time. Many existing agers of product development face—in PC software
and new products have an extremely large or even as well as in many other industries. c
infinite number of potential user conditions or sce-
narios to test based on what hardware and applica- References
tions each customer is using. These new products can 1. Aoyama, M. Concurrent-development process model. IEEE Software 10,
4 (July 1993).
benefit from some incremental changes in the devel- 2. Basili, V.R., and Turner, A.J. Iterative enhancement: A practical tech-
opment process. They also require more advance nique for software development. IEEE Trans. Software Eng. SEI-1, 4
(Dec. 1975), 390–396.
planning and product architectural design than 3. Boehm, B.W. A spiral model of software development and enhance-
Microsoft usually does to minimize problems in ment. IEEE Comput. 5 (May 1988), 61–72.
development, testing, and operation. 4. Cusumano, M.A. The Japanese Automobile Industry: Technology and Man-
agement at Nissan and Toyota. Harvard University Press, Cambridge,
Nonetheless, the synch-and-stabilize process Mass., 1985.
described here provides several benefits for product 5. Cusumano, M.A. Japan's Software Factories: A Challenge to U.S. Manage-
ment. Oxford University Press, New York, 1991.
developers: 6. Humphrey, W.S. Managing the Software Process, Addison-Wesley, New
York, 1989.
• It breaks down large products into manageable 7. Levy, S. Hackers: Heroes of the Computer Revolution. Anchor/Doubleday,
New York, 1984.
pieces (a priority-ordered set of product features 8. Royce, W.W. Managing the development of large software systems. In
that small feature teams can create in a few Proceedings of IEEE WESCON (Los Angeles, 1970), pp. 1–9.
9. Selby, R.W. Empirically based analysis of failures in software systems.
months). IEEE Trans. Reliab. 39, 4 (Oct. 1990), 444–454.
• It enables projects to proceed systematically even 10. Smith, S.A., and Cusumano, M.A. Beyond the Software Factory: A com-
when they cannot determine a complete and sta- parison of “classic” and “PC” software developers. Working Paper 3607-
93/BPS, Sloan School, Massachusetts Institute of Technology, Cam-
ble product design at the project’s beginning. bridge, Mass., 1993).
• It allows large teams to work like small teams by 11. Urban, G.L., and Hauser, J.R. Design and Marketing of New Products.
dividing work into pieces, proceeding in parallel Prentice-Hall, Englewood Cliffs, N.J., 1993.
12. Wheelwright, S.C., and Clark, K.B. Revolutionizing Product Development.
but synchronizing continuously, stabilizing in Free Press, New York, 1992.
increments, and continuously finding and fixing
problems.
• It facilitates competition on customer input, Michael A. Cusumano (cusumano@mit.edu) is a professor of
strategy and technology management in the Sloan School of Man-
product features, and short development times by agement at the Massachusetts Institute of Technology, Cambridge,
providing a mechanism for incorporating cus- Mass.
tomer inputs, setting priorities, completing the Richard W. Selby (selby@ics.uci.edu) is an associate professor
most important parts first, and changing or cut- of computer science in the Department of Information and Com-
puter Science at the University of California, Irvine.
ting less important features.
• It allows a product team to be very responsive to
Permission to make digital/hard copy of part or all of this work for personal or class-
events in the marketplace by “always” having a room use is granted without fee provided that copies are not made or distributed for
product ready to ship, having an accurate assess- profit or commercial advantage, the copyright notice, the title of the publication and
its date appear, and notice is given that copying is by permission of ACM, Inc. To copy
ment of which features are completed, and pre- otherwise, to republish, to post on servers, or to redistribute to lists requires prior spe-
cific permission and/or a fee.
serving process-product flexibility and
opportunism throughout the development
process.
These ideas and examples provide useful lessons © ACM 0002-0782/97/0600 $3.50

COMMUNICATIONS OF THE ACM June 1997/Vol. 40, No. 6 61