- The Challenges of Offshore Development
- How Agile Concepts Make Offshore Harder
- How Agile Concepts Make Offshore Easier
- How to Succeed at Offshore Agile Development
- Is it Worth the Effort?
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
How to Succeed at Offshore Agile Development
We seem to have a situation in which agile methods mitigate some challenges of offshore development and exacerbate others. We need to find a way to address those characteristics about agile development that make offshore development more difficult.
Documentation and "Handoff Points"
The distinguishing characteristic of agile development that poses the largest challenge for distributed teams is the nature of "project knowledge." Things such as detailed system requirements, design specifications, and system structure and behavior at any point in time are stored almost solely in the minds of the project's team members. If the system under development is being defined to a great extent as development progresses (thereby leveraging the power of agile methods), any documentation is likely to be out of date or irrelevant. This makes the "handoff points" of the development process very difficult. (Some typical handoff points include the iteration kickoff meeting, delivery to the customer, and transition of system technical support.)
The solution to the challenge of the handoff points is not to weight down agile development with reams of documentation, but rather to document appropriately when necessary. Document the features that are queued up for the upcoming iteration—to a level of detail that will enable your development team to understand the features enough to break them into tasks, estimate them, and get started. Prepare documentation to accompany delivery to your client allowing the client to understand what has been completed (and what was expected but hasn't yet been completed). When the system is mature enough to transition technical support to another group, document as much as the new group requires to be successful.
There are two keys to successful documentation on agile projects. The first is finding the point of "just enough" documentation. This is difficult to determine and will vary by project. Fortunately, the iterative nature of agile development allows you to experiment until you get it right. The second key to successful agile documentation is to not get attached to it or have unrealistic hopes of keeping it updated. Documentation must be created to serve a specific purpose, and after it has served that purpose you'll all probably have more important things to do than keep updating the documents. It may seem counterintuitive, but it's often better to produce fresh documentation the next time some is clearly required. A side benefit of starting over each time you need to document part of your project is that it's great incentive to keep your documentation efficient!
Proxy Customers
Assuming that your offshore team is unable to locate a business customer willing to play the role of onsite customer, you'll have to establish some type of proxy customer. The best proxy customers are not necessarily those who are experienced with the domain. Often a good proxy is someone with a combination of interests and abilities in technical and business spheres. He or she must be able to interact and communicate equally well with the technical and business project members. On projects large enough to support a team of proxy customers/analysts, it may be useful to have a blend of onshore/offshore resources playing this role and to institute some kind of "analyst exchange program." Allowing both teams to live in one another's worlds periodically will provide opportunities for the cross-functional collaboration that is the lifeblood of an agile development team.
Getting Questions Answered - the First Time
One final issue that troubles offshore teams is the response time required on posing questions to people who operate in radically different time zones. If a question requires more than one back-and-forth, there can be a lag of three days before an answer arrives, which can really put the brakes on the velocity of your team. This can be mitigated in part by adjusting work schedules to ensure at least a few hours of overlap at least a few days per week, during which time-critical issues can be worked through in real time.
Another concept that may help is to use message boards or a Wiki instead of email. The team in India posts questions and issues to a common place during their workday. Project team members in the U.S. or Europe address those questions during their workday. If the whole team commits to actively working to keep this "message center" alive, it significantly improves intercontinental communication between teams.