Weinberg on the Essential Team

No matter how strong or smart one person may be, there will always be tasks that person cannot do alone. A few individuals might have the strength and skill to build their own house, but no one person is going to build a hotel. Whenever human beings attempt to build something larger and more complex than one person can handle, they form teams. Indeed, among all living creatures, human beings are the teambuilders par excellence.

Understanding the fundamentals of teamwork is more important in software engineering than in any other profession. Simply put, teamwork is needed to create large, complex systems, and creating software is the most complex intellectual task that human beings have ever attempted.

Fault Location Teams Are a Good Way to Start
Every software manager knows the "99% complete" fallacy. Everything seems to be going according to schedule-until we start testing the software and things begin to slow down. One reason for this slowdown is that testing only reveals the presence of problems; it doesn't fix them. When tests reveal a software failure, the work of correcting that failure has just begun. Before we're finished, someone must locate the code containing the fault that led to the failure, and then someone responsible for that code section must resolve the problem by fixing the code. In short, the failure report must eventually reach the hands of a person responsible for the code in which the repair will be made. One of the major reasons projects slip their schedules is the time between receipt of failure reports and the time the eventual solver receives them.

In a tiny system with only one programmer, locating the proper person would be no problem. In larger systems with more people, however, each person is responsible for only a part of the whole. As systems grow larger, failure reports are seldom handled by the first person who sees them. In an organization under the stress of increasing customer and problem demands, many reports cycle around from desk to desk, some for months, or years.

One of the easiest places for a manager to appreciate teamwork is the impact of a fault location team on project schedules. Any software organization, no matter how badly it's been doing so far, can immediately benefit from the creation of fault location teams. These teams are assembled and trained to work together on fault location and to prevent the problem of failure reports circulating endlessly and failing to reach the person who can solve them.

The manager's first job is to select a diverse and compatible fault location team and free their time from other tasks. The manager's next job is to get this team together in an appropriately furnished room with good access to all the information they might need, and then prevent interruptions from outside the team. The team's mandate is to locate as many faults as they can in a single session. The single session limit is essential because it concentrates thought and eliminates administrative burdens.

Several of my clients use a system in which each morning a different team takes a tour of duty. When a failure report has been handed off more than three times, or when it has been in the system for more than three days, the manager puts the failure on the agenda for that morning's team.

Creating fault location teams is an effective management intervention in crisis situations, where many organizations spend a lot of their time and emotional energy. Fault location teams can be assembled quickly and immediately begin to handle failure reports faster than other approaches. By