Internationally Agile
Date: Mar 15, 2002
Two of the hottest recent trends in the software development community are agile development and internationally distributed teams. Agile methods are a response to the drastic degree of change in the modern business and IT environments. These highly dynamic environments demand software development teams that can respond to change and continuously deliver business value. International distribution of development teams (called offshore development) is largely a response to market forces demanding lower rates for software development. Many organizations that develop software have recognized the wealth of skill and talent available at much lower rates in places such as India or China and are anxious to source work from these development centers.
Are these two trends compatible with one another, or are organizations going to be faced with a choice between "going agile" and "going offshore"?
The Challenges of Offshore Development
Much has been written about the pitfalls of offshore software development. These are some of the most significant challenges to overcome:
Decreased communication bandwidth. Due to time zone differences between western business centers and many of the major offshore development sites in India and China, there are very few hours in the day when project participants are in both office locations at the same time. This factor, as well as the current cost and quality of telecommunications, serves to significantly decrease the volume of communication between offshore and onshore teams.
Decreased visibility into project status. It's often difficult for project managers and business sponsors to get an accurate sense of project progress and status. Many of them have been unpleasantly surprised at late stages of a project to find that their sense of "percentage complete" was radically incorrect. Measuring project progress is a problem when the project team is collocated and onshore, and is only made worse when the project is on the other side of the world.
Configuration management. "Bringing it all together" for implementation in the production environment is one of the most difficult parts of any software project. Many teams that have built components offshore have been beset by problems when the time came to integrate the offshore and onshore pieces into a working system.
Disconnection on project estimation. Anyone who has been involved in a software project knows that customers, managers, and developers all estimate projects differently, each using their own "fudge factor" based on what the other groups tell them. In an offshore situation, where it is entirely likely that the development team will never meet the project manager or customers, the standard deviation of traditional project estimates can vary wildly. Additionally, it can be very difficult to assess the accuracy or reasonability of estimates as the project progresses.
All of these obstacles are significant to overcome, and different organizations have met with varying success using a variety of different methods to address them. However, since agile methods are relatively new, there has been very little investigation into how they may exacerbate or remedy these challenges—until now. ThoughtWorks opened an office in Bangalore, India last year. Since we have had success using agile methods in the U.S. and Europe with non-distributed teams, it was only natural for us to try to figure out how to extend agile development offshore. What follows is what we have learned so far.
How Agile Concepts Make Offshore Harder
At first glance, it may seem as though agile methods, with their reliance on face-to-face communication and emphasis on collaboration, would be nearly impossible to implement with an onshore/offshore development team. Indeed, at the extreme end of the spectrum, where the ideal state is described as customers sitting next to developers, international distribution would be practically impossible. In practice, however, very few teams attempt to achieve that "pure" form of customer/developer collaboration. Instead, many work on a daily basis with some type of proxy customers—often referred to as business analysts or software analysts who interface with the customer when questions arise that they can't answer.
But just because very few people take agile concepts to the extreme, that doesn't mean that distributing your team doesn't interfere with the critical collaborative nature of agile teams. It absolutely does. For example, it's probably unlikely that you'll be able to find a business customer willing to join the offshore team to serve as onsite customer. Even if you were able to arrange this, the person would be extracted from his or her job to go and play the role of customer for a while and would to a certain extent lose touch with the business. After some time, your customer wouldn't be able to identify changing requirements as quickly as a customer who remained on-site doing his or her job in addition to participating on the development project.
How Agile Concepts Make Offshore Easier
So far the picture looks pretty bleak—offshore is wrought with challenges and parts of agile development appear to make offshore even harder to manage. Fortunately, some aspects of agile development directly address and may even eliminate some of the problems posed by offshore.
If practiced with discipline, continuous integration—the process by which developers integrate their code and build the entire system whenever they have made changes—should reduce or even eliminate configuration-management issues. Our teams working in India check code into the same repositories as our U.S. teams. Check-in is preceded and followed by build verification tests (unit tests) as well as automated functionality testing. When a test fails, a build fails, and it's up to the developer who broke the build to fix it—no matter where in the world he or she sits. The value of continuous integration is that it solves small integration headaches immediately instead of trying to solve huge ones at the end of the project. Configuration management of offshore development becomes almost a non-issue.
Most agile methods emphasize the importance of having the people who will perform the work estimate the work. Ideally, agile project plans are built by rolling up the aggregate estimates on a set of features—where the development team has provided the estimates. Even under less than ideal conditions, the project plan for an agile project should at the very least be strongly influenced by the opinions of the development team. A project run by an autocratic project manager who estimates for his or her team is not an agile project. If the project team stays true to the values surrounding project and task estimation, they will certainly reduce the risk of drastic disconnects between customers, project managers, and the development team on projects with an offshore component.
Iterative development with frequent delivery to the customer is a core practice in agile software development, and one that directly addresses one of the major challenges of offshore development—decreased visibility into project status. Frequent deliveries allow project managers, customers, and users to measure project progress by the amount of working software they have received. During a typical "documentation review" on a project, a group of users sitting in a room can be overwhelmed by an avalanche of documentation that doesn't necessarily represent much progress toward delivering a working system. Give that same group of users access to a machine where they can test your last months' worth of effort, and you'd better believe that the project manager, customer management, and everyone else in the company will know at a very great level of detail how much was really accomplished in that month!
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.
Is it Worth the Effort?
Clearly, a number of challenges are introduced by offshore development, and some of them are likely to be made worse by using an agile approach. Some of the techniques suggested for mitigating the problems caused by agile (such as resource rotation) actually reduce the benefits of offshore sourcing. Even if you allow that agile teams are able to produce software more rapidly, there is some question as to whether the inevitable delays caused by reduced communication bandwidth counterbalance the speed of agile teams. This begs the question: Is it feasible to apply agile methods to offshore development?
The early results of our efforts in Bangalore have been very promising. We're using an agile approach for two large projects co-sourced between India and the U.S. Both of these projects were originally based entirely onshore and used agile methods in that environment. Several experienced project team members have spent time in India and the knowledge transfer is proceeding very rapidly. We have successfully deployed several iterations of remote development with software analysts (our term for proxy customers) located in the U.S. and developers in India. Based on these results, we plan to continue growing the India portion of both of these teams and to continue using an agile approach.
Two factors that certainly enable us to use an agile approach for offshore development are that we've been using agile methods at ThoughtWorks for several years and that these two projects are quite large (greater than 50 team members each). Learning agile development in an internationally distributed environment would certainly pose additional challenges and risks. Smaller projects might not be able to recover the expenses associated with rotating resources through cost savings on offshore development and might have to figure out different ways of collaborating and communicating.
Though on the surface the case against offshore agile development seems strong, our experiences using it on two projects co-sourced in India and the U.S. are beginning to convince us that despite these hurdles, the benefits of agile development—chiefly that it responds well to change and delivers high business value more rapidly than other approaches—make offshore agile very doable and very worthwhile.