Self-Organization Extensions

As the number of subteams within a project team increases , the organizational framework needs to be expanded from a team framework within which individuals operate to a project framework within which multiple teams operate . The basics of self-organizing teams from Chapter 3 apply to larger teams, but there are extensions to those ideas that also apply. Creating a self-organizing framework for a larger team entails:

The organization, through the project manager, is responsible for staffing the project with the right people. At the team level, getting the right people means finding those with appropriate technical and behavioral skills. At the project level, the project manager works to ensure the right leaders are assigned to each team. As with individual team members , the project manager should have the authority to reject any proposed team leader.

The project management team has the responsibility to ensure everyone understands the product vision and his or her subteam's assignment within that overall vision. For larger projects the subteams may even go through a visioning exercisevision box, elevator testfor their individual piece of the product. An architectural overview, component descriptions, and interface definitions can help each subteam understand both the big picture and its piece of the product.

In addition to understanding its product responsibilities, each subteam also needs to understand its roles with respect to other subteams. For example, feature teams need to understand how they are expected to interact with the architecture team. Larger projects are almost always, in some fashion, distributed projects. Obviously next -door buildings facilitate more frequent face-to-face meetings than a Chicago-Bombay separation, but this does not obviate the fact that larger teams face issues related to distance, culture, and expertise. Defining subteam roles and responsibilities within the hub organization is an initial step in dealing with distribution issues.

As I was working with one client, a very large IT organization, several people lamented the lack of communicationa common complaint. However, another individual saw it differently: "We have too much communication. Just look at my email inbox each morning." He was right. What this organization lacked was not "communication," but a culture of collaboration , of jointly working on issues rather than slinging emails and documents at each other. Teams need to figure out new and creative ways to collaborate. For example, teams can use the concept of traveling pairs from software development. As I've recommended elsewhere, "Every other iteration, a pair from one feature team could travel to the second site where they then pair with developers from the second team. Traveling pairs transfer knowledge about the team's features at a working level. No matter how good the architectural decomposition of a product, two distributed teams working on the same product need a certain amount of working-level conversation and collaboration" (Highsmith 2002). Exchanging people will be much more effective than exchanging paperwork.

One important inter-team task is managing dependencies, a task frequently relegated to the project manager. All too often dependency management falls into the same trap that serial development doesmanagement by documentation rather than conversation. Within a team, the team members themselves manage dependencies between features. They identify dependencies in planning meetings and note them on feature cards, suggesting alternative scheduling when they anticipate problems. They also identify dependencies during daily team integration meetings. These discussions not only identify the dependency, but also the exact nature of that dependency and how to assign work to allow for it.

The same discussions occur at the inter-team level when feature team members (often team leads and senior engineers ) get together to identify dependencies and determine how to handle them. The project manager may know about dependencies, but the team members have the detail information required to figure out how to work with them. Conversations backed up by informal notes can be effective and much quicker, even in fairly large teams, than relying on formal documentation and approval processes.

Although there are practices that create team-to-team interaction (e.g., integration meetings), there is no small set of practices that covers all the situations encountered in larger projects. Each project team is unique, and the project management team will need to experiment with interaction practices just as it does with technical ones. [1] That said, there are several key practices that can help create the right kinds of relationships and interactions among various teams. In this environment the project manager's role should be to facilitate the interactions between the teams, not the specific activities each team uses to produce deliverables. One practice is the commitment-accountability protocol described later in this chapter. Another such practice is to establish inter-team rules of engagement and accountability. As an example, Extreme Programming proponents have developed a set of rights that govern the interactions between customers and programmers.

[1] For one such practice, work-state information management, see (Highsmith 2000), Chapter 9.

Manager and Customer Rights (a sample)

Programmer Rights (a sample)

Another example would be the rules of engagement between architecture and feature teams within a project.

Feature Teams

Architecture Teams

These rules of engagement, which evolve over time, guide the integration of teams within a project. Rules of engagement place a context around overall collaborative efforts and specific documents. Without rules of engagement, teams will be constantly dragging the project manager into decisions that they should work out among themselves.

Part of team self-discipline is developing these rules of engagement and then working within them. Within a team there are always conflicts whose resolution relies on the leader's coaching skills. Similarly, conflicts arise between teams; any time there is interaction and coordination, conflicts are inevitable. Again, one of the project manager's roles is to coach the teams in resolving conflicts, solidifying how the rules of engagement actually work.

Framing decisions becomes more difficult, and more important, as project organizations grow to multiple teams. Decision making should be distributed. For example, feature teams decide on the details of features assigned to them; the architecture team decides on platform issues; the integration team decides on the integration tools. However, the distribution should also be appropriate. Teams should not make unilateral decisions on items that impact another team without engaging that team in the decision process (a rule of engagement). So, for example, a team could not change an interface design without coordinating it with other teams that use that interface. Framing decisionsdeciding which decisions are within the purview of an individual team, which decisions are left to the project manager and leadership team, and which decisions require engaging with other teamsis a critical piece of building large adaptive project teams.

Related

Категории