An interesting feature of the globalizing world, is the option to move jobs to locations with a higher availability of competence or a lower cost of production. Specifically CIO’s have been happy to investigate that option and from second half of the nineties, we saw tons of companies offshoring software development projects partially or entirely, often to India. With the first successes, and the fast rising number of companies participating, came also the first failures. And as time went on, more failures. By halfway the first decade of the 21st century, offshoring fell out of grace in a respectable number of companies and ‘reshoring’ became a thing.
Reshoring? As in: “nearby, or in-house”
Increasing wages overseas, lack of integration, travel costs, communication difficulties,… there is a plethora of factors causing companies to reconsider the offshoring and bring the jobs back. Back as in ‘in-house’, or at least ‘nearby’. While there are sufficient reasons why offshoring didn’t work, local limitations that in the first place pushed companies to offshore, didn’t necessarily disappear. A local lack of sufficient competent, available and affordable engineers forces to keep the eyes open for alternatives.
That is where the nearshored Extended Team Model comes in, being… in-house, nearby.
Zahedi and Ali Babar define in their 2013 paper the Extended Team Model (ETM) as “a customized offshore outsourcing collaboration model based on long-term partnership of two sides in which offshore site considered as an extended arm of the core team at onshore. The ETM emphasizes on building a unified team with close interactions across the locations beyond client-vendor relationships.”
Scrummaster and Agile Coach Duncan Evans blogs that to make distributed teams work, there are three simple steps to take. The first one is investing in people and is mainly a responsibility of the supplier, the company building the Extended Team. A second is establishing purpose. In the Extended Team Model, this is the responsibility of the client, who will define the vision and communicate it to the local and extended teams. The third step is to experiment with processes and tools, in close collaboration between the local and the remote team. Zahedi & Ali Babar (2013) see a lack of shared understanding of processes as one of the main difficulties in Global Software Development (GSD), making alignment between the on-site and nearshore team an important challenge to tackle and a mutual responsibility. Own experience learns that not sufficiently taking the remote team into account while deciding on tooling does generate frustration on the site of the remote team.
At Epikia we mix the nearshored Extended Team Model with the steps Evans describes and fine-tune to enable our teams to become a seamless extension of the clients local team:
- A thorough intake to build up a deep understanding of the clients’ vision, processes, preferred methodology and tooling. This understanding will lead to a customized implementation of our generic model, mirroring in our team the vision, approach, tooling, and culture of our client;
- A joint recruitment effort where the recruiting is taking care of by Epikia. The selection is a joint responsibility of Epikia and the client. Once the selection done and one final candidates emerges, Epikia makes a contract proposal. Once joined, consultant who will work long-term (“for the foreseeable future”) in a dedicated, extended team of the client, on the clients’ projects;
- A daily electronic communication between client and (members of) the Extended team, completed with regular (bi-weekly, for sure in an initial phase) remote visits at the Epikia-offices with face-2-face interactions;
- Epikia staff takes care of the follow-up HR activities as payroll, training, evaluations, … The evaluations are obviously based on daily performance and will be discussed with the client;
- When the typical client-vendor relation is a project-based one, due to the specifics of this model, we will focus on creating a relation which goes beyond client-vendor relation, assuring an always tighter integration.
Looking forward to read your experiences with extended teams in the comments.
1/8: Updated to correct some typo.