How Microsoft Makes Large Teams Work Like Small Teams

Buy this article E-mail this page 

What can Microsoft teach us about nurturing creativity in people and teams and integrating their work, while maintaining schedules and coordinating frequent changes? Cusumano explores the Microsoft approach to product development, called synch-and-stabilize, which is based on two strategies:

1. Focus creativity by evolving features and "fixing" resources.

2. Do everything in parallel with frequent synchronizations.

This approach allows people on large product development teams to work individually and people on smaller teams to work on different features. Those features are then integrated into the product at various milestones rather than at the end of the project. Teams begin by creating a vision statement that defines the goals of the new product and its features. Next, the program managers and developers write specs outlining product features, schedules, and staffing. Project managers divide the product and project into parts and set milestones for the project schedule. All feature teams go through a complete cycle of development. Throughout, feature teams synchronize their work by building the product and finding and fixing errors daily or weekly. They are generally free to set their own schedules within certain predetermined time frames.

The second strategy brings some discipline to the process without dictating every developer's schedule. People are free to work in parallel yet function as one large team. Hence, Microsoft enforces a few rigid rules that enforce coordination and communication such as adherence to the "daily build" and immediate repair of bugs.

The key elements of the Microsoft approach are:

• Limit the size and scope of projects by setting clear boundaries on what each project will accomplish and organizing around product units that define how many people work on the project and how much time they spend.
• Break products down into features and functions and organize them into components that more than one product can use.
• Divide projects so they mirror the structure of products, prioritize features and divide them into clusters, and set target dates for each feature.
• Establish small multifunctional groups and give each team and individual autonomy and responsibility.
• Set a few rigid rules — daily builds, immediate repair of bugs, and deadlines for stabilizations — to ensure that teams coordinate their work.
• To ensure good communication, blur divisions so people share responsibilities, have only one site for major development efforts, use a common development language, and maintain a loosely organized structure.
• Allow for flexibility so specs and details can evolve along with the project and build buffer time into the schedule to accommodate unforeseen changes and exploration of alternative practices and tools.

In the end, Microsoft's principles apply not just to software development but to any fast-paced industry in which there are frequent product builds.

Michael A. Cusumano is a professor at the MIT Sloan School of Management.

$	6.50	Buy PDF
$	12.00	Buy PDF and permission to copy
$	5.50	Buy permission to copy from your own original
$	6.50	Buy paper reprint
$	12.00	Buy paper reprint and permission to copy

Academic pricing and volume discount information

[top] [back]