Transitioning to Agile in Onshore-Offshore Distributed Teams


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.

Automated Builds
Pair Programming
Code Reviews
Continuous Integration
Project Management
Figure 2 : Sample of Open Source Agile Tools
OODT teams considering Agile development exercise special care during the transition period. A successful transition starts by identifying the right

About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.