Software Development as a Team Activity

Software development has become a team sport.

”Grady Booch ^[2]

^[2] A personal conversation with Dean Leffingwell.

At some point, the game changed. Why? Humphrey [1989] observed that

the history of software development is one of increasing scale. Initially, a few individuals could hand craft small programs; the work soon grew beyond them. Teams of one or two dozen individuals were then used, but success was mixed. While many organizations have solved these small-system problems, the scale of our work continues to grow. Today, large projects typically require the coordinated work of many teams.

"The history of software development is one of increasing scale."

The requirements management process touches every team member, albeit in different ways.

Humphrey goes on to observe that complexity continues to outpace one's ability to solve these problems intuitively as they appear. For example, we were involved in a requirements project that simultaneously affected approximately 30 products in a broad product family. The requirements being generated influenced, in real time, the software being written by more than 800 programmers at distributed locations. Success required intense coordination of a "team of teams" all working in a common methodology to address the requirements challenge.

What's to be done? Clearly, we have to make the "team thing" work and work well. As Boehm [1981] points out in the COCOMO cost estimation model, the capability of the team has the greatest impact on software production.

Effective requirements management can be accomplished only via an effective software team.

Davis [1995] supports this conclusion in his discussion of team productivity: "optimizing the productivity of all individuals does not necessarily result in optimizing the productivity of the team." So, it seems logical that we invest some of our resources in making software teams more productive.

Requisite Team Skills for Effective Requirements Management

In order to help the team, we've organized this book around six team skills that are necessary for a modern software team to successfully address the requirements challenge.

• In Team Skill 1, Analyzing the Problem, we develop a set of techniques the team can use to gain a proper understanding of the problem that a new software system is intended to solve.

• In Team Skill 2, Understanding User and Stakeholder Needs, we introduce a variety of techniques the team can use to elicit requirements from the system users and stakeholders. No one set of techniques will work in all situations; nor will it be necessary for the team to master all of the techniques. But with a little practice and some judicious picking and choosing, the team will gain a much better ability to understand the real needs that the system must address.

• In Team Skill 3, Defining the System, we describe the initial process by which the team converts an understanding of the problem and the users' needs to the initial definition of a system that will address those needs.

• In Team Skill 4, Managing Scope, we arm the team with the ability to do a better job of managing the scope of the project. After all, no matter how well understood the needs are, the team cannot do the impossible , and it will often be necessary to negotiate an acceptable deliverable before success can be achieved.

• In Team Skill 5, Refining the System Definition, we help the team organize the requirements information. Further, we introduce a set of techniques the team can use to elaborate on the system definition, or refine it to a level suitable to drive design and implementation, so that the entire extended team knows exactly what kind of system it is building.

• Finally, in Team Skill 6, Building the Right System, we cover some of the more technical aspects of design assurance, testing, and change management, and we show how traceability can be used to help ensure a quality outcome.

Team Members Have Different Skills

One of the most interesting things about teams is that individual team members have different skills. After all, that's what makes a team a team. Royce [1998] points out that

balance and coverage are two of the most important aspects of an excellent team. . . . A football team has a need for diverse skills, very much like a software development team. . . . There has rarely been a great football team that didn't have great coverage, offense, defense, and special teams, coaching and personnel, first string and reserve players, passing and running. Great teams need coverage across key positions with strong individual players. But a team loaded with superstars, all striving to set individual records and competing to be the team leader, can be embarrassed by a balanced team of solid players with a few leaders focused on the team result of winning the game.

In the software team, we hope that some players have proven their ability to work with the customers effectively, that others have software programming abilities , and that others have testing abilities. Still other team players will need design and architecture abilities. Many more skills are required as well. We also expect that the requisite team skills for requirements management will affect various members of the teams in various ways. So, in a sense, we'll hope to further develop every team member's ability to help manage requirements effectively. And we'll try to indicate , where we can, which team members may be best suited to a particular and necessary skill.

The Organization of Software Teams

Software development is exceedingly complex, and the domains in which we apply our skills vary tremendously. It therefore seems unlikely that one specific way to organize a software team will work in all cases or is inherently more efficient than other approaches. Nonetheless, certain common elements occur in many successful teams. Therefore, we think it's important to establish a hypothetical team construct. But rather than invent an ideal team, which would be too easy and too academic, we decided to pattern our hypothetical team on a real software development team.

The team we'll model is based on a real-world software team that has proved effective in two major areas: (1) effective requirements management and (2) delivery on time and on budget. (Of course, we believe that this is an obvious cause-and-effect relationship!) Yet we also admit that many other skills must be present in a team that truly delivers the goods year in and year out. In our case study, the team works for a company called Lumenations, Ltd. that is developing a next -generation "home lighting automation system" for high-end residential use.