Global Development and Delivery

Ensure coordination and oversight for all sites

It’s important to “think global” from the start by planning how your organization will support the delivery model you want. Establish how roles and responsibilities will be distributed across the sites, including where the management and decision-making will reside. Identify the tools the teams at each site will use and determine the infrastructure required to enable their use and any integrations with tools at other sites. Visibility into distant teams, especially outsourced teams, can be a particular challenge — how can you be sure of your current actual status, with a holistic view across the entire project and deliverables? How can you reliably measure and compare between components or projects? Compare apples to apples, using consistent measures (as much as possible) for every team. Identify up-front what you will measure to track progress and status, and work with the teams to ensure they can produce the needed metrics. Select discrete units you can measure objectively. For example, avoid measuring artifacts as “50 percent complete”; rather, indicate they are either complete or incomplete. Where possible, collect data directly from your development tools, so you can eliminate human error and subjective bias. (In some cultures, team members may be more reluctant to voice bad news.)

Establish well-defined and consistent workflows

To avoid misunderstandings about how work should be done, define, document, and educate the team on consistent processes that will be followed across all sites. It is probably unrealistic to expect all teams will follow the same process; different tools and technologies, different business needs, and inherited processes and cultures from acquisitions lead to diverse working styles and methodologies. An organization may have teams following waterfall, iterative, and agile methods, depending on their circumstances. Ideally, all teams in a single project would follow the same process, but in a global supply chain scenario, even those teams may be decoupled, contributing components with some level of autonomy. From the perspective of the overall software organization, it becomes most important to define the bounds or parameters that all processes must meet so that consistent touchpoints and deliverables across and between teams will be established. Define the artifacts to be produced, the metrics to be tracked, the measures of success, and the mechanisms for providing oversight and governance. Within a given team, define, document, and educate all members on the processes that will be followed. If exceptions are necessary (e.g., due to access restrictions or tool differences), clearly document where they apply. Clearly define authority and responsibilities: who does what, what is delivered to whom, and what standards are to be met. You may want to use the concept of a “RACI” matrix to determine who is Responsible, Accountable, Consulted, or Informed for each deliverable or process step.

Handoffs between teams or sites often pose problems. Using terms as concrete as possible, processes should clearly specify the deliverables required at each transition and the expected inputs and outputs. For example, help ensure clarity by providing templates for required artifacts and defining control gates with objective criteria for entrance and exit. Clearly specifying handoff deliverables and content can define common ground and ensure both parties get what is needed regardless of steps in between. This can be especially useful when working with outsourcing providers who may follow their own internal processes. 

Consider how to ensure change tracking, traceability, and accountability across the lifecycle, so you can validate if and when a particular change was implemented and what impact it had, or will have, on other tasks or deliverables. 

Where possible, automate your processes and artifact workflows and enforce them in the tools themselves. Tools should make it easier to follow the process rather than to deviate from it, acting as the proverbial “carrot” to encourage compliance, rather than as the “stick.” By reducing manual steps, you both reduce the opportunity for errors and save your team members time and effort. Automation can also help overcome delays due to time zone differences. For example, having an automated build-and-build verification process can enable a team in India to complete and test a defect fix, without waiting for the build team in the United States to come back to work. Using the tools to enact process can also ease tool and process adoption and help ensure process improvement as teams learn how to work more effectively both within their team and across teams.

Manage your inventory and information

Manage your assets and artifacts. Determine who needs access to which artifacts and ensure they have the required access. This includes considerations for network access and availability of the assets over WAN or Web, security permissions to perform the appropriate actions, and the simple ability to locate the artifacts (and the correct version of the artifacts). Provide traceability between related artifacts where possible, so those further “downstream” in the process are able to understand the context of the artifacts they are using. For example, enabling traceability between defects and test cases to requirements and using case models can help those executing the tests understand what results they should be seeing and why, and whether tests adequately cover the desired functionality. Use a versioning mechanism for your artifacts, tracking and tracing changes, and ensuring traceability between the correct versions of different artifacts. Take a snapshot or “baseline” of your assets at defined intervals, such as the end of each iteration or milestone. Each baseline includes a complete set of associated versioned artifacts that can be treated as a unit or single asset, shared between teams, and used as a reference point. Consider an asset management tool as a way to store and manage these aggregations of related and versioned artifacts and make them available for reuse.

Communicate, communicate, communicate

