BLOG

Team practices supporting collaboration, purpose and accountability

In part one I covered the technical elements contributing to the success of a recent nearshore engagement for Decipher. Now I’ll look at the team practices that helped make the project a success.

Shared purpose and connection drive the best collaborations

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:

• Travelling to spend a few days face time with the nearshore team. If I could I’d have brought the whole nearshore team over for a week or taken the onshore there, but I think that might have been tough to get budget for! I have recently observed that the improving quality of comms is reducing the importance of this ceremony. But it’s still important. Face time helps quash the scary monster on the other end of the phone and open conversations.
• Daily representation at standups where we might share a joke or reveal a personality snippet.
• Encourage one-on-one comms between onshore/nearshore members. And God forbid, pick up the phone from time to time. Even use some video.
• Minimise demarcation. We each had our own areas to address but onshore and nearshore were free to distribute the load when required. Those shared environments and practices I mentioned earlier are critical to that btw.
• Finally, there’s a lesson that crystalised for me reading “Peopleware” many years ago - without a common purpose, there is no team. Personally, generating this came in the form of a shared kickoff outlining a shared set of goals.

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.

Real time instantly visible progress reporting

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.

Contracts that protect without compromising collaboration

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:

• Manage risk through iterative validated delivery
• Set scope as high level goals
• Clearly define capability and practices expectations
• Provide a digestible exit clause should validated deliverables, capabilities and/or practices not meet stated expectations
• Use estimates only to aid in determining whether those expectations are being met – not to set pre-defined contractual penalties.

Distance matters but time zones kill

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!

Choose the right nearshore partner

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.

‍

‍