© 2000 John Suzuki, www.jksassociates.com
Executing software development activities across geographic and time zone boundaries presents unique challenges to both management and practitioners. These issues apply to any discipline in which close coordination is required between members of a group. Although tools and technology do help to improve productivity within a team, the largest gains for improving coordination are all related to the human aspects of relationships between people, teams and organizations.
Introduction
Executing software development activities across geographic and time zone boundaries presents unique challenges to both management and practitioners in today’s business environment. The problems of separated groups are becoming a more common challenge due to business needs and the requirement for multiple (and even multi-national) locations of modern companies. These issues apply to any discipline in which close coordination is required between members of a group. Although this paper discusses the challenges faced in forming and managing a Software Quality Assurance (SQA) group, the principles described here apply to many other multi-site development activities. When we use the term SQA, we are referring to a separate group from a testing organization.
While it may be intuitive that geographical separation leads to problems in maintaining consistency between groups, the actual problems are not easy to solve. The major problem faced by multi-site operations is difficulty in communication between team members. The barriers to communication that cause the problem equally limit the solution.
Historically software development has been an extremely difficult and time-consuming process and requires more than just common access to source code. Proper development in a distributed environment requires tightly coupled work and extra effort in managing the various locations.
By analogy, splitting SQA activities across two different locations and time zones would make SQA coordination difficult to manage. We have noted that coordination of SQA activities across multiple sites is also made difficult by the breakdown in normal communication channels that occurs when groups are not co-located. SQA coordination is made even more challenging because of the dynamic nature of a software project as it moves to completion. SQA activities, such as audits and reviews, are paced by the development work, and are therefore constantly struggling to stay current.
Coordination and collaboration in development and SQA teams It is generally recognized in the software community that proper coordination is a major contributor to project success in large-scale development. Over the past decade, researchers and some progressive software organizations have been actively studying an area called coordination theory [1,2,3,4]. This interest is motivated by the continued growth in the size and complexity of application development projects and the use of the Internet and World Wide Web as virtual development tools. Another driver is the realization that the context of a software work environment and the formal and informal mechanisms of communication are important to project success, especially in large development projects. The desire to improve coordination has also spawned a number of popular computer-supported cooperative work (CSCW) tools and teamware applications that have reinforced the importance of coordination theory.
Coordination has been defined as the managing of dependencies between activities [1]. Kraut and Streeter [2] have combined the various definitions from other coordination researchers and formally defined coordination as "the direction of individuals’ efforts toward achieving common and explicitly recognized goals and the integration or linking together of different parts of an organization to accomplish a collective set of tasks." In a software development environment this typically means that a common definition of the project exists, all developers are striving to build and organize the various parts so they fit properly, and that everyone is sharing information and coordinating design activities as the project proceeds. In essence, all the information and activities are being integrated so the application can be handed off to the customer in an expeditious fashion.
In a typical SQA organization, quality assurance information and activities must also be shared and coordinated. Like the development team, the SQA team must also have a common goal or vision. The goal might be a certain level of project audit coverage, a measure of the overall compliance to process and work product standards, or a standard measure of the quality of the tested application. Unlike the development team, the SQA organization has another constraint; namely, it must work in parallel with the development organization scheduling work product or process reviews and audits as the development team executes their planned activities. Audits and reviews cannot be performed unless the development team is about to or has recently completed that software activity. As a result, SQA schedules and audit activities must remain flexible to accommodate schedule slips, feature additions, high bug rates and design changes that occur regularly in software projects. This requires a higher level of coordination within the SQA organization in order to free up SQA resources to address these unplanned tasks. Additional coordination among SQA engineers will be required to insure that common audit results are obtained from the unplanned development activities throughout the entire organization.
Barriers to coordination
We have experienced and identified a number of barriers to coordination and collaboration with multi-site SQA teams. They include:
- Physical separation
- Loss of ad hoc communication
- Lack of contact among team members
- Duplication of processes
- Time zone changes
- Time to initiate contact or communication
- Communication differences or preferences
- Lack of trust
- Personal work style differences
- Different backgrounds of team members
- New team formation
- Not realizing there is a need to communicate
Physical separation
The greatest barrier to SQA coordination is the physical separation of the SQA team members across different locations. We have found that the separation of team members reduces both the opportunity and frequency of formal and informal communication. This observation is supported by several studies on coordination [2,5,6]. These studies show that informal communications are reduced when groups are separated across distances. The authors state the importance of informal, unplanned, and spontaneous communication in supporting coordination and team collaboration in software development projects. Despite being members of the same SQA team, physical separation seems to cause a number of side effects that affect proper coordination. These side effects include unique subteam perspectives (caused by geographical and culture isolation), location cohesiveness (adhering to a particular location’s set of internal practices) and unwillingness to share information and knowledge (caused by a lack of trust and a lack of familiarity with other team members). These are not intentional actions but seem to be common human traits that arise naturally from separation.
Loss of ad hoc communication
We have also found that distance makes it much more difficult to carry on informal communication. If a SQA team member is not available locally because his or her office is located at another site, the opportunity for informal exchange is not likely to occur. Grinter, Herbsleb and Perry [5] describe a similar problem in their organizations and attribute the problem to fewer opportunities and higher cost. Fewer opportunities, in a broad sense, refers to the next chance that an individual is available to see you-usually determined by walking by their office. This opportunity will not occur or occur infrequently if the team members are not co-located. They describe higher cost as the difficulty, inconvenience, and frustration in communicating with distant groups. We have also experienced the same difficulty in communication.
There is also a tendency to follow the old cliche "out of sight, out of mind." When you do not see someone on a regular basis, there is a tendency not to call them or to inquire about the status of their activities. We also have noticed that we lose other informal exchanges such as meetings in the coffee room, lunchroom or at the "infamous" water cooler due to location separation. The impact of this loss of informal communication is usually highly underestimated. Kraut and Streeter [2] found in their study that informal communications is the primary way information flows into and through research and development organizations.
Lack of contact among team members
An unanticipated barrier to coordination occurs from the lack of contact among team members. For example, the lack of contact prevents team members from knowing the daily schedules or availability of other team members. The lack of informal contact usually prevents team members from knowing who is on vacation, who is off-site for training, who is taking a holiday or who is absent due to illness. This lack of contact makes it difficult to coordinate SQA schedules and makes it less likely that team members will take the time to try to contact other team members at another location.
Herbsleb and Grinter [6] found several consequences from the relative lack of casual contact among software developers. They reported that unplanned contact seems to be one of the primary mechanisms that bring conflicts and issues to light within a development organization. They found that the lack of unplanned contact made it much less likely that conflicts and issues would surface. As a result, many more conflicts went unrecognized until much later in the development lifecycle. Addressing the problems later in development was likely to cost the organization more in terms of time and money. Another consequence that they listed from reduced contact was the general lack of information across the various locations. This included how they do their work, what were the most important issues to them, location specific terms and language, and various responsibilities and expertise of team members. Harder to measure is the loss of gossip and group bonding. From a SQA perspective, we found similar consequences. For instance, we did not realize early on in the team formation process that we were performing audits and reviews in a different fashion. There was no awareness of any conflicts in the way we performed our responsibilities. We also realized that we interpreted various SQA processes descriptions differently. If a conflict had been surfaced earlier, the teams at both locations could have resolved the differences at that time.
Duplication of processes
We have also found that the duplication of key SQA processes led to a loss in coordination. This was partially a result of the separate evolution of the basic audit process at each location and the fact that different development processes were used in each location. Being new, the team had few defined processes or standards in place. An audit of a development process may have been conducted in a slightly different fashion by the two locations. The geographic distance between the two sites increased the tendency of the team not to check with each other to see how a particular process was implemented, or to see if their process could be used unmodified at the other location.
Time zone changes
Although we experienced only a three-hour time separation, it was long enough to experience some coordination difficulties. Because of the time zone difference, the effective business time for the SQA team was reduced from 8 hours to less than 5 hours a day. Team meetings, videoconference calls, and telephone exchanges had to be scheduled to insure the availability of both conference rooms and video equipment, as well as the various team members. Different time constraints due to commuting, different lunch hours, and quitting times, all contributed to a reduction in coordination of group activities and scheduling.
Time to initiate contact or communication
The amount of time to initiate contact or communication can sometimes be a barrier to coordination. Communication across different locations sometimes requires multiple attempts to reach an individual. You do not have the luxury of walking down the hall to see if that individual is available. If too many attempts at contacting are required and the time for response to a request is too lengthy, the initiator is not likely to try again in the future. If responses to telephone voice messages or emails take too long, there will probably be a tendency not to call or email that individual in the future. If the time to initiate contact or communication with someone at a different location is too high, the tendency is to have communication with those who are the most familiar to you, i.e., at the same location. These natural human behaviors only lead to more coordination problems and further isolation of the groups.
Communication differences or preferences
Another barrier to SQA coordination is the communication differences and preferences of the various team members. Some team members may prefer telephone conversation while others prefer email. The telephone is a great tool for urgent conversation but suffers from not knowing if the other person will be available to pick up the call when you need a quick reply to a question. Because of the immediacy of the technology, the telephone is generally considered intrusive and disruptive. Email generally is less intrusive but suffers from not being read or answered in a timely fashion. Another problem with email is that it is hard to gauge the urgency and importance of the message. In addition, with an ever-increasing load of email being received, responses to those you do not know well may be delayed. Still others may prefer face-to-face communication to the telephone or email, especially if important messages or information (i.e., layoffs, site closures, reorganizations) are being communicated or transferred. If face-to-face communication must occur, it suffers from the time delay until both parties can physically get together. If differences exist in communication style, there may be a reluctance to communicate with other team members. Ultimately this leads to some loss and a higher cost in coordination.
Lack of trust
During the development of the multi-site SQA team, trust was not originally perceived as an issue or barrier to coordination. The team communicated by email and with videoconferences on a regular basis. We noticed however, that after the team met face-to-face for the first time for a team building session, the relationships between the team members and the project activities changed. The consensus from team members was that the SQA individuals from different locations seemed to work better together. There was an improved sensitivity and understanding to the problems that each location had to deal with. Project problems were resolved faster after the team building session. Part of this improvement is attributed to increased familiarity with each other and an increase in trust among the various team members. The remainder can be attributed to the feeling that both groups now realized that they were dealing with the same problems and situations on all projects. We believe that both locations finally felt that they were actually part of the same team despite being physically separated.
Personal work style
differences Personal work style differences definitely affect coordination. Some individuals prefer to work collaboratively, while others prefer to work alone. For some individuals, the analysis of documentation is preferred to making appointments to question and talk to individuals. The nature of SQA generally requires the auditors to work independently on their assignment and come together infrequently to report their experiences and progress. This approach generally reduces the interaction with the various team members. The independent work style of the SQA engineers tends to promote the lack of coordination since they tend to focus only on their primary audit and review responsibilities. The SQA manager also has less visibility into what each engineer is doing. This is detrimental since the manager cannot exercise managerial powers to counteract the forces that degrade coordination. Inexperienced SQA engineers may have a tendency not to seek out the more experienced SQA engineers for help since they feel they are interrupting. We have noticed that some SQA engineers prefer to make a detailed plan and follow it closely. Other SQA engineers prefer a more flexible schedule and plan and are thus more tolerant to disruptions and development changes. A more flexible plan however, requires extra concentration so the SQA engineer can finish his or her assigned and scheduled audit activities.
Different backgrounds of team members
When the SQA organization was first formed, representatives of the multi-site team represented a wide range of SQA experience and capabilities, from novice to expert. This led to some difficulties in coordination. The difficulties usually manifested themselves in two ways. First, less experienced SQA engineers had difficulties in defining the processes and activities that needed to be audited and reviewed over the lifecycle of the project. They were missing the SQA experience to know what needed to be audited and reviewed. This knowledge comes from previous SQA experience on other projects. Despite the lack of formal SQA knowledge, some of these engineers had considerable development talent and valuable application domain experience. The second group consisted of experienced SQA engineers who had little or no domain knowledge of the current application. While they had extensive experience in general SQA, they had trouble initially understanding the processes and techniques that the various teams had been using to build the software. Both situations led to coordination inefficiencies while both sets of individuals tried to correct their respective deficiencies. The tendency was to try to solve the problems first by themselves instead of seeking assistance from the various experts within the SQA team. And finally, the ratio of skills and experience was not evenly distributed between sites.
New SQA team formation
Another barrier to coordination that the SQA team faced was the challenge of starting a new team while also trying to work out the problems of multiple site coordination. Not only were many of the SQA engineers new, but the management team was inexperienced with multi-site management issues. Interestingly, Herbsleb and Grinter [6] stated in their research that the biggest unidentified challenge of assembling new development teams was the new relationships that the development organizations had to forge with the other locations. We found a similar situation in our analysis.
Not realizing there is a need to communicate
Technical folks are notoriously unaware that effective communication is sometimes missing, that communication needs to occur more often, or that the current forms of communication are not as effective as they believe. Sometimes it is hard to realize that email, collaboration tools, teamware, and formal communications sometimes are not enough to facilitate effective teams, processes and organizations. Other times we need to step away from the logical and technical side of development and acknowledge the difficulties with communication from a human perspective. This difficulty is probably a result of so many of us being trained technically and not being comfortable with the human side of software. Software development continues to be a human performance and social activity [7]. Communication plays a large role in the relationships of individuals and teams and ultimately in the success of software projects. After forty years of studying software development organizations, Weinberg has noted and stated that many technical problems are human problems in disguise [8].
Conclusions
We have presented a list of barriers to coordination that we experienced during the process of assembling a multi-site SQA organization. These barriers apply to any discipline whenever coordination is required. Although tools and technology do help to improve productivity within a team, the largest gains for improving coordination are all related to the human aspects of relationships between people, teams and organizations. We also discovered that the most important method in improving coordination between groups separated by distance is to physically bring the parties together as soon as possible. Face-to-face meetings prove to be valuable in promoting group norms, increasing sensitivity among team members, and improving communication. We feel that the benefits of a face-to-face meeting far outweigh any expense incurred by the SQA organization in bringing the team members together from separate or distant locations.
We have seen a number of short-term benefits to the organization and the various projects from the increased emphasis on coordination. First, there appears to be better communication between the various team members. In addition, there is an improved sensitivity to the communication challenges between the two locations.
The longer-term benefits of improved coordination include reduced costs, and a more simplified and uniform approach to performing SQA across the organization. From a managerial perspective, the improved coordination within the team makes it easier to manage and lead. This improvement in productivity and the reduction in SQA costs are important factors today in a competitive business environment and contribute to project and organizational success.
References
[1] T.W. Malone and K. Crowston, The Interdisciplinary Study of Coordination, ACM Computing Surveys, Vol. 26, No. 1, 1994, pp. 87 – 119.
[2] R.E. Kraut and L.A. Streeter, Coordination in Software Development, Communications of the ACM, Vol. 38, No. 3, 1995, pp. 69 – 81.
[3] R.E. Grinter, From Workplace to Development: What Have We Learned So Far and Where Do We Go?, International ACM SIGGROUP Conference on Supporting Group Work, GROUP ’97, 1997. Phoenix, AZ. ACM Press, pp. 231 – 240.
[4] N.B. Harrison and J.O. Coplien, Patterns of Productive Software Organizations, Bell Labs Technical Journal, Summer 1996, pp. 138 – 145.
[5] R.E. Grinter, J.D. Herbsleb, and D.E. Perry, The Geography of Coordination: Dealing with Distance in R&D Work, International ACM SIGGROUP Conference on Supporting Group Work, GROUP ’99, 1999. Phoenix, AZ. ACM Press, pp. 306 – 315.
[6] J.D. Herbsleb and R.E. Grinter, Splitting the Organization and Integrating the Code: Conway’s Law Revisited, 21st International Conference on Software Engineering, ICSE ’99, Los Angeles, CA. ACM Press, pp. 85 -95.
[7] Gerald Weinberg, The Psychology of Computer Programming, Silver Anniversary Edition, Dorset House, New York, NY, 1998.
[8] Gerald Weinberg, Problem Solving Leadership (PSL) Workshop Notes, December 1999.