Global Software Development

---

Global Software Development (GSD), Globally Distributed Software Engineering (GDSE) or Global Software Engineering (GSE) is software development that is carried out in globally distributed settings in various geographical locations.. It originated in the 1970’s in the financial and operation supports areas . Many software projects these days use GSD, for example because companies acquired an oversees company or, as 203 of the US Fortune 500 do, engage in offshore outsourcing . Much of the open-source software development is done in a globally distributed fashion, as contributors come from all over the world. Furthermore, an empirical study conducted at Microsoft indicates that over 50% of employees regularly collaborate with people more than three time zones away. Practicing global software development is not trivial however. Distributing work across multiple sites can be very difficult. Solutions are limited to the resources, expertise and infrastructure present at each site.

Strengths of GSD

In general, co-located development should be preferred whenever possible. However, there are situations in which globally distributed development can be beneficial or even unavoidable, in particular with mergers or acquisitions. When a larger company acquires a smaller company in another country, the acquired staff cannot usually be moved easily. Distributing software development over the world can also bring several benefits that may be crucial to a company’s strategic position . The four most prominent benefits are listed below.

Access to Scarce Talent

The most profound advantage of GSD is the increased access to scarce resources and most importantly skilled labor. Hiring specialists can be difficult to do locally in many areas of software engineering. Employing GSD allows companies to tap into a far larger talent pool than would be possible locally. Companies that base their success on innovation often find that their innovative capabilities come from the most talented engineers. By globally distributing work these companies can now take advantage from the increased innovation and shared best-practices that arise from teams with diverse cultural and organizational backgrounds.

Time to Market

Another important strategic advantage that GSD can bring has to do with speed of development. Working in multiple time-zones allows development to progress even if part of the development teams are sleeping. As a result, bugs can be fixed faster and features can be developed more rapidly to better meet customer demands/expectations. Follow the sun and 24 hour development are examples of two methodologies that take advantage of this time difference in a globally distributed setting.

Distance to the Customer

Practicing GDSE allows a company to be closer to their customers. . Being within driving distance of your customer makes meeting them much easier. Companies generally prefer to buy from suppliers that are close to them. This also makes building a personal relationship much easier and in turn allows a company to better understand the needs of their customers.

Lower Development Cost

Transferring work to another country can achieve a reduction in development cost due to lower cost of labor, though this might not always be the case. As there are also additional costs that come with distributing work globally, it may well be that overall costs increase. Furthermore, focusing too much on cost savings will likely have a negative impact on quality, negating the other benefits GSD can have. See hidden costs for more details.

There are also several benefits that have not received as much attention. For example, the forced separation of teams can lead to better software modularization, better documentation and more clearly defined processes.

Limitations of GSD

Globally software development is not easy to do right. Since the development team is split over multiple locations, several challenges need to be overcome before distributing software engineering becomes a viable option. It is important to be aware of those challenges before deciding whether or not to do GSD.

Hidden Costs

Costs might seem a big reason to consider offshoring, but it is difficult to form a complete picture of all costs that will rise when a part of the team in a remote location is added. Research on the true cost of distributed development reveals several ‘hidden costs’ which make it difficult to accurately estimate the cost of distributed projects Salary can be lower on an hourly basis at an offshore location, but additional costs already raise the average hourly price. Travel costs are introduced when the members of the team have to meet face-to-face. Control costs rise in order to ensure the quality of delivered work from other locations, and an investment is needed in communication infrastructure. Other direct costs include overhead in other parts of the company, like additional HR management, administration, inventory etc. Furthermore, recruitment and training costs are increasing. Indirect costs grow because of inefficiency and ineffectiveness of new team members, miscommunications and distractions by employees of other departments. Most companies that start GSD for reasons of cost alone therefore do not achieve the expected reductions. Savings should therefore not be the sole reason for a company to practice GSD. In one example from the work of Šmite and Solingen, the company researched is estimated to be close to break-even after 5 years of offshore outsourcing. The company, however, does not see the step as a failure, since they did not have costs as their main reason to make the step to offshoring. The decision they made was based on a lack of qualified engineers. The authors do warn that every company is different, so results have only indicative value.

Product Vision

A challenge that normally is tackled by agile workflows and is much harder in global development is the importance of face-to-face communication between team members and customers and within the team . If the development team is separated, most likely only one part of the team has active communication with the client while other team members do not. It is easy for remote employees to lose sight of the product vision if this is not communicated clearly and often. This increases the risk of misunderstandings and ultimately may lead to the wrong features being built.

Loss of Communication Richness

The second centrifugal force is ‘loss of communication richness’. GSD heavily relies on tools like voice/video calls/conferencing, digital scrum boards, and many others. While the current tools available give many opportunities to have a lot of communication, even with video calling you still miss out on things like body language and ambiance. Even current state-of-the-art video-conferencing tools cannot make up for the loss in communication bandwidth. Furthermore, written documentation is inadequate in solving these misunderstandings. In practice, it is heavily recommended to fly in the complete development team to one location for a few days at the start of the project, and get to know the team members best practices.

Loss of ‘Teamness’

