Six Tips for Making Global Software Development Work

More companies are looking towards globally dispersed software development teams to solve project staffing problems and make critical time-to-market deadlines. This trend is a fundamental change in how software projects are organized and implemented. Using the idea of “concurrent engineering” to deliver projects faster, you break up a project into smaller, less complex pieces and hire staff scattered throughout the globe who work asynchronously around-the-clock. (This is not the same as adding more people to a project to make it later, a la Brooks’s Law.)

Although companies using globally dispersed teams can tap into more skilled (and sometimes less costly) developers throughout the world, these teams typically suffer greater communications problems during software development. These issues come about primarily because of culture, language, and time differences.

Culture affects global teams in many ways, from what is acceptable to say to project team members, to how overtime and vacations are used. For example, it is a typically American attitude that if the project is running a week late, project members will forgo or reschedule their vacations. This is not very common in European countries.

Communicating can be tricky—especially if not everyone on the team speaks the same language. Even if the languages are the same, what we say may not express exactly what we mean. In co-located projects, we have many opportunities for informal communications to clarify what we said in person or e-mail. In global projects, developers have few—if any—face-to-face communications opportunities to clarify what we said.

Communicating across time zones is another challenge. Although working asynchronously can help a team progress faster, not everyone is available at the same time, which may slow down communication and decision-making. And, it’s difficult to find common meeting times, whether for project meetings or formal technical reviews. A project manager or team lead working on such a project must balance organizational skills, communication, and tools to pull the project off. In my experience leading globally dispersed teams, I’ve come to rely on six rules of thumb that have made my teams more productive and effective.

Tip 1: Define the project’s complementary processes: Agree on the meaning of important terms.

Global projects are generally composed of teams who do things somewhat differently. Some differences are cultural, others stem from varied management styles and strategies. What is certain, is that each team’s reaction to the other teams’ processes and terminology will not be the same.

Product development processes don’t have to be the same, but the processes need to be complementary. By complementary, I mean that the outputs of each group’s processes match the expectations of the other group.

Software development terms vary from team to team as much as processes do. I once led a second-line support group for a globally dispersed team, where there was some confusion about what the term “fixed” meant. Our job was to fix the defects that the first line support group could not fix and were time-critical for our customers. We had a recurring problem with two of our European first-line support groups. They kept promising imminent fixes to some very high profile customers, because they thought the defects were fixed. However, the defects were not necessarily fixed. The Boston group was using the notation “Fix” for defects that had been investigated, the cause known, and a fix was in progress. “Verify” was the notation for completed fixes. It never occurred to our European counterparts that “Fix” was not truly fixed!

Other terms I’ve found to be confusing are code freeze and feature freeze. To me, “code freeze” is that time in the project when only show-stopping fixes are allowed. Some teams assume that code freeze means that only very high priority fixes will get checked in. Some teams assume most modules will not change, but for some modules, everything is still up for change.

It’s also important that everyone agree on project milestones, what they are and what they mean. One of the first times I realized how important it was to understand what the milestones meant was when I was a program manager, trying to bring together project components from Boston and Los Angeles. I had developed the schedule with the participation of the technical leads and their teams. We did fine until the first milestone—feature freeze. To the Boston team, feature freeze meant that the low-level design was complete. However, to the Los Angeles team, feature freeze meant that they had a pretty good idea of the high level design. The notion that feature freeze should mean that the module interface designs were complete was foreign to the Los Angeles group.

I got the technical leads together to talk about why we needed freezes, and why and when freezing module interface designs was a good idea. We had all worked together in the same company for at least two years, so we knew each other, even though we had never attempted a cross-country development project. We talked by speakerphone, and somehow managed to keep from yelling at one another. It took us about a week to come to consensus—not everyone liked it, but we could all live with it—about what each milestone meant, and what results we would provide to make those milestones.

I have had a number of successes with projects when I used this “global discuss and publish” technique. Some teams chose to define interim milestones in addition to the milestones defined in the overall project plan. By agreeing to what each project milestone meant, we developed a joint project schedule, which included the major hand-offs from and to each group.

When teams talk about their hand-offs to each other, they can understand what each other means. That brings all the milestones closer to reality. And, when milestones are met, they can be jointly celebrated.

