Transitioning to Agile in Onshore-Offshore Distributed Teams

Whether you are concerned that your job is going to be shipped to another country or feeling safe that the outsourcing craze is calming down, the reality remains that we live in a global economy and more and more companies are beginning to explore ways to creating software in distributed and multicultural environments. The Web and the open source movement have demonstrated that it is not only possible to create quality software in a highly distributed and decentralized manner, but also that it "makes business sense" to do so. This article presents a pragmatic framework for introducing Agile practices and tools to onshore-offshore distributed teams (OODT).

As someone who has been in multiple roles from development to management on both sides of the shore, I've had the chance to work in several outsourcing models. My experience was in many ways similar to others' success stories[iv] and horror stories.[v] I've observed that finding a working model is far from trivial.[vi]
 Typical challenges can range from communication issues, IP infringement risks, and lack of adequate top level management skills to quality control, capacity management control and social and political factors. Then, there are the not-so-typical challenges like the incompatibility of the onshore-offshore company cultures and the way software is created. The last factor plays a crucial role in the success of the model, because it incorporates vital elements such as:

• People and roles
• Offshoring models
• Infrastructure
• Agile practices
• Agile tools

This article focuses on these five aspects of software development which can help in transitioning the OODT to Agile. As with every transition, the important thing is to start small with a pilot project and learn as you go.

People and Roles
Every project starts with people. Alan Davis gives a simple, but precise definition of the importance of good people: "People are the key to success." [vii] In the initial phases of the Agile transition, companies should consider sending experienced onshore {sidebar id=1} resources overseas to help with important activities such as writing the automated build scripts (ABS) and setting up a continuous integration (CI) server. The role of a trainer coach could be to introduce practices such as team room and pair programming and show how each one is executed.

Onshore-Offshore Distributed Team Models
One of the biggest challenges of offshore development is finding a reliable partner. Unless the US company opens an offshore branch, it should do due diligence to select a competent and trustworthy partner. If the offshore company or its employees have prior US work history and some Agile development experience, this will increase the chances of success for the OODT Agile initiative. Flexibility is also an important attribute and despite flashy marketing materials, not all of the offshore companies are flexible.
Now, let's take a look at a few variations of the offshoring model. There are probably as many models as the number of practitioners, however for simplification I will lump them in three general categories.

Model 1: Partial Offshoring
This is the first model of offshoring in which the implementation team (programmers, testers, documentation and support services) is shipped overseas. In this model, the design team is located onshore and it sends the requirements overseas. The offshore team responds with back fully-tested and working code. The onshore team then performs the user acceptance tests and validates the requirements and the defects.

Model 2: Complete Offshoring
The second model tries to provide as much co-location as possible by shipping the entire production team, including design and implementation, overseas. The only people left onshore are the customers. In this model, the customers send lists of features and the offshore team responds with fully tested working code. This scenario is arguably the most cost-effective among all.

Model 3: Mirrored Offshore Team
The third and most effective model for companies transitioning to Agile is the mirrored-design model. This is a hybrid between Model 1 and Model 2 and it is more effective for Agile transitioning because it replicates the design teams (architects, project managers, business analysts, and mentor/coaches) onshore and offshore. It takes advantage of the collaboration taking place onshore between the co-located customer and the design team. This collaboration is complemented with a low-cost peer-to-peer communication among the onshore and the offshore design teams. The onshore co-location improves the quality of the requirements and the architectural design while the mirrored offshore design team helps in delivering higher quality code by supervising the development and testing teams.

This model can be less cost-effective in the beginning, however as time progresses the initial investment pays itself out by savings from less defects and shorter development cycle. In addition, the mirrored teams lay the groundwork for a smooth transition by gradually shifting responsibilities to the offshore team.

Infrastructure
After choosing the key people and deciding on a team model, the next step is to build the infrastructure. Since communication is key in any of the OODT models, start by establishing the best communication infrastructure you can afford. Build a secure and reliable network via VPN, Voice Over IP (VOIP) and email. Create the following servers:

• Code repository–keep the repository close to the offshore team.
• Wiki - use the Wiki as a communication center.
• Instant messaging–IM can be a great tool for quick and effective communication for OODT.
• Integration and testing–create separate testing and integration machines for the offshore and onshore teams.
  Continuous integration–since early feedback is so important use a CI server along with test coverage, code inspection, notification and reporting tools. Place the CI server offshore and in a visible part of the room.