Related to the challenge of communication richness is the loss of ‘teamness’. Social bonds within a team are harder to form due to the lack of informal communication and differences in processes and practices Lack in the feeling of being a team results in less trust between team members and therefore less cooperation and less effective teams.

Cultural Differences

Hofstede’s cultural dimensions theory provides 6 dimensions in which cultural differences are explained in a measurable way. These dimensions cover differences in power distance, individualism/ collectivism, uncertainty avoidance, masculinity/ femininity, long-term-/ short-term orientation, and indulgence/ restraint. It is important to keep differences in culture in mind, but also not to generalize.

Coordination Breakdown

Development of complex software is a process that requires small adjustments continuously to stay on track. In a co-located setting these adjustments are usually made efficiently in a face-to-face manner. In a distributed setting these quick face-to-face meetings become hard to do. Problems that require these quick adjustments often get postponed, which slows the development. Furthermore, GSD requires stricter methods of planning and communication which makes managing teams more demanding as it takes more effort to keep all team members informed with the relevant information at all times.

Attrition

Attrition rate (or Employee turnover, or churn rate) is a big challenge in GDSE: When starting with GDSE, a new team is introduced to an existing code base. It takes a long time to get comfortable with a large scale, complex codebase that is often filled with legacy code. When members of the team then switch jobs or roles, the entire learning process starts again, resulting in an increase of inactive time

Best Practices

There are three main tactics, that can be used to reduce the problems with distributed work.

Reducing Intensive Collaboration

Many of the problems with GSD have to do with collaboration over long distances. You can either improve that collaboration as will be discussed below or reduce it. Simple tasks are easier to execute and as a result there will be less help and discussion involved. This also holds true with global work. Simple tasks that are relatively straightforward and have clear requirements, like hosting servers and help desks, can be offshored more easily. Another option to reduce collaboration is for the offshore team to take over full ownership of the product. As no other team will be working on the product, almost no collaboration is needed.

Reduce Cultural Distance

As previously described, cultural differences can be a barrier to using GSE effectively. There are four main best practices that can be used to reduce these problems.

• Bridgehead: If 25% of the workforce is onshore, they can be a bridge between the customer and the offshore business. The onshore employees are usually more experienced and culturally assimilated. They can then smooth over any problems that exist, translate the requirements and provide a face-to-face communication, which reduces miscommunication
• The cultural liaison: If it is not feasible to create a bridgehead, or even if a bridgehead is established, a cultural liason can be established that travels between key stakeholder sites. It’s role is to facilitate the cultural, linguistic, and organizational flow of communication and to bridge cultures, mediate conflicts, and resolve cultural miscommunications.
• Internalization of Foreign Entity: Another way of reducing cultural distance is to create a subsidiary in the country of choice, either by founding one or by acquiring an already existing business.
• Language: As one of the most important parts of collaboration is communication, it is important for the offshore company to know the language of the partner.

Improve Collaboration

Besides reducing the collaboration needed, the existing collaboration can also be improved. We will now discuss some best practices that could enhance collaboration in companies.

High bandwith communication

As mentioned before, communication is very important to be able to have good collaboration. A good practice, therefore is a good practice to us communication methods which have a high bandwidth. This means that a lot of information can be transmitted. This does not only include content, but also body language and non verbal cues. This will reduce the chance for miscommunication, for example sarcasm.

Using Scrum

Scrum is a framework for managing work with an emphasis on software development. The need for frequent communication can be addressed in part by practicing Scrum, as it is defines set moments for a team to meet and share their progress. For example, in the daily stand up meeting the team is able to see what other (offshore) team-members are working on. In the sprint review, planning and retrospective the team can see if where they are working toward is still valid, what they should do next and what can be done better respectively. Furthermore, many agile approaches focus on making critical information highly visible to the entire team via tools such as a Scrum board and burn down charts. Jeff Sutherland, one of the co-creators of Scrum, mentions the following 5 best practices to perform distributed scrum:

• Get everyone in the same room together periodically
• Use video communication for any scrum event
• Do not use asynchronous communication, like email and chat
• Have the team talk on a regular basis on what they are working on and to plan, think and to refine the backlog.
• Lastly, get everyone to use the same tooling.

Recent research in the context of Scrum and GSD shows that while companies do try to use Scrum to support distributed development, there are challenges involved in scaling Scrum in general and adopting processes and practices. Development teams therefore need to customize Scrum carefully to gain benefits from agile development in GSD.

Reduce Temporal Distance

Although asynchronous technologies like email and task boards can boost productivity, there are still large powerful reasons to choose for more synchronous communication methods like meetings, video conferencing and chat. Synchronous communication enables teams to resolve miscommunications, misunderstandings and other small problems quickly, before they become larger problems. When working in different timezones this synchronous communication can become hard, because employees are working in different locations, but can become even harder, as employees might not be working at that time. If the time difference is larger than 9 hours, synchronous communication becomes almost impossible. This is logical, as a normal workday lasts only about 8 hours, so meetings would need to scheduled before or after normal working hours.

References

This article "Global Software Development" is from Wikipedia. The list of its authors can be seen in its historical and/or the page Edithistory:Global Software Development. Articles copied from Draft Namespace on Wikipedia could be seen on the Draft Namespace of Wikipedia and not main one.

---