Tip 2: Use CMS and DTS—and make sure everyone uses them in the same way.

Everyone on the project needs to know where the source files are stored, what their state is, and what can be done with them. Here’s a scenario that happened to one of my recent clients.

This organization has development teams in Boston, San Francisco, and Toronto. The project is a collection of fairly independent parts. They all use the same CMS and DTS. But, they were using the tools in different ways. The Boston group used a nightly build and multiple promotion scheme for the sources (first step was to successfully compile and build, second step was to pass the minimum acceptance test). The San Francisco group used a weekly build and single promotion scheme (they built once a week and fixed things until the build passed the minimum acceptance test). The Toronto group used a scheme based on the review state, not the compile or build state.

This project got into trouble when they started the integration phase of their project. Because everyone had different ideas of how to use the CMS, the state of the sources was unclear to the project team. We solved this problem by

  • First, understanding what each group did with their sources, and how that worked within the overall project.
  • Then, deciding how we were going to use the source tree (complementary processes) so that we could actually integrate the whole project.
  • Finally, deciding what the branch and label names meant within each branch and to each group.

You can avoid this problem by agreeing on how to use the CMS and DTS at the start of the project. A number of vendors make integrated CMS and DTS tools, including Rational, Intersolv, and MKS. To find vendors and their tools, look at the FAQs on http://www.iac.honeywell.com/Pub/Tech/CM/CMTools.html for the Configuration Management tools or http://www.iac.honeywell.com/Pub/Tech/CM/PMTools.html for the Problem Management tools. Using an integrated CMS and DTS tool provides a number of benefits for the project team:

  • The defects and their effect on the sources is clearer to the whole team when they have one way to look at the defects and the sources.
  • The whole workflow of the defect finding and source updating is made easier with an integrated tool.

Not every team wants to use the same tools in the same way. I have used a number of techniques to get people to work together on this problem:

  • Logic. I appeal to the team members’ reason and explain how this will be better for them and everyone else on the team.
  • Challenge. I challenge the team members to prove me wrong by using the tools for a specified period of time. If they can find a problem in that time, we agree not to use the tools.
  • Pilot. I request that the team pilot the use of the tools. If they can find problems with how the tools are used, we re-evaluate the tools, or how we use them.
  • Shame and Guilt. When all else fails, I fall back on using either a team member’s shame of holding the whole team back or their guilt about not using the tool to get each team member to at least try what I want them to do.

Using the tools in an agreed-upon way is very helpful to using a complementary product development process even if the processes are not exactly the same.

Tip 3: Formally inspect requirements documents with participants from all development teams.

Getting the requirements right is key to project success—no matter what kind of project you’re leading. But, in a global project, it’s even more critical. Because there may be no opportunity to easily talk to the person with the necessary information, it is critical to write down the requirements, review them, and track them. It is especially useful to keep requirements in a repository, so people can go to one place to continually verify they know what is going on with the requirements. A number of tools supporting this type of requirements tracking are available, including: Rational’s Requisite Pro, QSS’s Doors, GEC Marconi’s RTM. See http://www.incose.org/workgrps/tools/contacts.html for contact information.

Requirements reviews also need to be more formal on global projects. You can’t simply do a casual walk-through with whomever is available or do an informal review over lunch or coffee. The formal reviews should include one representative from each project team. These participants sign-off that the requirements are correct and possible for their team to implement.

In my experience, electronic-only reviews and inspections are not adequate for effective review of requirements documents for several reasons:

  • The people who first read the work product “direct” the discussion. Some people are too shy to bring up their issues electronically.
  • Some people don’t read the product once other people start commenting.
  • It is difficult to get people to agree on a consistent commenting style.
  • The difference in culture and therefore the focus of the discussion cannot be bridged without some audio contact.

The way people use and understand language to write specs and their comments tends to prevent effective e-mail reviews. I strongly recommend all the technical leaders get together with the marketing leaders, and use a Fagan-style inspection, in which everyone reads every line of the requirements spec together. Video and web technology can make reviews and inspections easier. A number of Internet and web-based products allow you to share html and non-html documents among a number of sites. For example, WebLine Communications has a product that allows you to “push” web pages to other people’s machines. Microsoft’s NetMeeting allows participants to share documents during a meeting. Softboard and Teamboard are electronic whiteboards that allow people to create and modify documents electronically. At the time this article was written, there were many potential products. Electronic whiteboards can be particularly useful if you need to discuss design or architecture issues and draw pictures. Normal video communications may be most useful for standard project meetings, rather than meetings focused on carefully reviewing a technical document for defects.

