Solutions

I've heard it stated that "[to] point out issues without providing solutions is whining," and because I don't want to whine, here are some recommendations for new practices to add to XP (replacing existing practices) that enable XP to scale successfully.

Based on my experiences, the following new practices are required to support a multiteam XP environment:

• Loosely coupled teams

• Team coordination layer

Loosely Coupled Teams

It seems clear to me that to effectively scale XP requires choosing the latter of those two options for scaling XP specifically, to create a collection of loosely coupled collaborating teams. This is both a practice and a philosophical position. The practice part comes from breaking the project into these teams; the philosophical part is to keep these teams focused and functioning in the loosely coupled way. It could be argued that this practice replaces many of the XP practices, including PP, collective ownership, and coding standards, in the highest level of the project and imposes requirements for a new practice.

My experiences in multiple-team development lead me to a strong recommendation: The "prime" team should not dictate or impose a process on the "subcontracting" teams.^[1] However the prime team should indeed impose the feature rollout plan (the equivalent of the XP "release plan") on the teams. Our approach imposed the order of deliverables, used a consensus of the development teams to decide the dates, and adjusted the dates as necessary to meet the business objectives.

^[1] This recommendation is counter to that proposed by Carmel [Carmel1999], but this type of dictation is almost a guarantee for failure; see [Battin+2001] for further explanation.

This position leads to a collection of subcontractors, each with their own development process but with shared dates and deliverables. Because the teams have their own development processes, there's no effective way to coordinate any of the rules of the game specifically, rules that could be used to share development across the teams, such as the coding or change management rules. Because there's no effective means to ensure the same rules across the teams, it is unlikely that any coding can occur across teams, obviating the need for PP or collective ownership at the "across the teams" level.

Team Coordination Layer

To resolve the issue with coordination, a coordination layer is added (arguably outside the scope of XP) to the project to support the team interactions. This can be viewed as layering the project structure, where at the highest level in the hierarchy there is a collection of teams being coordinated. At the bottom are the individual teams that are doing the work. This type of structure can go on as necessary, enabling the projects to scale to enormous scope.

The team coordination layer replaces the metaphor, PP, collective code ownership, and on-site customer practices with an "Architecture Lite," adds a role ("liaison"), and augments planning game to work with multiple teams, keeping the project needs in full focus at all times.

Up-front Architecture Lite

The division of tasks among the various teams must be rational a team should work a problem for a reason. That reason can be based on the availability of workers, but that should be the last reason on the list. Indeed, the tasks should be allocated to teams in a way that minimizes the required day-to-day communication among the teams to get their job done. This, in turn, requires that some structure be provided to the solution space to direct this allocation. Traditionally, this would be the role of the "architect" and architecture in the project.

To meet the needs of an agile project, though, often a full "architecture" is not required. Instead, an "Architecture Lite" is more appropriate [Coleman2000; Toft+2000]. An Architecture Lite fully describes the system architecture but at a high level of abstraction. The description includes both structural and behavioral aspects of the system. In our use of this approach, we used the Architecture Lite to define and use a few strongly held key principles. Abstractly, these are:

• Low coupling among the elements

• Well-defined interfaces

• Concise semantics for the element behaviors

This Architecture Lite replaces metaphor and PP, the latter from the perspective of its use to share system design information. One of the keys in my experiences was to provide a stronger metaphor than the metaphor practice typically provides. Indeed, we defined a partitioning of functionality and behavior into "boxes" that formed the architecture. This enabled us to then carve up the work and assign it to the teams in a way that maximally leveraged their particular strengths (which include not only their capabilities but any conveniences caused by their location).

The intent is to enable agility in the large projects; agility implies emergent behavior. We rely on these principles to guide us when a behavior emerges. Because the elements' behavior and interfaces were well defined, they could be developed in a context that was shared among the teams. Because the network elements had low coupling, each team could run independently of both any other team and the architect. The net result of managing complexity at this level is that we are free to distribute the development of any element to any team.

Note also that one of the roles of the PP practice was to ensure that design knowledge permeated the team. The Architecture Lite replaces this role at the highest level in the project, explicitly acknowledging the loss in fidelity of the information.

Liaison

The role of liaison was one we stumbled on but is critical to success in a multiteam environment [Battin+2001]. Liaisons are members of the various teams that join forces to develop the Architecture Lite. By collaborating on the foundation of the system, each liaison has intimate knowledge of the rules of the system the principles of the system. Because each team has a liaison, this person can act as the conscience of the Architecture Lite, to ensure that the principles are kept. The liaisons enable the teams to work independently by filtering the required communication among the teams, because they understand intimately the roles of the other teams. As the project evolves and emergent behaviors cause the Architecture Lite to become invalid, the liaisons initiate changes to the Architecture Lite so that it can continue to be a useful tool.

The liaisons also fulfill an important role abdicated by the Architecture Lite they are the keepers of the high-fidelity knowledge of the code that implements the Architecture Lite. In XP subteams, any member should be able to fill this role, reducing overall project risk (by reducing the team's "Bus Number").

Team-wise Planning Game

The Architecture Lite enables a rational distribution of work across the teams, and the liaisons enable each team to proceed without much interaction, but neither of these resolves the issue of coordinating when such work is completed. Planning across teams is a difficult problem; each team can have its own set of issues. A team-wise planning game (TPG) is similar in many ways to the existing planning game practice, so it is more correctly viewed as an enhancement to that practice rather than a new practice.

The key aspect of this approach is to agree to participate in the approach throughout the project; the TPG coordinates the development of those features across the teams. Each team is represented in the TPG much as the individual developer is represented in the planning game. However, instead of representing an individual, they represent the team. They sign up for the work associated with their team, based on the structure provided under the Architecture Lite. If the new work breaks the architecture, the architecture is reworked for the next iteration (as the liaison role notes).

In the project discussed in [Battin+2001], we had a team of drivers of this coordination. In a certain sense, this team interacted with the customer to determine what the important business feature was and then interacted with the multiple development teams (as proxy customer?) to coordinate their activities. In the role of proxy customer, the coordination team could ensure that the teams worked on what was important from the global perspective.

We had weekly teleconferences among the teams to ensure that information about progress was being shared and to understand the impacts of any late team on any other team's progress. Often, the tasks were interdependent at the system level, in the sense that some portion of the system required both teams to complete their work to support some systemwide behavior. We used the weekly meetings to remind the teams of these dependencies.

This approach works best with subteams using agile development methods, because they are best able to respond to changes in requirements from iteration to iteration.