Work Together as One Team

People are the project's most important asset. Software development has become a team sport, and an iterative approach to software development impacts the ways in which you organize your team, how you should communicate within a team, the tools your team needs, and the values of each team member.

Traditionally, many companies have had a functional organization: All the analysts are in one group, the designers are in another group, and testers are in yet another group ”maybe even in another building. Although this organizational structure builds competency centers, the drawback is that effective communication among the three groups becomes compromised. Requirements specifications produced by analysts are not used as input by developers or testers, for example. This leads to miscommunication , extra work, and missed deadlines.

Even worse than a functional organization are matrix organizations, where, for example, an analyst works on several different projects at the same time and is not really a full part of a team. This leads to considering your most valuable asset, people, as interchangeable parts .

Functional organizations may be acceptable for long- term waterfall projects, perhaps as long as 18 months or more. But as you move toward iterative development and shorter projects of nine months, or even two to three months, you need a much higher bandwidth of communication between teams . To achieve this, you must

• Organize your projects around cross-functional teams containing analysts, developers, and testers.

• Provide teams with the tools required for effective collaboration across functions.

• Ensure that team members have the attitude of "I'll do what it takes to get high-quality working software," rather than "I'll do my small part of the lifecycle."

Let's take a closer look at each of these points.

The project team should consist of analysts, developers, testers, a project manager, architects , and so on. You might say that this works for small projects, but what happens when projects become bigger with, say, 50 people involved? The answer is to organize around the architecture, ^[6] to group what we call "teams of teams" (see Figure 2.8). Have an architecture team that owns the architecture; the architecture team decides on the subsystems and the interfaces between them. Then, for each subsystem, have a cross-functional team consisting of analysts, developers, and testers who work closely to ensure high-bandwidth communication and fast decisions. They communicate with other teams primarily through the architecture and the architecture team.

^[6] For more information on how to organize your team and other management issues, see Royce 1998.

Figure 2.8. Teams Organized Around Architecture. If the project is too big to have everyone on one team, organize teams around the architecture in "teams of teams." An architecture team owns the subsystems and their interfaces, and a cross-functional team is responsible for each of the subsystems.

For a team of analysts, developers, and testers to work closely together, they need the right infrastructure. You need to ensure that all team members have access to the requirements, defects, test status, and so on. This, in turn , puts requirements on the toolset your team will need to use. Communication between the different team members must be facilitated through integration between their tools. Among other things, this increases the return on investment in tools, allowing round-trip engineering and synchronization of requirements, design elements, and test artifacts.

You should also streamline the process, that is, reduce the amount of documentation to the extent possible, thus reducing the time spent on producing and maintaining documentation. In order to do this, you must replace their communicative value. One way to do this is through increased face-to-face communication. Consider having more team meetings, encourage direct communication rather than communication by e-mail, and co-locate team members whenever possible.

Working together as a team also enforces joint ownership of the final product. It eliminates finger-pointing and assertions such as " Your requirements were incomplete" or " My code has no bugs ." ^[7] Everyone shares project responsibility and should work together to solve issues as they arise.

^[7] For more on this topic, see Kruchten 2000a.

Summary

An iterative approach increases the need for working closely as a team. Avoid functional organizations, and instead use cross-functional teams of generalists , analysts, developers, and testers. Ensure that the tool infrastructure provides each team member with the right information and promotes synchronization and round-trip engineering of artifacts across disciplines. Finally, make sure that team members take joint ownership of the project results.