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.

convert this post to pdf.

Sometimes getting what you want requires a little creativity. While working for a Fortune 50 company several years ago, I desperately wanted to attend a conference in a newly forming discipline. My manager supported my attendance, but had no budget for the conference. Responses from upper management varied from neutral to negative, ranging from “Why do you want to go to that conference?" to "Everyone knows our industry is going through a downturn these days; we need to cut back on all unnecessary travel expenses."

With a little imagination, I eventually found a way to attend the conference without spending my own money. I discovered that there was a separate budget center to fund separate R&D and Marketing activities… and that conferences and workshops fell under that category if the company could gain publicity or recognition from the event. This was the solution to my problem, and I got to attend the conference.

Over the years I’ve had to think of several creative ways to get the backing to attend conferences, seminars, workshops, and training sessions. To help you do the same, we’ll look at tools and strategies for use throughout the approval process: before you attend, making the case to attend, and obtaining the actual approval, as well as alternatives to consider if your request is turned down.

POSITIONING YOURSELF FOR YES

Often your odds of attending a favorite conference depend largely on your organization’s corporate culture, and your position in it. The next time you have an opportunity to change departments, projects, or companies, here are some ways to recognize (or even create) a conference-friendly environment.

First, make sure that your immediate boss supports and promotes continuing education. When you’re interviewing for a new position, ask your potential co-workers about their own training and growth opportunities. 

Choose organizations that have a formal training policy. Look for companies that promote and utilize a company policy in which everyone must take forty to eighty hours of continuing education each year. Many companies have a reimbursement policy for educational classes that are connected to your job functions or career path. I once had a boss who let me take any class or workshop as long as it related even remotely to my job, including esoteric topics such as technical marketing.

Look for jobs that depend on state of the art knowledge, require cross-disciplinary work, or in which ongoing education is a requirement to practice in that discipline. One of my most conference-friendly jobs was in a specialized work group called Advanced Development, where we pushed the technology limits every day. Our job was to survey cutting-edge innovations that we might be able to use in new products, so keeping current was a priority. Most of the information we needed, in fact, was so new that it hadn’t yet appeared in print; the only way to stay on top of it was to attend conferences. In addition to timeliness, breadth of knowledge was crucial. Our work crossed scientific disciplines, requiring us to read and study in diverse fields. Not surprisingly, this group had a large budget for conferences and training, and I was able to attend seminars on everything from object technology and the healthcare sciences to applied mathematics and statistics.

Negotiate your conference attendance as part of your employment contract, consulting contract, or statement of work. Specify the negotiated conference dates before you obtain final approval on a contract or employment agreement.

NINE WAYS TO MAKE YOUR CASE

Even in the most learning-friendly environments, chances are you’ll still have to make a logical and compelling justification for investing time and money in training. Here are some ideas that you can use to make the case to attend.

1) Is the time you’ll be away from your desk an issue? Offer to work a few extra evenings and some weekends in advance in order to make up for time away. This should ease concerns about you being away from the office and affecting the schedule and delivery of your projects.

2) In some cases, when your justification for spending company resources on a conference seems to not be working, consider a backup plan. This time around, offer to split the cost of the conference and travel, or volunteer to use some vacation time in order to attend that favorite conference. If you come back to the office full of new ideas and ways to improve operations, you’ll have a much stronger case next time for full company funding.

3) Show how you’ll share the benefits of your new know-how. Offer to prepare a presentation when you get back for your boss, your team, or department on the things you learned at the conference that could be used in your organization.

4) Just like hotel rates, conference prices aren’t always set in stone. See if you can get a lower conference fee by waiting until just a few days before the actual conference start date (or even the day of the event). Or call the conference chair (not the conference organizers) and explain that you would like to attend but you have limited funds. Make an offer; some conferences have been hit hard by recent travel cutbacks, and may surprise you by giving you a break.

5) If you have your eye on a conference that’s particularly unique, use this exclusivity and uniqueness as a selling point for attending. While many popular conferences are offered each year with pretty much the same content, some events are unique in content and in participation each time they’re offered. If you’re wanting to attend a seminar that may not be offered next year, stressing its now-or-never quality might help you get approval.

6) Submit a paper for presentation. Usually when you get a paper or presentation accepted for a conference you get one complimentary admission to the conference. In addition, you sometimes get complimentary admissions to conference tutorials.

