Adapting the Team Model

The MSF Team Model was designed to be flexible enough to support various teams in how they prefer to self-organize. As long as the core principles and the set of natural checks and balances are preserved, the model can be easily adapted to match the needs of small and large as well as simple and complex projects.

This section provides guidance on how to scale the MSF Team Model. When you consider adapting the MSF Team Model, you need to understand teaming constraints imposed by the corporate structure, culture, and policies. A team structure needs to be both compatible with the corporate structure as well as represent the interests of the various corporate functional areas (e.g., the training department). Staff assigned to a team should have a healthy cross-blend of skills so that they balance out each other's competencies.

As depicted earlier, the MSF Team Model is ideally suited to support a project team of roughly 10 to 75 people spread out across the various advocacy groups (when an effort involves more staff, consider scaling this to a program-oriented team model; that is, breaking into multiple projects). However, at what point should a team adapt its structure? Most often, it is when coordination and communications among a team start to affect productivity significantly. Keep in mind that this can happen on a small team, too (e.g., 10 people), if other factors are present (e.g., globally distributed team with mixed skill levels). The goal of adapting a team is to increase subteam cohesion and minimize cross-team coupling.

Additional contributing factors to adapting a team model are the size, risk, and complexity of a project, as well as the skills required to fulfill the responsibilities of the functional areas. A goal of dividing a large team into smaller ones is to lower process, management, and communication overhead and enable faster implementation. A goal of adapting a team model to deal with risk is to help either contain or isolate risks as much as possible. In some cases, a goal is to spread risks across subteams as part of a mitigation strategy. Many types of complexity can confront a team. Like handling risk, one option is to assign more-complex efforts to a more senior subteam.

Adapting a team model does not just mean extending it; it also includes scaling it down to meet the needs of small teams. The following section discusses scaling-down strategies.

Scaling Down: Combining Advocacy Groups for Smaller Teams

Even though the MSF Team Model consists of seven advocacy groups, a team does not need a minimum of seven people. It also does not require one person per advocacy group. However, all quality goals of the advocacy groups must be championed. Typically, having at least one person per advocacy group helps to ensure that someone looks after the interests of each group, but not all projects have the benefit of filling each advocacy group in that fashion. Often, team members must share roles. On smaller teams, roles must be shared across team membership.

A guiding principle on role sharing is to try not to combine roles that have intrinsic conflicts of interest. For example, Product Management and Program Management have conflicting interests and should not be combined: Product Management wants to satisfy the customer, whereas Program Management wants to deliver on time and on budget. If these roles were combined and a customer were to request a change, the risk is that either the change will not get the consideration it deserves to maintain customer satisfaction, or that it will be accepted without understanding the impact it has on a project. Having different team members represent these advocacy groups helps to ensure that each perspective receives equal consideration. This is also true in trying to combine Testing and Development.

Combining some roles adds risk to a project. Combining other roles is unlikely as a result of intrinsic skills mismatches. But as with any teaming exercise, successful role sharing comes down to the actual members themselves and what experience and skills they bring with them. Table 4-4 advises what is perceived to be risky (as indicated by "Not Recommended"), unlikely, and synergistic (as indicated by "Possible") combinations of advocacy groups.

Table 4-4. Recommendations for Advocacy Group Combinations

	Product Management	Program Management	Architecture	Development	Test	User Experience	Release/Operations
Product Management		N	N	N	P	P	U
Program Management	N		P	N	U	U	U
Architecture	N	P		P	U	U	U
Development	N	N	P		N	N	N
Test	P	U	U	N		P	P
User Experience	P	U	U	N	P		U
Release/Operations	U	U	U	N	P	U
Key: P Possible U Unlikely N Not Recommended

By following the logic provided in Table 4-4, you can see that the smallest recommended team consists of three people in the configuration provided in Figure 4-7.

Figure 4-7. Example of combined advocacy groups for a three-person team

Scaling Up: Expanding Advocacy Groups for Larger Teams

