Studying the process of software design teams

• Authors: Bill Curtis;Diane Walz;Joyce Elam
• Venue: ISPW '90 Proceedings of the 5th international software process workshop on Experience with software process models
• Year: 1990

In the 1990s we will begin to see software development environments that embed models of the software process in the control of their tools. These process models will too often be based on traditional life cycle models, models of individual activity, or idealized models of team processes. If these environments are to benefit software development they must support team activity rather than hinder it. The crucial issue in developing technology to aid teams is how well the model implemented by the software coincides with a team's most effective behaviors in performing a task. In order to get a broad perspective on how software design teams solved problems, Herb Krasner and Jeff Conklin videotaped 37 team meetings over five months of an MCC team designing an object-oriented database.In a doctoral dissertation using these data, Diane Walz (1988) devised a method for scoring the verbal protocols of design teams into categories tailored to the design process. Her analysis emphasized the team's information requirements and their effect on the group process, especially information sharing. She began by assuming that the conflicts within a software design team were not solely the result of incompatible goals and/or opinions, but also represented the natural dialectic through which knowledge was exchanged and terminology was clarified (Walz, Elam, Krasner, & Curtis, 1988). Analyses of the protocols and follow-up questions to team members indicated that design meetings were generally dominated by a few individuals to whom fellow participants attributed the greatest breadth of expertise. These individuals appeared to form a coalition that controlled the direction of the team.A fundamental problem in building large systems is the development of a common understanding of the requirements and design across the project team. Of the few studies of multiple agents performing complex design activities, none have investigated the integration of knowledge across experts in different domains or the communication processes required to develop a common model of the application and the system design across the entire design team. As a result, design in team situations is typically treated as an outgrowth of individual design activities, avoiding the multi-agent problem-solving and communication issues.The transcripts of team meetings reveal the large amounts of time designers spend trying to develop a shared model of the design. For instance, many design meetings may be devoted to filling knowledge gaps, such as lectures about the application (e.g., talks by outside experts on object-oriented programming or the requirements for object repositories). Next, the team must come to a common understanding of the semantics of the symbol or diagrammatic system they are using to represent design information. The longer they go without establishing this consensus, the more communication breakdowns will occur. Next they must try to comprehend the differences in their initial model of the application and the design solution. Without understanding these individualized starting points, the team is unable to detect when a breakdown in establishing consensus is likely to have occurred. Finally, they must come to negotiate a common understanding of the architecture. This common model allows them to work on different components of the system without violating interfaces or architectural constraints. Problems of this nature usually do not show up until integration test, and are much more expensive to remove than they would have been in the design phase.The existing research on team problem-solving led us to expect monotonically increasing consensus among design team members on design issues. A simplistic model assuming that cooperative design activity requires agreement among team members lead us to expect this monotonic increase. However, an interesting pattern in the verbal acts representing agreement within the team was observed across the 17 meetings that constituted the design phase of this project. As the data in Figure 1 demonstrate, Walz observed a surprising inverted U-shaped curve (verified through logistic regression) that characterized verbal acts of agreement. The level of agreement increased until meetings 7-10, when the design team released a document presenting its functional specification in response to customer requirements. In subsequent meetings the level of agreement began to decrease. There are several possible explanations for the observed pattern.First, there may be an inflection point in the middle of a group process where the team is forced to come together and agree on their technical plan and operating procedures. Gersick (1988) observed such a point in a study of project teams. Rather than the standard group process of form-storm-norm-perform, Gersick suggested there came a point halfway through a group project where the team faced its lack of progress during its early stage, and came to a consensus about how it would attack the objective. Often this critical point involved an insight into the problem's structure. Group process was relatively stable and productive until the delivery of the final product. Although this model suggests that significant changes occur in a group's process midway through its history, it does not explain the downturn (the drop in consensus) of the inverted U-shaped curve. Gersick's model may be more descriptive of temporary teams that are asked to perform tasks out of their area of expertise.A second hypothesis is that this curve results from the integration of two processes occurring in teams. There is a intellectual process of integrating technical ideas and resolving inconsistencies. Overlaid on this process is a project process of meeting scheduled milestones. Meeting the milestone forced a contrived consensus that did not resolve underlying technical disagreements, but allowed production of a document. However, the existence of this document disguised the lack of intellectual integration that remained in the design. These disagreements began to dominate design meetings immediately after document delivery. Having completed their obligations the team was free to reopen the conflicts that were temporarily suspended to meet the milestone. Thus, we would expect this inverted-U phenomenon of agreement to recur whenever the team must achieve a shared (rather than individual) milestone. Since we only looked at the design phase, Walz could only observe one such curve. Had we studied behavior across the entire development phase Walz might have uncovered an oscillating curve representing the level of agreement with the upper inflections occurring at deadlines for milestones. However, the magnitude of these oscillations should decrease over time as the team resolved more of their underlying technical disagreements.A third explanation is not unlike the second, but emerges more from modeling the stepwise refinement (decomposition) of the artifact. In this model the team struggles to resolve technical conflicts at the initial level of refinement required of them (e.g., functional specification, system architecture, detailed design, etc.). After the artifact at this level is produced, the next level of refinement presents many new technical issues over which the team must struggle toward consensus. Thus, we would again expect to see an oscillating curve of agreement as succeeding stages of refinement present new sets of problems for the team to resolve. These continuing issues would not be surprising since the development team shifts its attention from the early concern with application structure to a later concern with how to optimize the software on the available hardware architecture. This model might differ from the second by not requiring a decreasing magnitude for the oscillations, since each oscillation represents a new wave of problems, rather than the continuing struggle to resolve disagreements that have existed from the project's start.Of these three explanations we prefer the second because we believe that on many, perhaps most, real projects there are people present who recognize early some of the fundamental problems that must be resolved. Their understanding of these problems cuts across several levels of abstraction or refinement and they are able to articulate the implications of these issues for several levels of refinement early in the design process. The levels of refinement argument may be relevant in that the problems attended to early are those that must be resolved to produce the artifact. Thus, levels of refinement provides a model for selecting among problems in order to make progress toward a milestone. Much research lies ahead before we can feel comfortable selecting among these speculations or other explanations of these data. We have concluded that the team design process should be modeled as a multi-agent cognitive process, on which the social processes of role development, coalition formation, communication, etc. are superimposed. In order to explain the team design process, we model group dynamics by their effect on team cognitive processes.