You can use the same Fagan-style inspection process on architecture specs, design specs, and test designs (the strategy and plans for testing the product). The project can gain something quite valuable from inspecting test designs with representatives from each team—each team’s perspective on the product and what is important to test.

Tip 4: Make project plans available to all team members.

Project leaders sometimes forget that not everyone has access to or knows all the intricate pieces of the project schedule. In a global project, this can lead to project failure. Once the project plan is developed, everyone needs access to it. Joint development of the project schedule will make sure that all the hand-offs and milestones are well understood and articulated by everyone. At the very least, I recommend that the major milestones and their commitment dates be pulled out of the schedule, and disseminated to the entire global team by email. It is even better to have the whole schedule and project plan available online in a workgroup tool.

In addition, I recommend that every two weeks, or more often in “crunch mode”, send out an updated list of major schedule milestones to everyone in the company or everyone on the project. This helps everyone see which milestones and dates have been reached and to track the team’s progress on the project. As each group meets its milestones, send out congratulatory email to the specific project team, copied to the other teams. This allows the other teams a chance to stay informed about how the project is doing.

Tip 5: Organize the project teams by product feature, not by organizational function.

I have seen global teams organized by product development function and by product feature. Although it is possible to have developers in one place, writers in another place, and testers in a third place, the people find it harder to do the actual work of product development. I worked with one functionally organized group where the developers and testers were in Massachusetts and the support group was in California. The two groups had dramatically different perceptions of what each other did.

The support group sent detailed bug reports to the developers for fixing in the next release. In addition, some defects needed to be fixed as updates to the current release. But, not all the reported defects were fixed in a timely fashion. The developers did not always understand the priority of the fix requests, and the support group did not always explain the importance of the customer. As a result, the developer and support groups were not able to work smoothly with each other.

In my experience, global projects are more successful if they organize the teams by product feature. One of my clients currently working on a component project has organized the components into three related areas, and has two USA-based teams working on two areas, and one European team working on the third area. These teams are self-contained—they each have product developers, product writers, and product testers. The system test group is part of the one of the USA teams, and that group will have final responsibility for complete system test. At this point, the people understand what they have to do, and the project is progressing on schedule. (For more information on Feature Teams, see “Use Feature Teams” by Jim McCarthy, (originally published in Software Development, now in Dynamics of Software Development).

Tip 6: Use collaborative tools to bring the project together.

Especially in a global project, collaborative workgroup and workflow tools allow people to see all of the project’s documents in one place. Workgroup tools such as Lotus Notes help bridge the communications gap of time and language. Workflow tools such as Lotus Notes assist with lessening cultural differences and the effects of those differences on processes.

For example, during the project with the Boston, California, and Toronto teams, I used forms in Lotus Notes to keep senior management and members of other projects up to date on our project progress and to get help from a centralized support group with our CMS. At one point, senior management wanted to add another project to the shippable product. Because the project managers and senior management had access to all the project plans and release criteria, we could rationally discuss how to add the new project and still meet our ship date.

On this same project, we used workflow forms to create and inspect the master version of the product. We sent the release group (located in California) a workflow form explaining how to create the master. They filled out the next form telling us where the master was and what had gone into it, so we could verify it. We replied to that form with the results of our testing. Using the workflow and workgroup parts of the tool allowed us to save significant time on the project by allowing us to work asynchronously in time, but together in process.

Global projects pose additional challenges to the normal stresses of software development projects. Different cultures, different languages, and different time zones all contribute to the extra stresses. By keeping these six tips in mind, and by applying all the sound project management practices you’ve already learned work in co-located teams, you can keep your global projects on track.

© 1998 Johanna Rothman. This article was originally published in Software Development magazine, August 1998

Like this article? See the other articles. Or, look at my workshops, so you can see how to use advice like this where you work.

Leave a Reply