Off-shoring debate: Time to rethink

The era of off-shoring is over.

The data shows that the wage differential between “here” and “there” is no longer as stunning as it once was. Labor costs in China and India, the main outsourcing hubs, have been going up by double-digits amounts every year for the last 15 years, while salaries in the US stayed the same. Labor in some other countries is still cheap, compared to US costs, but the culture difference is greater, and infrastructure is lacking, making outsourcing projects there even more risky.

In addition, a lot of data (and emotions) have been collected over the last 15 years about off-shored work done badly. Companies are now armed with data that activities that used to be considered peripheral to the organization’s success, when done badly, can have enormous influence on the bottom line. A lot of this work is now being brought back in – geographically and culture-wise.

Another problem, that has surfaced with the practice of off-shoring highly-skilled work, concerns intellectual property rights. US companies are used to strong protections of the law, police willing to investigate, and public, generally familiar with and respectful of IP. As some organizations have learnt the hard way, IP rights are different, and are not nearly as vigorously enforced outside of the US and the developed world, as expected. Companies that choose to outsource work involving sensitive or valuable information find themselves largely on their own, when it comes to enforcement, as local law enforcement, even if local laws support foreign company claims, usually chooses not to get too involved in such cases.

All the arguments boil down to one big question: does shipping work across the globe make US companies more or less competitive? With the data available today, when all costs and benefits are taken into account, the answer appears to be that it is more advantageous to work close to home.

But what about diversity?

Modern thinking places a lot of importance on having a diversified team.   Younger people, older people, men and women, people of different nationalities and cultural backgrounds bring more competitiveness and an entrepreneurial spirit to the project.  Diverse teams are shown to be more creative and better able to connect with customers.  Is it possible to get these benefits when working with a rural team from close-by?

A rural team is likely to have a strong sense of responsibility, a great entrepreneurial attitude, and to come up with very creative solutions in the project space.  Outsourcing teams, located outside of a large market and working on remote projects, face constant competition from on-location talent, and foreign-shore workers.  In order to be competitive, rural developers must (and do!) work hard to maintain and advance their technology and communication skills, pay close attention to the project flow to ensure the highest possible ROI.

Having a quiet environment away from the buzz of a large technology center provides a chance to come up with out-of-the-box solutions for hard problems.  A systematic approach to project organization and iterative methodologies, together with a great deal of access technology, helps to establish a successful communication routine with the project owners and clients.   Working autonomously, albeit with regular interactions with the client, encourages a more entrepreneurial approach and promotes taking greater responsibility for success.

A rural-sourcing team is also more likely to be diverse. People who chose to work remotely come from different life paths and backgrounds, and are more prepared to work together in a diverse team than an average city dweller. A remote team fosters the best qualities that diversity can offer, while being close-by allows for true competitiveness, better communication, and great results.

Road Trip

Imagine planning a long road trip, say from Texas to Alaska. Many Agile classes and presentations have used this as an analogy in exercises about adapting to change. The same analogy can demonstrate means of adaptation to using distributed resources on a multi-disciplinary team.

In the common analogy the trip is planned in great detail: the route, stopping points (restaurants, hotels, etc.), expected speeds, arrival time, etc.  Shortly into the trip, a relative calls requesting a favor.  Since the relative is close to your planned route you make a detour to help.  Alternatively, a newly discovered point of interest causes an unplanned stop.

Both cases put the plan at risk. After the side trip or stop, you can try to somehow return to your original plan but that might involve risking speeding tickets, potential backtracking, etc. It is more flexible to fall back to the high-level details—major milestones—and re-plan the rest as the need arises. The analogy further suggests starting with a high-level plan and adding details when needed is generally more effective and less stressful.

This analogy can be extended to talk about distributed teams. Consider planning the same trip with two vehicles. To help make the point, imagine it is the 1960s. The two cars of travelers would need to stay pretty close to each other.  Significant contingency plans would have to be made in case of separation. If a change to the overall plan were needed, the car wanting to deviate would need to wait for or catch up to the other car to tell them about the change. Then they have to update the plans on where to meet should they get separated.

In the 1970s, the two vehicles would be able to communicate with each other using CB radios. Should one want to deviate or if they are separated, they could coordinate over the radio—as long as they stayed within a few miles of each other.  They would still need a backup plan should they get out of CB range.

Today, we have mobile phones and text messaging with which we can stay in near-constant communication.  The cars would not need to stay in proximity and could still get in touch at a moment’s notice to ensure they ended up in the same place at the end of each day’s travels.  Contingency plans would be made in case one or both car’s lost their phones or lost cell coverage.  However, effective communication would be possible at any other time.

