␡
- Understanding Distributed Development
- Understanding Agility
- Agile Principles Influencing Globally Distributed Projects
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
This chapter is from the book
Agile Principles Influencing Globally Distributed Projects
Listed below are twelve principles of the Agile Manifesto, annotated in terms of their impact on distributed development and direct implementation of an agile approach.
- Satisfy the customer through early and continuous delivery of valuable software: Early and continuous delivery is only feasible if all distributed project sites work in concert and take into account customers’ wishes.
- Welcome changing requirements, even late in development: Communicating requirements changes and their implications requires considerable coordination effort across different sites, but it is not more difficult in a global setting than in a local setting if people on the project are accustomed to pulling together toward a common goal.
- Deliver working software frequently: To deliver working software at frequent iterations, all sites must carefully integrate the work they do. The effort required for teams to deliver a smooth build and integration is considerable even when teams are collocated; it is all the more so for a distributed project.
- Business people and developers work together: Regardless of distance between sites, language differences, or cultural disparities, all project members must be fully aware of customer needs, and must make every effort to incorporate customer feedback in the development process.
- Trust motivated individuals: Trust generally is built by proximity—a default obstacle in a distributed setting. The sense of closeness, though, must be fostered so as to bind teammates together despite physical distance.
- Face-to-face conversation: Because direct, face-to-face conversation is one of the best ways for people to communicate their shared requirements and goals, periodically set aside a time, place, and technology to facilitate effective communication.
- Working software is the primary measure of progress: In a distributed setting, making software work over different sites is much more difficult than when everyone is collocated. The major challenge is to ensure the joint effort of the different sites in order not to have several systems but, rather, one coherent, running system in place.
- Promote sustainable development: This principle acknowledges the fact that people working too much overtime tend to burn out, adversely affecting the quality of a system. This is true for both distributed and collocated teams, but there is added difficulty on distributed, global projects that have people working at odd or irregular hours in order to communicate and collaborate. The time and physical effort people spend traveling between different sites also can negate their effort to build relationships, making people on distributed projects more susceptible to burn-out than are folks on collocated teams.
- Continuous attention to technical excellence and good design: Some projects are negligent in establishing quality assurance at all sites. Assuming that continuous attention to quality is every project’s goal, ensure that all sites and all project members work toward attaining it. Additional education may be needed to bring all staff at all sites up to snuff in such areas as testing, refactoring, quality metrics, or other skills.
- Simplicity is essential: In distributed settings, project members sometimes develop a general, one-size-fits-all framework for the system in advance of beginning development work because they believe it will ease the development of business functionality later. However, such a framework generally is disconnected from and irrelevant to the customer’s actual business requirements and thus doesn’t support the domain. Such a framework introduces more complexity and compromises developing business functionality.
- Self-organizing teams: Physical distance between sites can be particularly challenging to self-organizing teams because distance makes it harder for people to know and trust one another.16 A sign of mistrust—a smell—develops if a more command-and-control style of collaboration inhibits the ability of teams to self-organize.17 Trust is essential on globally dispersed or distributed teams, whose members may need to be educated about taking responsibility and self-organizing—especially in regard to concepts that contradict their culture.
- Team reflection and adjustment: Here is a direct connection to the first value pair of the core of the Agile Manifesto, which values individuals and interactions over processes and tools. At first glance, this is not necessarily different in a distributed setting than it is in a collocated setting: The idea is, allow team members to reflect on how they’re progressing to enable them to improve over time. The challenge, however, is to regularly promote reflections across all sites to improve cooperation and incorporation.
Globally distributed projects face the major challenge of how to organize iterations and releases across different sites and still ensure that something functional is delivered at the end of the development cycle. Moreover, the real challenge is not the organization of the work but the integration of the distributed development effort into one working system. Performing integration and build across teams and sites is essential.