Adventures in Distributed Agile

The most successful implementations of offshore agile development are those where most of the team is co-located offshore. As long as the developers and testers are co-located and have reasonably continuous access to the Product Owner/domain expert, there is a chance of success. With that in mind there are still many factors which should be considered when contemplating utilizing off-shore development teams in a distributed agile environment.

COMMUNICATION BARRIERS

The time difference between your team and the offshore team is critical to establishing communication patterns. If there is not sufficient overlap between the onshore and offshore working hours, at least one onshore team member may have to expand the overlap by working earlier in the morning or later in the evening. Sometimes all that is required is someone moving their lunch hour 1-2 hrs. Many employees of offshore companies rely on fixed-departure transportation to get to and from work (and travel great distances) and thus are not able to change their working hours. Negotiate the possibilities with the offshore company upfront.

Many countries have statutory holidays which differ vastly from North America or Europe. Further, some of these statutory holidays last for many days at a time rather than just the occasional Monday. Of course some countries also have different work weeks. This can either work in your favour or against you depending on the overlap.

Probably the largest barrier to success on a distributed agile project is the likelihood of language /cultural differences which adversely affect the flow of communication. If you intend to use Scrum methods (daily stand-ups, sprint planning sessions etc) then it is important that you have confidence in the speaking/listening skills of both teams. Working with offshore teams that emphasize ESL for their employees is a great advantage.

Video conferencing greatly enhances the communication experience for teams. Being able to see faces and body language helps with the interpretation process that goes along with listening to team mates who do not speak your native tongue fluently. Obviously the quality of the video conferencing makes a difference and to a large extent it is reliant on the network bandwidth on both ends. Don't forget to investigate network reliability and bandwidth in the country/city of the offshore company.

However good the verbal communication is, understand that you will be relying more on Email/IM than you would otherwise like to on a standard agile project. The good news is that many employees of offshore companies have stronger written than verbal communication skills. Also, because of the prevalence of Instant Messaging outside of the workplace, having the team connected this way means that both parties can take advantage of asking quick questions over IM on either parties' off-work hours. Being able to do this can save many hours for the project as there are fewer '15 hr' delays in having questions answered.

Nothing can replace the value of face-to-face communication. Given that the offshore team has a reasonable level of verbal communication skills, it will still be necessary to work in-situ with the team with some frequency. This will mean at least traveling to the offshore team's campus several times during the project. Certainly early instances of release planning and iteration planning will benefit from having all parties co-located. Further, having one or more members of the offshore team travel onshore periodically creates stronger relationships which are paramount to good communication when the team is separated.

While I routinely work with distributed teams where the Product Owner is geographically dispersed from the rest of the team, the domain knowledge of the team is highly critical to the project success. Some offshore teams specialize in particular domain knowledge while others' are open to developing that knowledge in-house. In either case, you need to be aware that your Product Owner's travel time and time dedicated to answering questions in a full and timely manner is inversely proportional to the domain knowledge of the off-shore team. Ideally, offshore teams should have direct co-located access to their own domain expert.

AGILE MECHANICS

Practicing iterative/incremental development in a distributed environment requires modifications to some of the basic agile techniques. Scrums, demonstrations, retrospectives, and planning sessions usually have to be altered to fit the situation.

In situations where the Product Owner is geographically separated from the rest of the team, but the time-zone overlap is sufficient, I've been able to hold daily scrums by speaker phone in front of a scrum wall. The speaker phone in conjunction with a a webcam directed at the Scrum wall is sufficient for the Product Owner to follow and indeed participate in the Scrum. In situations where the time-zone overlap is insufficient, the Product Owner has had to call in to the offshore Scrum on off hours and view a virtual Scrum board (e.g. Rally). Both scenarios have proven successful.

In fully co-located projects, I like to perform Demos and Retrospectives on the same day as iteration planning. Those activities generally take up most of a day. As one has to factor in time zone differences in distributed agile projects, it becomes clear that these activities need to be split up over multiple days. The demo is best done 'live' but certainly the iteration demo should not be the first time the offshore team receives feedback on functionality developed in the iteration. Similarly the retrospective should be a chance to review feedback on the iteration already collected in the closing day or two of the iteration. This way both the demo and the retrospective can be completed in under 2 hrs. If the team can then be made aware of the subsequent priorities, they can work on the iteration planning in the onshore off-hours and the following day the team can reconvene for 2 hrs to review the iteration plan, review questions and answers for the Product Owner, and re-jig the plan if necessary. During both of these sessions, Video Conferencing is invaluable. Often the audio quality of a VC unit is superior to that of standard telephone audio due to the bandwidth dedicated to the VC unit.

In many cases, distributed agile teams cannot effectively use a standard Scrum wall covered in index cards. A virtual scrum board (e.g. Rally, VersionOne, Team Foundation System) can prove to be almost as engaging for the distributed team. Using a virtual scrum board, goes against many of the agile principles (mainly the fact that physical artifacts like the wall and the cards foster face-to-face discussion) but it is a necessary sacrifice once one embarks on distributed agile development.

In the end the most important aspect of any model for software development revolves around the ability to make appropriate business decisions based on the most current information at hand. Companies should always be asking themselves 'Why do we want to offshore our development?' Clearly cost reduction is the chief reason, but it is a common mistake to grossly underestimate the real cost of implementing successful distributed offshore development. There needs to be budget for a moderate amount of travel, virtual backlog/scrum wall tools and ideally video conferencing. The good news is that once you have made the investment in the teams, tools and techniques the cost of delivering projects declines.