7) Look outside your own department for funding. In some large organizations a special corporate budget exists to pay for promotions and marketing, as in my earlier example, and that may be a cost center you can tap for underwriting. Presentations and attendance at conferences, you can argue, are proven ways to promote the company name and the work that’s being done by key employees. I’ve used this approach successfully when my organization had travel and budget restrictions at the local division level.

If there just doesn’t seem to be any training money in your organization, think outside the box. I once made a deal with the president of a local technical society, for example, and offered to help with fund raising and putting together a regional quality conference. In return, the president agreed to draw from the conference profits to pay my fee to attend a national Software Engineering Process Group (SEPG) meeting. The more creative you get in your funding, the more important it is to get the agreement in writing, if possible.

9) Should all else fail, you might not want to rule out begging as an option. This is an effective strategy if you have a decision maker who is a placater and has trouble saying no to people. The flip side of begging? Threatening to quit. While I’ve never done this directly, it was probably implied based on the seriousness and urgency of my request to attend a particular conference.

CLOSING THE DEAL 

Receiving the actual approval—the signature on the dotted line—is often the most difficult step in the conference-attending process. In some organizations without a clear path for training request approvals, the conference may be long over by the time you get a yes or no!

If you’re concerned this may be the case in your company, schedule a one-on-one meeting with a manager in your department who has budget authority and explain the benefits of attending the conference. Estimate the company’s return on investment, explaining how new ideas or processes could help the organization cut costs and improve productivity. I have personally found that this is an effective approach; few people go to this effort just to attend a conference, so the extra work is often rewarded with a yes.

If you run into a brick wall, or if your immediate manager says no, then consider asking higher up the ladder—the division president, a general manager, or some other key player in your organization. Each organization is different, but just be sure before you appeal your immediate supervisor’s ruling that you understand the risks of tampering with the chain of command.

Is a decision maker wavering, unsure of whether to okay your trip? Then use the personal touch to get approval. Have someone like the conference chair, a conference organizer, or keynote speaker talk to your manager about the benefits of attending. This peer-to-peer approach may be enough to help turn the approval process in your favor.

LIVING WITH NO

If you manage to exhaust these suggestions and have your approval request turned down, you still have options to receive additional training. Here are three alternatives that worked for me in various companies after my initial conference requests were refused by management.

1) Sponsor and organize your own training in house. I once arranged onsite training in the C language for about 30 development people within our organization. I did the planning, organization, handouts, and arranged cost center repayments for all attendees. I brought an experienced C instructor in house for thirteen weekly two-hour sessions. We split the two-hour classes between one hour of personal time and one hour of company time.

2) Volunteer to seek out grant monies for training. In the state of California, the Employment Development Program (EDP) offers grants that can be used in training or retraining the company’s workforce. I once threatened to write an EDP grant for training a development group on CASE tools. I was told the budget did not contain money for either tools or training. The threat of writing the grant proposal was probably enough to embarrass the company into coughing up the money. Our management eventually paid for licensing of the tools and hired some consultants to help with training and implementing the CASE tools.

3) Does your group, department, or organization have a corporate library or subscribe to journals, periodicals, videos or reference works that you can checkout and use? If the organization is missing this valuable resource, ask to start one. An in-house library serves as a great resource for those groups or organizations that don’t want spend a lot on conferences or training. Remember that having in-house resources isn’t helpful unless you’re allowed to utilize them; make sure you can allocate time to take advantage of the library’s contents.

FINAL THOUGHTS

I’ve noticed over the years that only a small number of people actually pursue attending conferences. Even when times are tight, most budgets have enough slack in them to cover a few thousand dollars here and there. Capitalize on this fact by asking if you can attend that important conference or much-needed seminar. The worst thing that can happen is that management says no. And you might be pleasantly surprised; during a four-year period at one company, my requests were never refused. I explained the benefits, I asked the company to make an investment, and I got the conferences I asked for.

Is it worth the extra effort? Every time I’ve asked to attend a conference, I’ve learned something – from the training event, and often from the request process itself. Being a part of these conferences has offered both short- and long-term benefits: learning new concepts that improve the effectiveness of my work, networking with potential colleagues, and improving my knowledge base and technical skills.

And once you’ve negotiated the logistics, approvals and finances of attending a conference, learning can indeed be its own reward. At the end of the conference, in addition to the technical or operational information I’ve learned, I have the added satisfaction of knowing that I’ve invested in myself.

convert this post to pdf.