Assessing Agility and Distributed Projects
- Understanding Distributed Development
- Understanding Agility
- Agile Principles Influencing Globally Distributed Projects
- Summary
Read Agile Software Development with Distributed Teams: Staying Agile in a Global World and more than 24,000 other books and videos on Safari Books Online. Start a free trial today.
This chapter is from the book
This chapter is from the book
This chapter is from the book
- All things are connected. . . .
- —Ted Perry, “Speech of Chief Seattle”
Understanding Distributed Development
My neighborhood grocery store currently displays an advertisement that notes,
Computer specialists can be found in India; a grocery specialist is just around the corner.
One message to be taken from this ad is that people may need to go far afield to find experts to build or support technology, but they easily can find everything they want in the way of non-technological expertise locally. I don’t want to argue for or against the cultural bias of this supposition (there undoubtedly are myriad grocery specialists in India, and I know for certain that there are IT specialists by the thousands in Germany), but I do want to note the implied difference in difficulty between seeking experts locally versus abroad. That’s not to imply that the difficulty in looking for talented people in more than one place argues against globalization, merely that global project success involves more than just hiring top performers from around the world. Of course, there are those cynics who say that going global just means that the project will fail cheaper, so if cheap labor is the main goal, then just looking for any kind of cheap help will be enough.
As when shopping for groceries, software customers require at a minimum a local contact from whom to receive the actual product. Globalization does not change this. Although global software development may encompass multiple locations, distributed and dispersed teams, numerous companies, and off-site customers, a “local” coordinator only becomes more important as project scope, distance, and dispersion increase. Simulating proximity is one key to the success of distributed projects, as will be seen in the following sections.
Working With Several Development Sites
As indicated previously, a typical setting in a distributed software-development effort involves multiple development sites. Project experts should not all be physically clustered at one site, but instead can communicate their knowledge virtually, across even several countries. In this way, each expert is the local link to the dispersed project effort.
Obvious difficulties accompany geographical distribution of project experts. Experts must collaborate despite being located at different sites, but different cultures, time zones, languages, distance, and so on, make collaboration difficult. The goal is for experts to communicate with each other, then translate their specific duties to the local audience.
Distributed and Dispersed Teams
At the core of distributed development are teams at multiple sites. A distributed project may be staffed by one or both of the following kinds of teams:
- Distributed teams might be made up of one group of people located in, say, Bangalore, India, and another group in the United States. This work unit is distributed between two sites, and the project is made up of two teams situated at different sites. Staff members may work on different aspects of a project, but they form a single work unit (like an offensive and defensive squad on the same sports team).
A dispersed team is one unit that is made up of people working at numerous locations. One team member may be located in India, another one in Northern Ireland, a third in the United States, and a fourth in Russia, with all four working as one development team.
Distributed and dispersed teams . . .
Most often, large global software-development projects include a mix of distributed teams as well as dispersed teams. Some groups within such a project may be collocated while others communicate from outposts. Keep in mind that a dispersed team requires a high coordination effort, even if the team is small, in order to ensure effective communication among all team members. Commit to building team identity early on in order to ensure that all members work toward the same goal.
Large Projects
Developing a project globally usually increases its size. As explored in Agile Software Development in the Large, factors that determine a project’s size include scope, time, budget, people, and risk. For example, factors other than budget certainly contribute to a project’s complexity and stature. The relationship between such factors as people and time also affect the size and nature of projects—few distributed projects are scheduled to last only three months, as it is just not worth the effort to set up a heavily dispersed environment with every team member in a different part of the world. Large projects, whether distributed or not, always garner their own risks. One risk is attendant with the coordination of diverse people and teams. Another is ensuring that a large project remains flexible and efficient, despite the overhead required, for example, to ensure that all project members have the same goals in mind.
Coordinating Companies
Often, the expertise of more than one company can provide better value for software customers than can be provided by a single entity. Some companies deem appropriate the strategy either of buying a company in order to work with teams at different sites or of founding a subsidiary at a different location, thereby ensuring an enduring cooperation and committing long-term to global development. Other companies regard distributed development as a chance to focus on their own core competency, and they prefer, therefore, to outsource peripheral tasks to other companies. Others use distributed development as an opportunity to better recruit talent.
No matter the group’s formal organization, the effort to bring together different companies for a project requires a considerable amount of work to establish cordial, and essentially trusting, relationships between parties. A lack of mutual respect may cause difficulty between different subsidiaries, but it spells disaster when between different companies.
The kind of relationship coordinating companies seek can be defined in a contract, which clarifies in detail what two or more parties expect and how they will resolve conflict. By spelling out penalties, contracts provide a formal means to protect involved parties. Although a contract may serve as a means to establish a successful and trusting relationship, it does not actually create and preserve a trustworthy relationship that enables successful cooperation. Establishing a complete and successful relationship requires more than just words in a contract. It requires trust and partnership.
The concept of lean development, which is the root of agile development, favors partnerships.1 Carsten Jakobsen, a project manager at the Danish firm Systematic Software Engineering, notes the use and role of contracts in building trusting relationships:
- “Toyota has proven that treating sub-contractors as partners instead of continuously seeking [whoever offers] the lowest possible price is more profitable in the long term. . . . Even though you have a contract between different parts of the project, you want the complete project to collaborate toward the same vision.”2
Different Sites
Distributed projects can encompass any of the following intra- and inter-corporate relationships, each of which engenders unique challenges to the goal of ensuring close collaboration and, thus, success.
- Offshore outsourcing occurs when the domestic company outsources all or part of its software development to vendors offshore. Thus, the onshore and offshore companies are different companies, a situation that requires close attention to legal negotiation.3
- Offshore insourcing occurs when a company founds a subsidiary or buys a separate company located offshore. In such a case, only one company is involved but is itself distributed across the globe. Large multinational organizations, such as General Electric, Schlumberger, IBM, or SAP, typically pursue this strategy, primarily to gain market presence offshore.
- Onshore outsourcing occurs when one company carries out part of another company’s development project. Both companies operate on the same shore, frequently in the same country or at least close by. Onshore outsourcing is not always considered to be global unless it shares many of the challenges of global development, such as cultural differences, which may interrupt communication, especially when due to discrepancies between corporate cultures. Perhaps the most significant challenge occurs when programmers, testers, database administrators, and other team members are not collocated.4
- Nearshoring can be combined with both insourcing as well as outsourcing. The major distinction is that while both companies are located on the same shore, they are not situated in the same country. For example, a California-based firm outsourcing development activities to Mexico.
Customers and Distance
Communication between customers and developers is as important—and as challenging—as it is among developers. Customers must communicate requirements to developers, who, in turn, must fully understand the customers’ needs in order to translate them into product functionality. Doing so is difficult even when customers and developers are collocated. It grows more difficult when physical distance and cultural and linguistic differences exist.
When requirements are unclear, developers can gain a better understanding by means of short feedback loops to clarify requirements verbally or to present an early version of the desired product or system. How successful the feedback loops are can depend on the physical distance between customers and developers—particularly when software must work on various platforms and systems, or display in different languages.5
Effective, accurate communication among customers and developers plays a major role in a project’s success not only during development but also during planning, taking into account different legal requirements and diverse cultural backgrounds.
Centrally Coordinated or Globally Integrated
In his book Global Software Teams, Erran Carmel of American University identifies three evolutionary stages of the global development process. As Carmel sees it, at Stage I, the entire development process takes place at one location, and thus is not a global effort. At Stage II, development takes place at multiple sites, all of which are centrally coordinated and controlled by one headquarters. At Stage III, remote sites are self-directed, with coordination between sites operating like a network. Carmel posits that most software development companies function at Stage II, and only a few companies ever prepare to move to Stage III, in which “various remote development sites assume greater responsibility for a range of tasks and coordinate some activities among themselves without funneling all decisions through headquarters.”6
Many development efforts even run aground due to company policies that prevent them from advancing to Stage III. These efforts are limited to always assembling the higher management of a product at one location, typically at corporate headquarters.
Global integration . . .
Overcoming the Distance
As now should be evident, distributed development involves much more than just finding (low-cost) experts somewhere. Rather, in order to successfully implement distributed development, the factors discussed above—multiple work sites, large projects, different companies drawn together, and distant customers—must all be addressed. The key to successful distributed development is establishing proximity despite all forms of distance.