Contents
13.1 Team-Structure Considerations
13.2 Team Models
13.3 Managers and Technical Leads
Related Topics
Teamwork: Chapter 12
EVEN WHEN YOU HAVE SKILLED, MOTIVATED, hard-working people, the wrong team structure can undercut their efforts instead of catapulting them to success. A poor team structure can increase development time, reduce quality, damage morale, increase turnover, and ultimately lead to project cancellation. Currently, about one-third of all team projects are organized in ineffective ways (Jones 1994).
This chapter describes the primary considerations in organizing a rapid-development team and lays out several models of team structure. It concludes with a discussion of one of the most nettlesome team-structure issues: the relationship between project managers and technical leads.
The first consideration in organizing a team is to determine the team's broad objective. Here are the broad objectives according to Larson and LaFasto (1989):
Problem resolution
Creativity
Tactical execution
Once you've established the broad objective, you choose a team structure that matches it. Larson and LaFasto define three general team structures for effective, high-performance teams. The structure that's most appropriate depends on the team's objective.
The users in Case Study: Mismatch Between Project Objectives and Team Structure had described exactly what they wanted, and the team really just needed to create and execute a plan for implementing it. Bill got some bad advice from Randy, who should have identified the primary goal of the team as tactical execution. The users were more interested in getting a timely upgrade than they were in creative solutions. The effect of the bad advice was predictable: organized for creativity, the team came up with a highly creative solution but didn't execute their plan efficiently. They weren't organized for that.
Once you've identified the team's broadest objective—problem resolution, creativity, or tactical execution—then you set up a team structure that emphasizes the characteristic that is most important for that kind of team. For a problem-resolution team, you emphasize trust. For a creativity team, autonomy. And for a tactical-execution team, clarity.
Problem-resolution team. The problem-resolution team focuses on solving a complex, poorly defined problem. A group of epidemiologists working for the Centers for Disease Control who are trying to diagnose the cause of a cholera outbreak would be a problem-resolution team. A group of maintenance programmers trying to diagnose a new showstopper defect is too. The people on a problem-resolution team need to be trustworthy, intelligent, and pragmatic. Problem-resolution teams are chiefly occupied with one or more specific issues, and their team structure should support that focus.
Creativity team. The creativity team's charter is to explore possibilities and alternatives. A group of McDonald's food scientists trying to invent a new kind of McFood would be a creativity team. A group of programmers who are breaking new ground in a multimedia application would be another kind of creativity team. The creativity team's members need to be self-motivated, independent, creative, and persistent. The team's structure needs to support the team members' individual and collective autonomy.
Tactical-execution team. The tactical-execution team focuses on carrying out a well-defined plan. A team of commandos conducting a raid, a surgical team, and a baseball team would all be tactical-execution teams. So would a software team working on a well-defined product upgrade in which the purpose of the upgrade is not to break new ground but to put well-understood functionality into users' hands as quickly as possible. This kind of team is characterized by having highly focused tasks and clearly defined roles. Success criteria tend to be black-and-white, so it is often easy to tell whether the team succeeds or fails. Tactical-execution team members need to have a sense of urgency about their mission, be more interested in action than esoteric intellectualizing, and be loyal to the team.
Table 13-1 summarizes the different team objectives and the team structures that support those objectives.
Table 13-1. Team Objectives and Team Structures
Broad Objective | |||
|---|---|---|---|
Problem Resolution | Creativity | Tactical Execution | |
Source: Adapted from Team Work (Larson and LaFasto 1989). | |||
Dominant feature | Trust | Autonomy | Clarity |
Typical software example | Corrective maintenance on live systems | New product development | Product-upgrade development |
Process emphasis | Focus on issues | Explore possibilities and alternatives | Highly focused tasks with clear roles, often marked by clear success or failure |
Appropriate lifecycle models | Code-and-fix, spiral | Evolutionary prototyping, evolutionary delivery, spiral, design-to-schedule, design-to-tools | Waterfall, modified waterfalls, staged delivery, spiral, design-to-schedule, design-to-tools |
Team selection criteria | Intelligent, street smart, people sensitive, high integrity | Cerebral, independent thinkers, self-starters, tenacious | Loyal, committed, action-oriented, sense of urgency, responsive |
Appropriate software-team models | Business team, search-and-rescue team, SWAT team | Business team, chief-programmer team, skunkworks team, feature team, theater team | Business team, chief-programmer team, feature team, SWAT team, professional athletic team |
Beyond the three basic kinds of teams, there are four team-structure features that seem to characterize all kinds of effectively functioning teams:
Clear roles and accountabilities. On a high-performance team, every person counts, and everyone knows what they are supposed to do. As Larson and LaFasto say, "everyone is accountable all the time on successful teams" [authors' emphasis] (Larson and LaFasto 1989).
Monitoring of individual performance and providing feedback. The flip side of accountability is that team members need some way of knowing whether they are living up to the team's expectations. The team needs to have mechanisms in place to let team members know in what ways their performance is acceptable and in what ways it needs improvement.
Effective communication. Effective communication depends on several project characteristics.
Information must be easily accessible. Meting out information on a "need to know" basis is bad for morale on a rapid-development project. Put all relevant information including documents, spreadsheets, and project-planning materials into version control and make them available on-line.
Information must originate from credible sources. The team's confidence in its decision making—the extent to which it's willing to make decisions actively or boldly—depends on how confident it is in the information on which it bases its decisions.
There must be opportunities for team members to raise issues not on the formal agenda. The word "formal" is key. Team members need informal opportunities to raise issues in an environment where titles, positions, office sizes, and power ties are not part of the equation. This is part of the underlying reason for the success of informal management approaches such as Management By Walking Around.
The communication system must provide for documenting issues raised and decisions made. Keeping accurate records prevents the team from retracing its steps through old decisions.
Fact-based decision making. Subjective judgments can undercut team morale. High-performance team members need to understand the bases for all decisions that affect them. If they find that decisions are made for arbitrary, subjective, or self-serving reasons, their performance will suffer.
A key to organizing a team for rapid development is understanding that there is no single team structure that achieves the maximum development speed on every project.
CROSS-REFERENCE
For more on the need to tailor the development approach to the project, see Which Dimension Matters the Most?, Which Dimension Matters the Most? and Does One Size Fit All?, Does One Size Fit All?
Suppose you're working on a brand new word-processing product and your goal is to create the best word processor in the world. You don't know at the beginning of the project exactly what the world's best word processor looks like. Part of your job will be to discover the characteristics that make up an exceptional product. For the most rapid development within that context, you should choose a team structure that supports creativity.
Now suppose that you're working on version 2 of that same word-processing product. You learned on version 1 what it would take to create a world-class product, and you don't view version 2 as exploratory. You have a detailed list of features that need to be implemented, and your goal is to implement them as fast as possible so that you stay ahead of the competition. For the most rapid development within that context, you should choose a team structure that supports tactical execution.
There's no such thing as a single best "rapid-development team structure" because the most effective structure depends on the context. (See Figure 13-1.)
