Next: References  Up: Opening Abstract  Previous: Appropriate Processes

Beyond the Dogma

What follows are some experientially-based perspectives on positions I have been frequently asked to justify. Each is an arguable position, which implies it has some things going for it, and some things going against it. First, it is important to understand what the positions pros and cons are. Then, the importance of each side must be weighed to understand which of the underlying characteristics are important within an individual environment. The general feeling I have from organizations in the U.S. is that supervisory presence in a meeting often stifles free discussion among an otherwise peer-group. A supervisor's `direct reports' may be on the defensive, and others may not feel comfortable pointing out what could be construed as someone's mistakes in the presence of someone with performance review responsibilities. The drawback to this position is that in many high-tech organizations, technical prowess is a precondition to promotion, and thus the first level supervisory ranks have valuable expertise to share. They also often have a broader project perspective to bring to development discussions. From an organization in Sweden, where supervisors are often integral players on a development team, there is experience where supervisors are active in the FTR processes and their presence is not an issue. I personally know several managers who should never step foot into an FTR, and others who have much to contribute and do so constructively. To understand the cost/benefit of a process, this data is essential. In the IBM of Fagan's time, activities were continually viewed with an immediate bottom-line perspective in mind. The data he collected was essential to the survival of the Inspection process within IBM, and for the rest of us, it proved a key motivator to look further at his ideas. However, all data carries with it a cost of collection, both physical and mental. Data regarding effort expended in individual preparation for an FTR is particularly troublesome, since its collection can not be easily automated, and there are peer and management pressures to be less-than-truthful in many circumstances.

The basics of process control tell us that once we have a process well in hand, monitoring may be reduced to fractional levels to reduce data collection and analysis costs, and thus further reduce overall process costs (noting that data collection is a cost born by the process itself). This is the basis behind things like skip-lot sampling, sampling to various acceptance levels, etc., common in the manufacturing world.

Thus, when implementing an FTR process, it is important to understand where everyone stands on this issue. If managers have been convinced of the benefit through other means, this data may be of little use, and people often resent amassing it, which makes it counter-productive. When we collect data, there should be an ongoing rationale for its use. When the process has been internalized and becomes a normal part of business-as-usual, data collection efforts should be focused on the next generation of challenges confronting the organization.

Why do we organize team meetings? There are many answers. An organizational psychologist may say: to capitalize on group synergy. A project manager may say: to make an event visible, and to make it happen. A sociologist may say: to motivate people to do the best work, since they desire to live up to the group norms of their peers. On the negative side of this issue, Votta discusses the idea of ``meeting loses", where a reviewer, for various reasons, fails to mention in a meeting a problem uncovered in their individual review [Votta'94]. In his study, meeting losses cancel out the gains from meeting synergy, and the meeting ends up adding no value to the process. [Porter, et.al'95] however find a net 33% gain from meetings, once again reinforcing the idea that processes are context dependent. Given that meetings are expensive in staff effort, the rationale and justification of them should be clearly understood. This is so implicit in our thinking that it is rarely stated. Our communications technologies are pushing forward our abilities to work together at a distance. In large corporations, people with the key experience for a development team may be scattered around a state, country, or the globe. When they can be easily accomplished, face-to-face meetings are probably most productive, however there are a wealth of other opportunities technology is opening up for us. One focus for Internet usage is on collaborative development environments: distributed times require distributed thought and distributed processes. Johnson has created a system for computer supported FTR interaction, where participants view documents, note issues, and engage each other in a Delphi-style interaction, all from the screens of their workstations [Johnson'94]. According to the lore, software folks love nothing more than to dig into a problem, re-architect a solution, and then go hack some code. The goal of this rule is to forestall such behavior and keep the meeting on track. The implicit understanding is that there is much material to cover and the team will never get through things otherwise. So how true is this stereotype in your organization? Given that a meeting has gathered people with relevant expertise for the specific material at hand, often a possible solution is worth discussing to some degree: it may help further delineate the problem, or it may provide a long-sought moment of enlightenment to the person charged with providing the fix. This commandment is one I've seen cause much rebellion among technical teams. As a trainer and facilitator, I feel I can best serve a team by making them aware of the commandment's pros and cons, and coming down hard on meeting moderators to keep things on track, in light of the full task they need to cover. Here's another detail that is very culture dependent. The goal is to help motivate and assure preparation by all team members before attending a meeting. There are certainly other methods besides punishing a whole group for the transgression of an individual, many of which may have a more positive reinforcing effect. I recommend that the moderator check in with each reviewer a half-day before the meeting to verify the teams overall preparedness; this provides a friendly nudge to the ill-prepared with enough advance time so they can prepare, and it provides an opportunity to reschedule if necessary without everyone going out of their way to get to a meeting that will be immediately deferred. This idea has been discussed earlier, but here are a few more parameters to consider. What exactly is meant by the term best in that statement? Is it based on data or emotion? From whom? In addition to my earlier assertion that ``best processes'' are subjective rather than objective things, another bothersome aspect of this dictate is an underlying characterization of a process as a fixed, never-changing thing. This runs counter to the prevailing wisdom that all processes can be improved. Start somewhere reasonable and move forward from there. From a reasonable start within an individual team, and with some attention to ongoing process improvement, the process can become `best' within the framework that means the most, that of the team using it. Rifkin takes this to its logical extreme, where every class session he teaches is charged with defining their own individual process [Rifkin & Deimel'94]; this, however will have drawbacks for large projects trying to implement a unified process across the whole development team. The key parameter here is to understand where you are looking for defects. For a design document that was about to be baselined and sent on for further implementation, this statement is often appropriate. However, for a partial design, existing perhaps on a set of foils, without fully specified requirements, I can still productively gather people together to poke around the ideas and help delineate, as a team, viable design alternatives. Often key problems, like an inappropriate design strategy, can be identified at these early stages which significantly reduce downstream costs of regrouping later on. FTRs have proven many times their cost-effectiveness across a wide domain of applications [Ackerman, et.al'89]. However, as a process based on groups of technical personnel, FTRs are certainly expensive. Remember the admonition: When your only tool is a hammer, all your problems look like nails. As software professionals, we have many avenues for defect detection, for example, testing, analysis tools, and parallel development, as well as FTRs. Using them all in their proper proportions becomes a study of cost/benefit tradeoffs and of social issues in acceptance and use by the technical staff. Process engineering, after all, is in understanding the balance.
****************

I have tried to put forth a cross-section of issues in this paper. In designing the best possible FTR process, certainly history provides us solid guidance, however amid the tug of reasons toward and away from a position, one's reasoning should be based on a specific organizational context.
 


Next: References Up: Opening Abstract Previous: Appropriate Processes