A proven way to scale up the Team Model is to break a team into subteams using a lead team to integrate subteams and manage the overall project (i.e., a team of teams). Although this adds a bit of hierarchy to the team model, the goal remains to be as flat as possible. For example, it is preferred to decompose a large team into more subteams rather than to have an n-tiered model where n is greater than two. Of course, this too can be taken to an extreme of diminishing returns.

A lead team is composed of leads for each advocacy group. Their main responsibility is to coordinate and synchronize their counterparts on each subteam (e.g., a lead team test manager coordinates solution testing with test leads from each subteam). They might also act as arbitrators as disagreements arise between subteams. A lead team sets the overall project vision and is responsible for cross-team and integration requirements.

MSF recommends two types of subteams: feature teams and function teams. Feature teams are multidisciplinary subteams that are created to focus on building specific features or capabilities of a solution. Function teams are unidisciplinary subteams that are organized by functional role. The following sections discuss feature and function teams in more detail.

Feature Teams

Feature teams are multidisciplinary subteams organized around solution feature sets or created to focus on a particular capability (e.g., the messaging service). Each feature team is responsible for all aspects of their portion of a solution and its integration into a solution. Typically, feature teams are used in the following situations:

• A solution has highly independent components

• Members are very dispersed across organizations or geography

• There is a need to partition a solution to match organizational boundaries (e.g., outsource a portion of a delivery)

• Quick, cross-team decision making is necessary (e.g., ad hoc clarification of requirements that leads to real-time refining of a project plan)

Feature teams work best when they are colocated and have balanced representation from all advocacy groups. This is not to say that every advocacy group must be represented. A minimalist's approach to this would necessitate that each subteam contains only the minimum number of advocacy group representatives necessary to accomplish that subteam's tasks. For example, one subteam might need participation from the Release/Operations Advocacy Group whereas another subteam might not. Figure 4-8 is a team model example that includes three feature teams and a function team. There are a few things to note with this graphical example:

• It is a logical project team structure and not an organizational structure. It is expected that members of the subteams would be matrixed from various parts of an organization.

• Not all feature teams have dedicated roles in all advocacy groups (e.g., the File and Print feature team does not have a dedicated Architect role). Although there are nondedicated roles, the others on the subteam are expected to continue to champion their quality goals, responsibilities, and activities.

• The feature teams do not have dedicated user experience people. This organization has decided to group them together in a function team (discussed in more detail in the next section).

Figure 4-8. Example of a team model that includes feature teams, a function team, and a lead team

Once a teamand usually an organization's managers who have resources matrixed to the teamhas agreed on how to logically structure a team, it is time to put together a staffing plan that includes how to staff a team, what skills are needed, what roles are needed, who is available, where the work location(s) are, and the many other factors needed to resource load a team properly. This type of plan is discussed further later in Chapter 8, but for now to round this out, Figure 4-9 is an example of a team structure that identifies phased solution delivery as well as named individuals filling the various roles. In this example, a solution was segmented into four phased releases. Although this team was organized by feature team, the Release/Operations team was grouped together as a function team.

Figure 4-9. Example of large project team architecture to support versioned solution releases

Function Teams

Function teams are unidisciplinary subteams organized by functional role. Each function team is responsible for all aspects of their portion of a solution, which usually spans across the whole solution. Typically, function teams are used in the following situations:

• An organization has limited resources to perform a particular function and is unable to have those resources join each feature team. Instead, the resources are grouped into a functional team so they can centrally service all feature teams.

• A functional area is best served by being clustered together with like-minded individuals or when consistency is needed across a solution (e.g., User Interface Design, as shown in Figure 4-10).

  Figure 4-10. Example of a function team

  

• Distributing needed skills across feature teams is not practical (e.g., legacy systems integration).

• An organizational team is unable to be matrixed into a project team, and hence it needs to remain somewhat removed from a project team.

• Unlike a feature team that calls for balanced role representation, there exists a need for a larger concentration of effort to fulfill one or more functional areas within an advocacy group.