Offshore Agile Software Development: Does It Work?
Software & Web Development

Offshore Agile Software Development: Does It Work?

Agile software development is an often misunderstood and misused term. In an exclusive new series of articles, IDG Connect offers expert insight and opinion on Agile. In this piece Sander Hoogendoorn, Principal Technology Officer and Global Agile Thought Leader at Capgemini, discusses Agile and Waterfall as different approaches to Offshore Software Development.

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

By Sander Hoogendoorn, Principal Technology Officer and Global Agile Thought Leader, Capgemini

PREVIOUS ARTICLE

«Rant: Working From Home's Not Working

NEXT ARTICLE

Offshore Agile Software Development: A Practical Guide to Making It Work »
Sander Hoogendoorn

Principal Technology Officer, Global Agile Thought Leader and foremost Developer

  • twt
  • Mail

Comments

no-images

lyrx on May 30 2015

The main problem with vinyl records is the pops caused by lint in the grooves. It seems in the 21st century someone would solve the problem.

no-images

Tarzan on June 05 2015

I have a VERY large vinyl collection and have just decided to sell/transfer ownership of the entire lot. I was a Billboard/Record World/Cashbox Dance Chart magazine reporter from 1975 through 1985. Need I say anymore about the hidden treasures in the collection. 20,000 LP's, 12", 45's, test pressings, colored, limited edition pressings and remixes only presented to reporting DJ's.

no-images

lyrx on May 30 2015

The main problem with vinyl records is the pops caused by lint in the grooves. It seems in the 21st century someone would solve the problem.

no-images

Tarzan on June 05 2015

I have a VERY large vinyl collection and have just decided to sell/transfer ownership of the entire lot. I was a Billboard/Record World/Cashbox Dance Chart magazine reporter from 1975 through 1985. Need I say anymore about the hidden treasures in the collection. 20,000 LP's, 12", 45's, test pressings, colored, limited edition pressings and remixes only presented to reporting DJ's.

Add Your Comment

Related reading

AppDynamics

Analytics Software

How Application Intelligence Powers Digital Transformation...

The very nature of modern digital commerce has blurred the lines between IT and business. This white paper discusses the top focus

SilverPeak

WAN

The Software-Defined WAN

Today’s hyper-connected, cloud-based environments demand greater agility and efficiency. Enter the software-defined WAN, which can address th

Most Recent Comments

no-image

Resource Center

  • /view_company_report/775/aruba-networks
  • /view_company_report/419/splunk

Poll

Would a Brexit be bad for UK tech?