Team Graft — Creating Nearshore Agile Relationships

Outsourcing has been around for a while.

Companies have historically been outsourcing IT work to partners in other geographies, to cut costs and operate more efficiently. Offshoring moved to nearshoring and to building fully integrated nearshore agile partnerships.

From the early Eastman Kodak days, in 1989, things have come a long way. The drawbacks of outsourcing business functions to faraway locations were hard to miss. Cultural differences, communication problems and time differences have been some of the rampant problems affecting software offshoring as we understand it.

The Nearshore alternative. But is Nearshore Agile?

What started as outsourcing on the US — India path evolved into US companies sending work closer — nearshore — to Mexico and other Central and South American locations. In turn, European clients found nearshore help in Central and Eastern Europe.

The early enthusiasts of outsourcing software projects were obviously risk-takers, open to novelty and interested in anything that could make their projects be able to pivot easier and materialize faster and cheaper. It is thus no wonder that these early adopters of outsourcing were also early adopters of Agile processes.

Early nearshore teams were usually long-term extensions for a single client’s team. Once the client embraced agile processes, the outsourced team had to follow suit and become nearshore agile.

The challenge appears when seeking to build a new agile nearshore relationship between an established client and an established provider. They each have their own customary tools and processes, and the nearshore provider needs to adapt quicky and efficiently to their client, without compromising on quality. A true nearshore agile relationship avoids value substraction through integration costs and management overhead.

The baggage that each player brings to the table should not be neglected; what worked worked for a nearshore provider in a previous project, under different circumstances and in a different type of environment will not necessarily work again. Yet the nearshore provider might be inclined to believe it will.

In and of itself, the relationship between client and provider is not born Agile. Contract-induced KPI blindness and milestone haze (inherent to Agility, since there is not one bang-go-live! moment) can be amplified by distance and lack of co-location.

Creating a Nearshore Agile relationship.

To make sure that 1 + 1 != 0 (competent client and competent nearshore provider do not result in a disastruous relationship), several steps can help.

We will assume you are dealing with a professional company, with successful projects in their track record, and a good grasp of Agile practices.

First of all, you need to talk and get (at least a first) impression of each person who will work in your team. No certification or impressive resume will make up for sheer lack of chemistry or poor communication.

Make sure that both the nearshore team and their management are flexible enough to accommodate change. If “we do it our way, ’cause our way is the best” comes into play, you could waste time and nerves down the road. Your own internal processes and practices should be well established and easy to follow and adapt to.

Make sure your neashore team members are confident and candid enough to speak up when there is a problem.

Define responsibilities. If all engineers (internal and nearshore) are busy developing, who is expected to provide QA? Is everybody on board aware of this?

Mastering an Agile mindset, understanding and being able to apply Agile processes provides a nearshore Agile team the essential building blocks to be ready to enter a new relationship smoothly and successfully.

Agile relationships require a good agile nearshore team. And this team is like a band of skilled musicians. If they know the notes, chords, progressions and are not stuck to an existing playlist, they can and will adapt to a new tune.

Find out if we can help you reap the benefits of an agile nearshore relationship — www.dotnear.com. This post first appeared on dotNear’s blog, in January 2021.