Due to the ever-rising demand for seasoned software developers in the nineties, offshore software development became a compelling alternative to in-house development for many organizations. Despite the cultural, language and time differences and the geographical distance involved, more and more projects were executed with offshore development and testing, benefiting from lower rates of cost and the high availability of people, and where necessary, the ability to have teams working around the clock.
Early offshore
Particularly during the early years of offshore software development, the majority of projects were executed using rather traditional, Waterfall-style approaches. Projects were characterized as fixed-price and fixed-date. The requirements and the design were compiled onshore, after which coding and testing was done in another part of the world, be it Eastern Europe, India or South America.
The Waterfall model typically involves executing each of the activities in software development consecutively, and only once – requirements, analysis, design, code, test and deployment – to deliver a product based on the completion of each of these project milestones. Interestingly, this model has led to high failure rates in projects, even without offshoring some of the activities. At each milestone knowledge is lost and testing is executed very late – only when development is done – with exponentially rising costs of repairing bugs. Moreover, achieving completeness in requirements early on in a project is difficult and changes to requirements are costly.
Oddly enough, even with these anomalies, and even with failing local projects, many organizations still ventured into offshore software development applying the Waterfall model. Not surprisingly, many of these projects failed to deliver on time or on budget and did not deliver the required functionality. Despite the hoped-for benefits of lower costs and high availability of skilled people, offshore projects add another level of complexity due to more complex control and coordination, and because of language, cultural and time zone discrepancies.
Is Agile more suited for offshore than Waterfall?
So with Agile approaches, such as Scrum and Kanban, reaching the peaks of their popularity, an interesting question is: can Agile approaches and techniques overcome some of the shortcomings of offshore Waterfall development?
In short, Agile approaches are characterized by working in short iterations, where during each iteration a number of continuously re-prioritized work items are fully realized by a multi-disciplinary team, usually applying a similar life cycle per work item – requirements, analysis, design, code, test and deployment – as Waterfall uses over a whole project.
At the start of an Agile project the requirements are only identified, and not compiled into full detail. This list of requirements is known as the backlog, and is not designed to be complete. Rather, items from the backlog are elaborated on during iterations (also known as sprints). So all the real work is done during iterations. As a consequence, Agile teams are required to be multidisciplinary, and work together on a daily basis to implement functionality work item by work item. As such, co-location of teams, quite often at the client, works best in Agile.
So is Agile more suited than Waterfall for offshore software development? Clearly there are huge benefits. Requirements, analysis and design needn’t be finalized until a work item is actually implemented. So there is no grand, fixed, inflexible design decided upfront. Testing and deployment also take place immediately after coding the individual work items, not only at the end of the project. The total life cycle of a work item is usually no longer than a couple of days, instead of the whole project duration. That is why Agile works well in domains where it is accepted that requirements are never complete and might change, which is the case in the vast majority of projects worldwide.
So what happens when Agile approaches and techniques are applied to offshore software development to overcome Waterfall shortcomings? Apart from the apparent benefits, applying Agile to offshore also comes with consequences. Applying an Agile approach will involve close collaboration between all roles, whether on-site or offshore. It will also involve daily communication, and the ability to work on the same work item at the same time. Communication is therefore key in Agile projects, and as we all know, distance makes communication harder. Therefore offshore Agile teams need to be able to rely on other means of communication than on-site teams. Moreover, it is key that information is clear and unambiguous, which is difficult as this is exactly the bottleneck that Agile is trying to overcome, as work items are not elaborated on until implemented.
But despite some of the difficulties involved in offshore Agile projects, particularly in highly complex domains or around regulatory sensitivities, Agile approaches have the potential to offer many benefits. In my opinion, it almost goes without saying that offshore Agile is going to be more effective to most organizations than offshore Waterfall, but only when key issues around communication, overheads and language issues are overcome. I will explore some of the key strategies for making offshore Agile software development work in my next post.
This post was also published on the ISD Connect website at:
