Case Studies On Bringing Agility to Offshore Software Development


of the customer when the projects were kept small. Small- and medium-sized projects generally did better meeting cost savings than big projects.

Team Together In One Room and Pair Programming
One of the big challenges working with offshore organizations in India and China is the high attrition rates–often one will find a high fluctuation of employees in the offshore organization. To a knowledge-intensive discipline such as software development, this is a problem. However, many cases benefited from an agile approach to this issue. Having the team gathered in one room and using pair programming, they had the advantage of quick communication and transfer of knowledge between the team members offshore. Due to the high feedback cycles and quick exchange of information in the room, one project manager mentioned that their projects were never delayed, even when developers left in the middle of the project.

Do Requirements In Iterations/Use Short Iterations
As communication is impeded in offshore development, one has to focus on ways to improve communication and thereby the ability to transfer understanding. Many cases found that iterating through the requirements and implementing short iterations helped the offshore developers understand the onshore customer's business needs and logic.

Very rarely would requirements be in place at the start of the project. For plan-driven cases, this would be a serious problem, while those using an agile approach could accommodate the problem. In one case, a European participant believed that his project would have been a catastrophe if a Waterfall Model had been used when specifying the initial requirements. The case found that iterations helped the team understand and explore the requirements. Another European case (using a Russian offshore center) had only 50 percent of the requirements in place when the project started. This team would not have been able to deliver in time if it had required stable requirements before the team could start developing the project.

Another case had learned from its onshore projects that doing requirements in iterations was the only thing that worked, as it gave them a chance to focus on important requirements first and thereby give more value to their customer. This created conflict when its CMMi Level 5 offshore center preferred to have all requirements upfront. Onshore managers found that delivering detailed upfront requirements to this standard would simply be too expensive and would impede the economical benefit of using offshore resources.

A Russian case started out with a plan-driven approach, but experienced that the upfront requirements from the customer were too vague. It had to abandon the Waterfall Model and do the requirements in iterations in order to get hold of the complexity of the project.
The use of short iterations was another way to circumvent bad communication in offshore development. The size of short iteration would vary from one to four weeks. Some cases experienced that the offshore iteration would be a little longer compared to onshore iterations due to the informational overhead. Other cases kept onshore and offshore iterations the same size. One agile case aligned the size of the iteration with the need for feedback: the heavier feedback cycles needed, the shorter the iterations. Some found that if they had longer iterations, they would be disturbed in the development process all the time. By having short iteration of one week developers could work undisturbed for a week, while project managers were collecting new requirements for the weekly planning game.

The iterative framework was also found beneficial for the agile offshore vendors. By using an iterative approach, the customer could pay after each iteration. In this way the customer did not risk as

AgileConnection is a TechWell community.

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