Outsourcing Software Development to another Country Stinks
It stinks big time.
It stinks because it had a terrible beginning that shaped the current nightmare it mostly is. The beginning of offshoring software development started under the Waterfall model.
- “O.K. let’s install a sweatshop in this third world country. We can find skilled enough workforce to develop software almost for free. We don’t have to deal with the expensive salaries and benefits that these American employees are costing us”.
- “Why not, we write the specifications, we hand them over to the Development and QA team in Banana Republic.”
- “Yeah, why not, it works for the textile sweatshops: You give them instructions, they are smart enough to understand them, you hire low cost managers to watch over shoulders, and voilá!”
That stinks. At AgileNearshore we really make an effort to avoid working with the type of clients whose only motive to outsource software development to Costa Rica is because they want to lower costs (that is, Costa Rica workforce is cheaper that American workforce, but not the cheapest globally, we have other differentiators). We only talk with clients that
- Are located in the United States: We don’t want to cope with time zone differences since it is a synchronization nightmare. We definitely don’t want that.
- Have a commitment to Agile’s approach: If the prospect client has a Waterfall mindset, we can refer him to competitors who are willing to enslave developers to do that.
- Are willing to do upfront co-location of the team with the Product Owner: We want to build a bond between the client and a team. If the client is not willing to spend time co-located with a team (at least initially), the transmission of value is in danger. After all, flying to Costa Rica could be closer than flying to other U.S. cities, wouldn’t it?
- Have a greenfield project to get developed: Legacy projects bring inherited bad practices and undesired architectural constrains with them. We want our team to have full control over the deployment environment from the beginning.
Why are we so picky? Because combining Offshoring with Agile is hard. So hard that some understandably claim it is impossible.
Let me tell you why it is so hard, and why so many offshoring instances I see make life so miserable for clients and developers.
A nightmare explained
Ten years ago, American companies started to outsource their software development to paradise (yes, Costa Rica). About the same time, the Agile movement started to appear and to realize that when it comes to developing software, we have come to value (as the Agile Manifesto says):
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
Wait a minute. Let’s go through these valuations in an offshoring context.
Individuals and Interactions over processes and tools
How are you going to value individuals and interactions if your software development team requires team members scattered around the world? This question is valid even if absolutely all the team members are in the same city, but they do Working-From-Home.
The only instances where I can say that WFH works are those for teams smaller than four people. Teams bigger than that require being co-located in order to get real collaboration, and meaningful communication to happen. Period.
If your team doesn’t require intense collaboration, then WFH makes sense and it is effective. I am just curious to know which software development process of a regular size doesn’t require intense collaboration.
Working software over comprehensive documentation
Offshoring relies heavily on documentation to move knowledge and information around. If your development team is eight plus hours ahead of you, or part of your team is eight plus hours ahead of the other part of your team, you heavily rely on extensive documentation to get synchronized, which normally doesn’t work because it never conveys the full meaning and intention of the author.
I’ve successfully lead distributed teams, team members in Costa Rica and team members in India, and the time difference is the most painful hassle on earth. Even if you use video conferencing, and alternate “sacrificing synch hours” (e.g. this week Costa Rica’s team member will give up their free time to synch with India, but next week it will be the other way around), you never get the productivity of a co-located team.
When I say: “I’ve successfully lead distributed teams”, I mean:
- “We delivered the product to a happy client”. Had I had a co-located team we would have delivered it much earlier and to a much happier client.
- As a leader I had to sell to Costa Rica and India teams the almost unconvincing statement in practical terms: let’s be one team, even if they are on the other side of the world. All of this heroic team effort at the expected third world cost.
However, no member of these heroic teams is willing to do something like this again. Simply put: It is a burden to deal with time zone differences.
And because heroes are not common, what normally happens is that the team doesn’t deliver high quality working software on time.
Customer collaboration over contract negotiation
The complain number one in Agile adoption is that the client is not available. Now take the negative impact that such problem creates and multiply it by 100 in an offshoring context.
The negative impact is amplified by the fact that normally there is one proxy person between the client and the development team (“team members don’t know how to deal with clients”, “team members speak broken English”), so business expectations are not accurately transmitted to the team, or technical limitations are not effectively communicated to the client.
Responding to change over following a plan
Offshoring firms thrive to catch really big projects. The math is simple, in order to keep offering low costs for a developer they need volume (lots of developers to charge for), these firms need a reliable source of income based on hiring huge amounts of inexpensive workforce.
Big projects (and the money they represent) can easily cloud judgment. Salespeople and Project Managers work in terms of hourly rates. Hourly rates tend to cloud judgment because they hide the fact that the bigger the project, the greater the uncertainty inherent to it. Big projects tend to be fix-scoped with tasks broken down to the detail of how many hours needed per developer per task (we are reducing costs here, detailed upfront planning of the hours needed by tasks because we are being charged by hour). Detailing planning by the hour gives up-front precise (although not accurate) estimation numbers, giving the illusion that nothing is uncertain. Along with deliverables every four months, the ability to respond to change is nullified.
Why the Waterfall model doesn’t work
The reason of the Waterfall’s disaster is candidly expressed by the first person ever to describe it (and to draw a diagram for it), Winston W. Royce in 1970, in this article: it is “risky and invites to failure”. From then on, the ‘scientific’ community rushed to cite Royce’s description and diagram, without including his comment of ‘well, it simply doesn’t work for software’.
Tarmo Toikkanen has a brilliant explanation of the embarrassing propagation of this wrong idea: “People remember images. And people often read the beginning of an article, but not the end.”
People saw a diagram that described software process in a way that seemed similar to other engineering fields. It was the only thing that mattered.
As we say in Costa Rica, software is not as easy as “blowing out and making bottles” [Ok, such a proverbial comparison may be said in other Spanish speaking countries also].
Software is uncertain.
Software is complex to be specified upfront.
Software is complex to build.
Outsourcing software development to countries whose costs are lower does not reduce its complexity.
Even worse, outsourcing software development to such countries INCREASES its business and management complexity.
From my experience, the only way to get a trade-off without losing quality and time to market is not get totally driven by reducing costs when deciding where to outsource. Make incremental and frequent commitments with the provider as you build trust with him. In case of big contracts, do an Agile Release Planning and do an agile contract. Be willing to travel to build social capital and ease synchronization, and once in Costa Rica you can take advantage of the many affordable and nearby tourist destinations.
Do you have this agile mindset? Do you really want to successfully outsource your software development to Costa Rica? Contact me. Let’s start a conversation about this.
People who looked at this item also looked at…
Related items
posted in costa rica, outsourcing, Quality |