Figure 1 depicts a sample OODT infrastructure. The CI server takes the center stage in an Agile OODT infrastructure. Both teams use it as a means of triggering the build and tracking the status of the code at any given time. The CI server should reside close to the implementation team because it can notify co-located teams visually or by generating a sound. Both onshore and offshore teams have access to all network resources all the time, however code repositories, Wiki servers and other supporting applications are better off if placed close to the teams that use them most.

Figure 1: Sample OODT Infrastructure.

Agile Practices
The third and most important element of a successful OODT Agile transition is the implementation of Agile practices. Practices that have worked for co-located teams have to be tweaked to accommodate for a distributed environment. For example a co-located CI can be managed with a physical token passed among the team members as they build the code. This approach does not scale up for OODT and therefore there needs to be a way for an asynchronous continuous build, based on a background process which polls the repository continuously and triggers a build after it detects a change. That's where tools such as CruiseControl come into the picture.
Let's take a look at some of the more important practices:

Automated Builds
This is perhaps the first and most important practice for any Agile team. An ABS helps developers see the effects of any change immediately and make it possible to deliver working software at the end of each iteration. The need for ABS is even more pronounced in a OODT because multiple people build simultaneously and, in the absence of a common team place, it is paramount that every change is properly integrated into the build. This is a fundamental attribute of a well-designed automated build system since it helps keep the repository coherent and the code base buildable.

Continuous Integration
CI is the practice of periodically executing automated build scripts, preferably in short intervals. CI can be seen as a natural extension of the automated build practice since in most cases it relies on the presence of a set of ABS. A well-designed CI system encapsulates other continuous sub-practices such as compile, database integration, unit testing, deployment, functional testing, notifications, and reporting. All of these are designed to shorten the time between the problem discovery and its solution.

Test-Driven Development (TDD)
One of the biggest challenges of developing software in an OODT environment is communication, primarily during the requirements analysis. TDD can greatly reduce the risk of misunderstanding customer requirements by providing a suite of automated tests designed to probe key assumptions on the requirements. The ability to run tests independently from the people who write them gives the onshore design teams the freedom to test and verify the system anytime they need.

Iterative Incremental Design and Development (I2D2)
I2D2 or evolutionary design is based on the idea of gradually growing the design as the requirements evolve and it is especially important for OODT. The requirements will likely change due to evolving business needs or misunderstandings caused by the distance. It is important for both the mirrored design teams as well as the offshore implementation team to anticipate changes and strive for the smallest design that makes the current requirement possible. The design teams should balance a moderated upfront architecture with evolving incremental change. Many Agile design teams allocate Iteration 0 to work on the architecture, while the support team builds infrastructure and ABS.

Other Agile Practices
The practices outlined above are just a few in the wide range of possibilities for the transitioning OODT. Other important practices and recommendations include:

• Code reviews. These can help reduce the number of defects in the code even for pair programmers.
• Daily stand-up meetings. OODT teams can sometimes drift if left unchecked and a daily meeting in a workable time slice can bring the team back to together.
• Iteration-end demos. These customer demos are designed to validate assumptions and make sure that the teams' goals are aligned with the customer's.

Agile Tools
Once the practices are in place, you need to start looking for the right tools. When it comes to tools, the Agile teams have plenty of choices and the real challenge is selecting the right tools for the job. Figure 2 lists some open-source tools proven to be effective in Agile teams. Depending on the offshoring model and the infrastructure layout, these can be potent weapons in the OODT's arsenal. As always, teams should independently evaluate each tool before moving forward with its adoption.

About the Author
Levent Gurses is a Washington, DC-based software consultant. He is also the co-founder of Jacoozi, a US-based technical consulting and development firm specializing in transitioning companies to Agile by establishing infrastructure, mentoring, and coaching. In his professional life, Levent helps clients develop leaner and meaner software through Agile practices. Most of his free time goes to reading and motorcycle racing.

[i] See "My Job Went to India," Chad Fowler,

[ii] See "Outsourcing Boom Is Over" eWeek, http://www.eweek.com/article2/0,1759,1987497,00.asp?kc=EWRSS04069TX1K0000700

[iii] See "The Success of Open Source," Steven Weber, http://www.amazon.com/Success-Open-Source-Steven-Weber/dp/0674018583

[iv] See "Simple Successful Outsourcing," CIO Magazine

[v] See "Outsourcing Horror Stories," Steve Mezak, http://accelerance.typepad.com/runtime/2006/09/outsourcing_hor.html

[vi] See "Offshore Outsourcing Failure Case Studies," EBS Strategy

[vii] See "201 Principles of Software Development, "Alan M. Davis, 1995. New York: McGraw-Hill. http://www.amazon.com/Principles-Software-Development-Alan-Davis/dp/0070158401