Clear and effective communication could be the most important of the success factors; it is certainly key to building any solid team. Successful projects encourage collaboration and promote team building and social networking. In a collocated team, collaboration can happen informally in the hallway or “at the water cooler,” as well as in face-to-face meetings. With distributed teams, you must work harder to keep everyone in the loop. Consider a communications plan that defines how you’ll keep all team members informed and working toward common, shared goals. Communicate frequently and openly and work to build trust between team members. Take advantage of any and all available collaboration mechanisms. Many of the standard mechanisms are well-known and widely used: e-mail, teleconferences, and various notes or documentation facilities built into development tools. Most of us are also now familiar with chat and instant messaging, Web conferences, and screen sharing. Wikis and team blogs are other mechanisms whose adoption has been spreading recently. Establish a “virtual water cooler” by way of instant messaging, team rooms, or other collaboration mechanisms. Trust can be hard to establish in a distributed team, where interpersonal contact may be limited. Create online profiles of team members in a central location, including pictures and even audio clips, so others can connect faces and other personal information to the name and voice. If budget allows, periodic face-to-face meetings provide an opportunity to establish relationships with the benefit of nonverbal communication (although note that cultural differences can also affect these nonverbal modes of communication). It goes without saying that you should schedule team meetings with consideration for the different time zones of the teams’ locations. In cases where no time will conveniently work for all teams, schedule meetings at alternating times, allowing teams to take turns attending at convenient or inconvenient hours. When scheduling meetings and milestones, you must also consider the holiday schedules that vary across different countries and cultures. Scheduling a major milestone when one region has a month of vacation or a significant political or religious occasion is likely to cause schedule delays and potential team conflict.

Where possible, collaborate in the context of the object or artifact under discussion. Use URL references to share content via e-mail or chat. Annotate or make comments directly on the artifact, and preserve comments with the artifact for future reference. Keep clear records of communications and decisions, so those who were not involved know what was decided and can understand the rationale. For team members in other time zones, this can also save a lot of time in round-trip queries, where an entire workday may elapse before a question on a particular design decision or rationale can be answered by someone on the other side of the globe. 

Textual records can also help to address language barriers. Those team members who are challenged by the spoken language can read (and re-read if necessary) the written documents in order to better understand decisions and context. Similarly, it may be helpful to provide text backups to vocal communications; for example, shared charts, text captioning, and chat “back-channel” in a teleconference. (Note that such backups also help those with hearing difficulties.)

Be aware of the diversity across your organization and the differences in culture and work habits across sites. For example, team members in some cultures may hesitate to question superiors; others may be more confrontational and challenge authority. Understand these differences and ensure all team members understand them as well, so you can adapt and mesh working styles between teams. Some companies offer resources in diversity or cultural training; in other cases, you may need to learn from experience or ask others who have worked with similar teams.

Establish a flexible, adaptable IT infrastructure and architecture

Your IT infrastructure, including your networks and development tools, should enable you to support a variety of distributed organization scenarios. Ensure the tools and platforms you select to provide the capability and flexibility you need to support the topologies you require, whether they are replicated, hub-and-spoke, centralized, or some combination. Specific considerations include: 

• Client access to servers via LAN, WAN, or Web
• Security and the ability to restrict access to artifacts as needed
• Ability to interact and integrate with other tools and platforms in a heterogeneous operating environment
• Support for team collaboration
• Ability to support necessary languages and code pages

Summary

Organizational distribution and global development and delivery are here to stay. Outsourcing and right-sourcing are practices that will continue to grow, evolve, and mature. For many companies, a global team is no longer an option, but an enterprise strategy and a way of doing business.

The benefits of a global software team can be significant, including cost savings, flexibility, access to key skills and experience, and quicker time-to-market. However, there remain many challenges that can adversely affect the ability to realize those benefits, including cultural, communication, and process issues.

Delivering on the critical success factors of:

• Global coordination and oversight
• Well-defined processes and workflow
• Inventory and information management
• Clear and accessible communication
• Flexible and adaptable development infrastructure

The next article in this series will describe the key attributes of software solutions for GDD and expand on how to build the flexible, adaptable infrastructure you need for your teams to be successful.

Notes

1 Bernstein Research, “Future of IT Services,” May 22, 2006. Gartner Group, “Gartner on Outsourcing,” Dec. 14, 2005. Forrester Research, “Future of Outsourcing,” Oct. 24, 2006. 

2 Weier, Mary Hayes, “Tata Earnings Show Offshore Outsourcing Moving Beyond Software Development,” Information Week, Oct. 15, 2007. http://www.informationweek.com/story/showArticle.jhtml?articleID=202402971

3 Gartner Group, “Gartner on Outsourcing,” Dec. 14, 2005.