While the cost-per-developer of offshore development might make it attractive, the benefits frequently fail to materialize. Solutions delivered by offshore teams are all too often characterized by poor solution fitness and quality problems, leading to late delivery and dissatisfied customers. Agile development practices are proven to provide better solutions, but they require a high degree of communication. Adopting them in an offshore environment presents a unique set of challenges. To do it successfully requires all members of the team have a common understanding of:
How everybody is going to work together.
The business problem they're trying to solve.
The project's status.
Agile adoption is far more successful when there is a shared vision in the team for each of these.
How Do We Work Together?
Even in offshore development, there is some portion of the team that works nearshore. This gives the development team access to the business. Typically the nearshore team consists of project management, business analysts, and senior technical staff, while the offshore team consists largely of developers. As the team is distributed, getting both groups to function as a single team is the first priority.
To do that, the members of the team must first understand how they will work together. Because there is not a single definition of an Agile process, taking an "Agile approach" can mean different things to different people. The practices adopted - requirements gathering, continuous integration, test-driven design, project tracking, and reporting - are performed in different ways by different teams.
Advertisement
Having different ideas about how work is to be done will result in people working at cross purposes. For example, while both nearshore and offshore teams may agree that requirements will be expressed as Agile "stories," they may make different assumptions about what that means. The nearshore team may only to provide single sentences that describe each requirement, expecting to work out the details with the developers as code is produced. The offshore team might expect detailed narratives with each requirement. This inconsistency will create dysfunction.
Before beginning development, the team must agree how Agile practices will be executed. Over the course of the project, it must hold retrospective meetings that specifically focus on practice disconnect. In so doing, the team gets its house in order, and will be consistent in how it solves the business problem.
What Is It We're Trying To Do?
The second priority is to facilitate a common understanding of the business problem at hand. Agile development isn't "order taking" with developers working from voluminous specifications. Instead, it is a process of discovery, with people coming to a greater understanding of a problem by iterating development of a solution. This requires fluid, engaged communication.
The obvious problem in an offshore context is that distance strains communications. Being physically separated means the development team won't be exposed to the "ambient noise" of the business. Working in different time zones introduces latency in how quickly questions can be asked and answered. Facilitating collaboration on the business problem is a top priority. This is done through a combination of practice, tools, and training.
Collaboration requires that everybody speak the same language. In Agile development, it means that people communicate in the language of the business. If developers are to do more than simply work from specifications, they must understand the business problem they're trying to solve. That means an investment in training the team so that developers can communicate in a business context, and not just a technical context.
From a requirements perspective, this often means that the distributed team creates more detailed requirements narratives than are typically used in a co-located team. But reliance on extensive artifact production can create false confidence. For a distributed team to work on a problem collectively requires communication tools that allow knowledge to be captured as it evolves. This is possible with integrated, development-oriented collaboration tools. They facilitate complex communication including rich media and artifact association such as requirements, code, bugs, tasks, documents, and discussions. They allow knowledge to be shared, organized and searched, and made accessible over the duration of the project.
Collaborating with the business is particularly challenging in offshore Agile. The business participates in development on either side of coding, specifically in articulating requirements and by executing the software. The same collaboration platform used by the development team should also be usable by the business. By expressing requirements as independent statements of need and associating discussion threads, presentations, documents, spreadsheets, and other artifacts with them, the business is able to provide context more completely to developers. At the other end, frequent releases of the software to a test environment - possibly automated as a final step of the continuous integration process - gives the business access to the most up-to-date version of the software. This will allow for continuous feedback on the software as it is developed.
Of course, all of the collaboration infrastructure in the world won't overcome a disengaged customer. It's one thing to have a full suite of collaboration tools, the project in a state of continuous build and frequently released for test. It's another for someone to actively participate. That means an active and engaged business partner, regularly reviewing the software and providing feedback to nearshore and offshore members of the team. Strong project sponsorship makes this happen.
Furthermore, for a team to "work a business problem" collectively requires more than just tools and training. Role replication - having people in identical roles in each location - creates consistency and continuity of execution. Having "global pairs" of key roles also institutionalizes team collaboration. For example, for a development team to get questions answered in a timely fashion requires access to business knowledge when it needs it. Having a business analyst in both offshore and nearshore locations makes this possible. Similarly, to track team progress and resolve team obstacles, there should be project management in both locations. The same can be said for senior technical roles. Because personal relationships overcome communications problems more effectively than technology, it is important that each "global pair" be co-located with the other for brief periods.
Finally, there needs to be frequent, focused team communications. Agile development calls for a daily "stand-up" meeting where each team member states what he has worked on, what he is doing next, and anything interfering with his progress. Agile also makes use of retrospective and planning meetings with each iteration (e.g. one to three weeks) and each release (e.g. one to three months). These are highly focused events that communicate priorities and expose risks. By consistently executing them, the team increases its communications "bandwidth" and minimizes "noise."
By doing all of these things, the domain knowledge of the offshore team increases (see Figure 1).
Figure 1: Increasing Domain Knowledge On Offshore Teams
This allows offshore team members to be more effective partners in development. As a result, offshore development teams are considered less "development capacity" and more "empowered teams."
How's It Going?
The third priority is operational transparency. This engenders trust and allows business and technical decisions to be made with confidence. Agile practices uniquely allow for both, creating a high degree of transparency in offshore projects.
Agile practices create operational transparency. In Agile, statements of functionality are each individually developed, built, and tested. That is, for a team to call a requirement "complete" the code must be built into working software and meet acceptance criteria. Working this way allows an offshore team to provide frequent and direct visibility into work done and requirements fulfilled. This also means that project status is less a statement of opinion and more a statement of fact: the future of the project hasn't been mortgaged by deferring the development stages of build and test. As a result, the offshore team can communicate project status in unambiguous terms. Finally, having both granular statements of functionality and an accurate picture of current state make project forecasting more reliable. This means nearshore business sponsors and project managers have current, fact-based assessments of whether the offshore team is on a trajectory to meet its business case.
In addition to operational transparency, Agile practices lend themselves to non-invasive compliance. Unit and integration tests can be automated. They can also be implemented as reporting or gatekeeper events of the build process. Subsequently, a complete set of compliance measures can be applied and made accessible to all members of the team. For example, the nearshore team can define a set of performance or security acceptance criteria. These acceptance criteria can be implemented as tests. These tests can be automated and implemented as part of the build process. As a result, expectations are mutually understood by nearshore and offshore team members, and the offshore team can continuously demonstrate compliance with a complete set of expectations.
Making Better Decisions
While Agile practices can be effective in offshore development, process is not a silver bullet. Development success still comes down to the performance of each individual contributor, especially in a team using Agile practices. While taking on these practices won't guarantee the success of a project, they clearly communicate expectations and expose team capability so that better project decisions can be made. That, in turn, increases the likelihood of project success.
About the Author
Ross Pettit has 15 years' experience as a developer, project manager, and program manager working on enterprise applications. A former COO, Managing Director, and CTO, he also brings extensive experience managing distributed development operations and global consulting companies. His industry background includes investment and retail banking, insurance, manufacturing, distribution, media, utilities, market research and government. He has most recently consulted to global financial services and media companies on Agile transformation programs, with an emphasis on metrics and measurement. He is currently Director Professional Services for SourceForge Enterprise.
Error, missing joomlaboard config file!
Comments (5)
zieved: ...
Im a banking student.I want to find out the journal that related to the offshor banking.
1
February 12, 2008
Brian D: ...
Am averse to the idea that the developer community needs to know more about the business . Knowledge needs to be conveyed in reusable artifacts. The idea that it should be in someone's brain is impractical. Silos in companies have resulted primarily from the outdated concept that developers need to have an extensive knowledge of the business to produce a good solution. Let the developers do what they do best and the business team do what it does best. Iterative development and continuous collaboration help iron out prior misconceptions without the need for either side to gain the other's expertise. This approach fosters a developer community that can be leveraged across various business domains of the organization.
2
April 25, 2007
Matthew J.: ...
I know it is a small point, but there is something missing in the sentence, "The nearshore team may only to provide single sentences that describe each requirement, expecting to work out the details with the developers as code is produced."
Did Ross mean, "The nearshore team may only want to provide single sentences that describe each requirement, expecting to work out the details with the developers as code is produced"?
3
March 08, 2007
Mohan: ...
Interesting topic and analysis. I too have been musing on some of the issues and challenges of Agile Offshoring on my blog http://infosysblogs.com/managing-offshore-it
4
February 23, 2007
OS: ...
Hi Ross Great presentation.!All points highlighted are really appropriate. As your article highilghts ,agile more calls for transformation in practicing effective people practices along the software engineering activities.
Articles 
