Many companies have used the excuse that the off-shore service delivery model is more cost effective than co-located Agile teams. This is intended as a presentation designed to spark dialogue with the session participants on their own experiences with this hypothesis.

The presenter will first give a brief history of the off-shore outsourced software development model covering why it has become popular and why it has started failing compared to teams using Agile methodologies.

Introduction

Now that off-shoring has become well established throughout the software development industry, it is time to review the practice using real project metrics to see if the off-shoring model does in fact deliver on its promise. Looking at real metrics for quality, efficiency and productivity do not support the rosy picture of solid savings and successful projects. The authors both have substantial experience with software development efforts and have worked on projects with a mix of off-shore and co-located components. In this paper we will go beyond the anecdotes and rumors to demonstrate that co-located teams using Lean-Agile practices deliver better quality work in significantly less time and money, even more cost effectively than Agile based distributed teams.

I am sure you have all heard the hype about the benefits of using off-shore development resources. The vendors are promising that moving software development work to India, China or whatever flavor of the month off-shore location will cut costs by 30-50% or more, plus you will gain flexibility and access to highly skilled talent you can’t find in the US. It sounds great and the published salary rates for off-shore developers seem to support the savings. Certainly over the past five years, enough companies have believed the stories to move substantial amounts of their development efforts off-shore. (Need an actual number here) However, what is missing from this rosy picture is the high percentage of companies that have quietly moved their development back in house, because they have discovered that there are more efficient methods for developing software that don’t have the same risks as off-shoring and produce better quality work for significantly less cost.

Research Methodologies

The authors have had the opportunity to work with many organizations and over 20 teams over the past several years. The teams were all unique in technology, mission and geographical locations; however all the teams utilized some form of Indian contract labor varying in degrees. In several cases, the teams were observed and metrics on their effectiveness and efficiency were captured, using financial records, hours worked on a given project, number of defects and other standard measures of productivity. After analysis of the numbers and a comparison of the teams productivity, the impact of switching to an off-shoring and distributed team model was evident in the reduced quality of the code bases, overall team productivity and organizations’ technical leadership skills.

Understanding the Problem

There have been numerous reasons cited in case studies and in the press for off-shore project failures. However, it is often hard to gain an understanding the state of a given company’s off-shore development efforts due to the great difficulty in capturing real metrics. Many companies are reluctant to share embarrassing details of troubles. Company executives and managers who negotiated the off-shoring contracts are frequently not the project managers who execute them, so there can be large disconnect between the contract intentions and the actual deliverables. Since management is often rewarded for short-term cost savings rather than deliverables that may not be realized until years later, the temptation to sign an off-shoring contract to demonstrate savings can be overwhelming. In one case a vice president retired with a substantial bonus a few months after authorizing a major off-shoring contract, so he was not around to blame when the contract was canceled two years later for failure to deliver.

With that said, in recent years there has been a number of academic and industry efforts to quantify the risk factors so that project teams and corporate management can both predict the potential risks and possibly mitigate them. The list of potential off-shoring risks at the meta-level includes the following:

• Economics: labor, capital, infrastructure

• Politics: legalities, ideology, instability

• Culture: language, social norms, gender roles

• Demographics: migration, urbanization, population

What many don’t realize is that often the failures are caused by multiple factors magnified by the communications difficulties between members of teams and teams separated by not only the obvious issues like language and culture, but multiple other issues. In the end, the more risk factors identified for a given project and team has the greater the likelihood of project or team failure. Some of the contributing factors that must be captured include:

• Distance/number of time-zones crossed

• Number of team locations

• Size of the team

• Differing expectations for outcome

• Team member skill set mix

• Number of companies involved in project

• Unclear corporate loyalties

• Team organization

• Mixed messages about team leadership

• Sponsorship – That is who is paying the bills and what are their objectives

Not only are the listed risks magnified as more are added but the issues have a cumulative effect, so the rate of failure for teams with multiple risks is higher than would be expected if the risks were just additive. All of these factors can effectively deep-six a project that looks on paper to be a perfectly reasonable off-shoring fit.

The Emergence of Off-shoring as a Business Practice

Factors for Initial Success

Changing Business Conditions

The Disappearing IT Workforce

Time to Market Matters

Chasing Arbitrage Rainbows

Off-Shoring Best Practices

In response to the increasing difficulties and failures to achieve the promised cost savings companies have responded by developing a number of best practices to insure that off-shored projects have a higher probability of success. Some of the more common best practices include:

• Projects teams limit development methodologies to a waterfall approach and create the project requirements before any development effort is started. This also assumes that the project requirements are both very detailed and remain stable throughout the project’s lifecycle.

• From the beginning of the project, extremely clear expectations are set for the offshore team and the contract with the off-shoring company is well vetted by the legal department.

• Parent companies use their best systems architects and other high level resources to oversee the offshore development to make sure that the business requirements are translated correctly.

• Companies deskill the projects as much as possible so they can move simple and repeatable tasks off-shore to minimize issues with poorly trained and high turnover off-shore staff.

• Larger companies eliminate the middleman and create off-shore subsidiaries so the off-shore resources are part of the parent company. This approach eliminates the conflicts of interest, but does not solve the cultural and political difficulties.

• Parent company managers visit the offshore team during the project duration to establish good communications and relationships.

• Some members of the offshore team join the onshore team to minimize communication problems caused by distance and differences in expectations.

• Apply Agile methodologies, training and coaching to both teams together to increase productivity.

Creating Distributed Partnerships

Using Agile Methodologies for Distributed Teams

Lean-Agile Best Practices: Creating Small, Powerful, Co-located Teams.

Some of the factors that really make a co-located Lean-Agile team so productive are as follows:

• Customer/developer partnership

• Cooperation through co-location

• Short development iterations to identify issues before they become major problems

• A focus on quality

• Continuous process improvement

• Career growth and mentoring opportunities

Conclusion

It is quite clear that the off-shore distributed model for software delivery is in deep trouble. The underlying assumptions about relative labor costs, skill sets and productivity are now shown to be incorrect and increasingly less justifiable. To combat these trends and reverse the rapid decline in productivity and quality, it is time to take back the software development process by applying Rapid Application Development (RAD) methodologies using Lean-Agile practices. By applying these principles along with the creation of continuous improvement and continuous learning environments it is possible to create small, powerful, adaptive, sustainable software teams that far out perform any off-shore distributed development team.

Appendix A – Case Study: Off-shoring Gone Bad

A project where everything possible that could go wrong did, illustrating many of the issues brought up by using high distributed off-shore teams for knowledge work.

Appendix B - Case Study: 80 for 10 Indian Agile Conversion

In this case, the host company converted a high functioning co-located team to include an Indian component and actually lost 30% productivity in the process.