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.
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.
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:
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