A CIO’s Account of Nearshore, Ninjas and What Doesn’t Work Offshore

I like to imagine an IT vendor selling the first screwdriver. “It can also replace the hammer, if you use the head of the screwdriver to hit the head of a nail. You also won’t need a knife for butter anymore because it will replace that as well. Crow bar… gone. Car keys… a thing of the past. A screwdriver will replace them all and you can finally standardize on one platform (the screwdriver) and reduce costs across the toolbox.”

The “right tool” approach to the organizational structure of an agile software development project mitigates cost by using arbitrage to achieve lower costs, while minimizing risks from misuse of resources – like using the screwdriver when you really need a hammer.

There are three tiers – offshore, nearshore and local, and then there is a cross-functional, cross-project sub team – the Ninjas – but we will get to that later. The balance of resources between the tiers depends upon the project, the teams, aversion to risk, the company culture and the experience within the teams.

Offshore

Offshoring software development was certainly once touted as the uni-tool. “Send us your development, your call centers, your business processes. Move it all offshore!” And after really trying to make it work, things started moving back home. Offshoring is neither the end-all solution, nor is it dead. But where is it best used in software development?

First, let’s distinguish offshore from nearshore. Nearshore involves similar time zones, allowing for agile development. Offshore is dissimilar enough in time zones that live coordination of the customer and the development team cannot be done without rearranging schedules from standard work hours. And I’ve tried the night shift in offshore models and my experience was similar to everyone else’s that I have talked to – don’t do it. No one should have to deal with high turnover on a “B” team.

There is an unspoken rule to distinguish nearshore from offshore. If you really really do not want to go visit the team at their location, they are offshore. Mumbai – offshore. Anything in Costa Rica or Brazil – nearshore. This doesn’t mean that New Jersey is offshore – they still have to be in a different country.

So, what is the offshore team well utilized for? The answer is non-critical path waterfall development: waterfall because the time difference precludes agile development; non-critical path because delays in communication add unpredictability which can upset the timeline. These delays will occur, and with the time difference, the few exchanges necessary to resolve the situation can take days. Components within this area should still fall into the guidelines for waterfall development – that is that they are highly definable and based off of established business processes not likely to change.

This analysis has been used for entire projects to determine the methodology applied for the process; I am proposing to apply it at the component level. If parts of the project can be developed at a lower cost utilizing waterfall methodology without impact on the whole project’s timeline and with minimal risk, then those components should be sent offshore.

“English-speaking” is a relative term. I can order a beer in German and ask where the bathroom is, but that is about it. By no means do I consider myself “German-speaking,” but there are nearshore vendors who would.

Nearshore

Nearshore development costs fall between the costs of local development and offshore development. It should be obvious that if nearshore development is cheaper than offshore and the quality is in line, then there is no need for offshore. Conversely, if it is more expensive than local development, there is usually no need for nearshore. Also, if waterfall method is used exclusively, a lot of the appeal of nearshore disappears.

The decision factors for balancing nearshore development with local development is not as clear when to send components offshore. Corporate culture, infrastructure, if the company has (or is trying to gain) a presence in the county, exchange rates and numerous other factors play into the decision. There is some residual resistance to nearshoring from bad experiences with offshoring, despite the differences between the two. Generally speaking, if nearshoring is accepted as an option, is fiscally sound and there is infrastructure to support remote workers, then the balance becomes one of comfort level with the development done remotely. In other words, what isn’t sent offshore and what isn’t done locally should be done utilizing nearshore.

When dealing with nearshore vendors, know a few things. First: “English-speaking” is a relative term. I can order a beer in German and ask where the bathroom is, but that is about it. By no means do I consider myself “German-speaking,” but there are nearshore vendors who would. Nearshore development is not identical to remote development, even with every fancy piece of collaboration software and hardware. There are cultural and educational differences, holidays, difficulties in procurement and staffing, economic fluctuations, irrational government regulations and so on. Where these issues exist in local development, they are amplified in nearshore development.

Local

There is a psychology to software development. Local development allows developers to understand local and corporate culture, establish bonds with product owners and other employees, participate in ad hoc conferences and lunches and so on. The degree to which the influence of proximity holds varies between organizations and between projects. Some view programmers as only interfacing with project managers – these people will be more comfortable with more offshore and nearshore development than one who organizes more in a cross-functional pod-like manner.

My personal preference is to keep project management and analysis local, and then to create cross-functional teams comprised of local and remote members. Having local management and some local development presence keeps the team aware of the corporate environment while mitigating costs. The question that comes is “What is the proportion between the two types – nearshore and local?” 80/20. Just kidding, the reality is – this is one of the toughest decisions managers are paid to make. Do not expect to employ empirical data to arrive at a solution, but instead rely on xperience and knowledge of the company and the project.

The Ninjas

Finding and keeping highly valuable “Ninjas” will form the bedrock to your success. It is not enough to be a senior/experienced/excellent programmer to become a Ninja. People skills are required, because the Ninjas deal directly with customers, program managers, end users and so on. Ninjas can be coupled with or act as a temporary stand-in for business analysts and project managers. Need more testers? Throw a Ninja in there. Project off track? Ninja will fix it. Everyone should have Ninjas.

Ninjas are rare, and by no means does everyone have the ability and desire to be one. They are strategic, tactical, multi-talented, affable and analytical leaders. Their presence provides mentoring to developers, stability to managers, insight to analysts and project managers and a sense of security to the customers. They should be well paid and taken care of, lest they become someone else’s Ninja. They need to be kept from entering management, lest they become “Freecell” Ninjas.

Conclusion

The best tool for the task at hand. And Ninjas.

Chris Synder, CIO at Hulcher, will be appearing at the Nearshore Nexus Conference, April 2012, in New York City. Follow NSAM (@NSAmericas) for regular updates.