Let’s start with the one that’s most important to me when working with nearshore teams.
Nearshore developers are too often treated like lemmings. Expected to work away on mind numbing tasks without complaint, forced to deal with less than optimal environments and work to instructions rather than goals. And - most importantly - function without connection to their onshore team. We’re not talking simple comms here, but a human connection. Admittedly it’s a long distance work relationship so we’re unlikely to forge lifetime bonds, but just a little can make a big difference.
Do what you must to make that happen, to the degree you can. For me it was:
In the past I’ve used (carefully selected) buddy systems to encourage this. Something that didn’t seem necessary this time around. I put this down to those earlier newbie factors of better comms and shared environments/practices, but maybe it just came down to the right mix of personalities.
Regular reporting of progress to the whole team is critical to maintaining that motivation of a team working toward a common goal. Make sure you have a way of doing this before you begin. For us it started with the usual Azure DevOps Sprint Board, something I’d consider a minimum.
To really feel progress however, it’s so important to have an easy visual. DevOps dashboards have a good deal of capability in this area but for us we had a lot of stories across multiple priority areas and I didn’t feel the widgets on offer would cut it.
I’m a stickler for instant visual feedback reporting so took the time to combine a DevOps export and some excel work to produce a progress grid that broke down progress into the prioritized features that needed translation. That progress grid was up every standup and we as a team adjusted each day to make sure we remained on top of it.
I’m not a contract specialist, but I’ve seen enough software engagements hampered or destroyed through poor contracts to list this as a must have.
I won’t go into the details of agile contracting as there are many texts and sites that cover this. I’ll just say we ensured our contracts, contract negotiations and induction/kick-off met the constraints of agile contracting. The principles boiled down to:
It’s nice to be a short flight away from your nearshore team. Hence the nearshore buzz (you’ll note the absence of ‘offshore’ in this post). But it’s time zones that kill collaboration. Reducing efficient on-demand dialogues into disjointed day or week-long monologues.
Our nearshore partners were nearby and in our time zone. A reassuring solid green dot against their name in MS Teams. Success factor gold!
We had to deliver this fast. We had to ramp up a decent team quickly and once they were ready couldn’t afford hiccups along the way. But the code we had to write was not hugely complex and the development ecosystem had proven it could quickly guide the necessary practices of new developers.
For us that meant going to a large proven provider - in our case Mitrais - and setting up an on-demand team through a three-day crash course. This was one of those times where those underlying principles kicked in and I played with the levers a little. In this case it worked, but normally it’s the last thing I’d recommend!
Long term plays, using captured or managed teams, through proven nearshore providers, where you spend as much time selecting and upskilling your nearshore team as you would an onshore team, is my recommended recipe for success.
There you have it - the factors that made this round of nearshored work a success.
There are a bunch of principles that underly these practices and the fun bit comes when constraints force you to get to know these and play with the levers to see what works and – hopefully in decreasing portions – what doesn’t.
If you’re interested at a principles level drop me a line – I’m all ears. I love this “human meets tech” stuff.
Get in touch via LinkedIn or our Contact Page any time.