Similar advances have been made which allow distributed development teams to communicate. Years ago it might not have been possible for geographically-diverse teams to communicate on a regular basis.  Later, communication was possible but cost prohibitive.  Today, there are numerous tools (cheap intra-U.S. phone rates, IM, texting, VOIP, etc.).  Some contingencies are made in case the normal means of communications are interrupted however, there is no reason why a distributed team cannot communicate effectively and often to ensure they arrive at the same destination day-over-day, at the end of the sprint, and at the end of a project.

Global viewpoints: bright lines in the sand

Outsourcing is risky business. A large part of creating a company is building a set of values, organizing a team around a cause, creating and sharing a vibe with like-minded people. Hiring an outside vendor to do part of your company’s work is about sharing values and being on the same team with the people outside. Trying to share a vibe with people from afar, who belong to different cultures, can be extremely difficult and often leads to lots of great anecdotes, and many failed projects.

I recently came across an interesting blog post by Inna Kuznetsova, a CCO of a truly global company CEVA Logistics. Inna is no stranger to working with people from different cultures: she first made a career at IBM, where she originally joined Russian IBM headquarters, and later moved to a US-based post. Inna shared a few insights she’s discussed with a friend, an expert on understanding different cultures, on doing business in a global community:

• In some cultures, including American, once goals and milestones are set, the vendor is responsible for the execution. The customer expects to be notified of problems, and perceives lack of news as good news.
• In many other cultures, in particular, in India, the vendor expects the client to maintain tight control of the project. If the customer isn’t closely involved throughout the project, the vendor is genuinely surprised to learn at the end that the client has expected the work to follow agreed-upon schedule and quality standards, and is upset now.
• In Russia, a good boss is expected to take care of his people, both professionally and personally. In America, there are rules of the game which bosses and their subordinates follow: good corporate things happen to those who do their jobs well. In Holland, people want to feel equal across the corporate hierarchy, and thus the boss is expected to make suggestions, rather than final decisions, to the team.

When building a truly global business, learning and taking into account these differences is vital. However, cost savings on a typical software project for the American market rarely justifies the risk and the difficulties of managing a global, multicultural team.

Outsourcing across the globe brings drastically different expectations and experiences to the project, and almost never allows for the team members to build close enough relationships to discover and mitigate their differences for the benefit of the project.

Hiring a local vendor doesn’t guarantee success of a project, but it does make the project much less vulnerable to adverse business conditions.

Distributed Team Potential Pitfalls – Post #4: Distributed A(a)gile

This is the fourth in a series of posts on Distributed Team Potential Pitfalls.  This post will discuss potential risks when implementing the Agile methodology with Distributed teams.

No one will argue that having an Agile team all in the same place, on the same schedule, and 100% dedicated to the Agile project is the most ideal and most productive.  The immediacy and richness of the communications and interactions cannot be beat by any other method.  There are some whom say that even having a distributed team means you are not Agile.

However, unfortunately, that is not always the most cost effective for a business.  Businesses need to look at the tradeoffs between collocation and the possible delays using a distributed team.  The “Agile” in Agile Methodology is capitalized for a reason.  It has been changed from a verb, and the meaning has changed with it.  However, using the Webster Dictionary original agile definitions

• “marked by ready ability to move with quick easy grace”
• “having a quick resourceful and adaptable character”

can be more appropriate for what businesses need from a development team today.  A(a)gile adoption should consider the business needs in the true meaning of the word agile.

That being said, there will be little argument that multiple changes in the way the Agile Methodology is implemented will create a totally different “SDLC” environment in which the risks outweigh the benefits.  If having a distributed team is the only variance in the Agile philosophy then time is the only risk which will likely not be obviated.  The other potential risk, quality, can be assured by ensuring that all other Agile values and principles are observed.  Throwing any other Agile guideline by the way side could create more of a cargo cult and the risks start to grow exponentially.

I worked with one distributed team whom thought that the Agile Principle to “Welcome changing requirements, even late in development” meant that they didn’t have to create as many user stories as could possibly be known up front.  They opted to start with a subset of user stories and intentionally wait to write the rest.  Then to compound the challenge, they grouped remaining areas into epics with large story points and then provided a fixed schedule and cost estimate based on a different team’s velocity.  It didn’t take long to show, in this example, how the risks compounded.  It didn’t take long in the life of that project for them to compound as well.

I’ve seen some companies implement the Agile methodology with teams that have resources whom are only part time on that Agile project.  Again, compounding this with a distributed team environment increases the risk of failure exponentially.  All team members must be able to focus on the project at hand to avoid the time costs of context switching.  Likewise, each team member must be available for all other members at all times. This is even more important on a distributed team.

Obviously, as with any distributed team, there need to be tools and protocols in place at the beginning of the project to help the team communicate and mitigate that risk the distributed team incurs.  (This is discussed in two previous RuralSourceIT blog “POCs” and “Time Zones”.)  In today’s technological world there is no reason for distributed team members to not be able to communicate immediately with each other.

If having a distributed-team environment is the only deviation from the Agile Methodology then the risks can be minimized and a project can be successful.