Decipher's CEO recently threw us a challenge: accelerate the delivery of their cloud product’s internationalization from six months to six weeks!
And somehow, through a gargantuan effort we did it.
Key to hitting that target was a swift ramp up of the productivity of our Mitrais nearshore delivery partners.
Now the dust has settled I’d like to share with you the reasons I believe it went so well. Some are well worn truths. But others are new. Enablers that were largely not available a short time ago.
Those new enablers centre around DevOps, the Cloud and what these are doing to boost Agile. Three separate but reinforcing advances that are transforming what IT can do for business.
Getting offshoring (and in fact any software outsourcing) right is a balance of several principles. Like my special, homemade spaghetti bolognaise, no two endeavours are alike but all share a common underlying set of dos and don’ts.
You’ll often see these principles poke their head out from behind the success factors below – but I’m not going into any detail on them in this post. I’ll just cover things from a simple “what worked this time around” perspective.
There’s a lot to cover so I’ve broken this post into two. Part one covers technical practices and some recent enablers and part two goes on to cover the team practices that support collaboration, purpose and accountability.
If you’re like me you’re never comfortable until you see change validated and tested in an independent and controlled environment. And nearshore devs don’t get the feedback they need until that’s happened either.
The excuses for making this happen are many - and in a non DevOps world often justified. And in the land of offshoring where validation is king, constant calls of “nearly there” are hugely frustrating and – more importantly - dangerous.
And so our DevOps ecosystem proved vital. Starting with easily established nearshore development environments and ending in a responsive onshore quality assurance capability. Validation was constant and excuses for non-delivery impossible to find.
It’s tough to go off track when you’re delivering regularly. Our nearshore devs submitted pull requests to their onshore buddies every day. Sometimes they strayed and it’s easy to imagine how some of those tangents could have ended in tears. But with daily reviews those tangents never got a chance to be more than a wobble in our progress.
During previous nearshore experiences significant effort was spent on a principle I called “sharing the pain.” Your nearshore team should not feel pain you don’t feel onshore. When their pain is unique, the potential for divergence grows.
Onshore:“Why haven’t you been running the automated tests?”
Nearshore: “Because they started failing trying to connect to the orders database. I think someone must have changed a firewall rule. We just asked our devs to run their tests locally.”
Onshore: “But you’ve broken 22 tests and I’ve got to ask how you ran the system at all without the orders database”
Nearshore:“…”
Onshore: &^*@&^#&!
Tough to explain that hiccup in progress to the boss without destroying his confidence in offshoring.
Thankfully with an all cloud ecosystem and repeatable environments, exchanges like that should be a relic of the past. Security is important here btw - getting this right so you can entrust your nearshore people to have access to what they need without compromising sensitive data.
I was walking to a meeting the other day and had five minutes to jump on my mobile teams and catch up with the nearshore team’s progress. Crystal clear, sharing if I wanted it, and their names and online status was readily available. How easy it’s all become.
It’s no secret that open and reliable comms is key to offshoring and it’s surprising how small the barriers need to be to tear that all down. A great attention sucker in many earlier nearshore endeavors has been establishing and then maintaining good comms between the onshore and nearshore teams by overcoming a myriad of policy,security, availability, connectivity and compatibility barriers.
I can honestly say that after a few minor hiccups, not I, or anyone I know on both teams, was ever left wanting for comms. And the number of independent connections being made between onshore and nearshore team members was very encouraging.
Convergence is playing an ever-increasing role in effective sharing of codebases and I believe certainly helped in our case. I see this as a product of DevOps and the cloud breaking down the fire walled cottage-industry internal architectures of old, together with, of course, a generally maturing software profession.
That’s not to say it’s any less complicated! Things don’t seem to be getting any easier for us devs (or is that just me?) but at least the tough stuff is mostly in the public domain now. Cloud deployment models, with larger user bases sharing increasingly homogeneous environments, means better tested, documented and understood architectures, frameworks and components, than ever before. With onboarding often just a few Pluralsight or Udemy courses away.
In part two I cover the team elements that helped the success of this engagement. Practices that encouraged shared goals, collaboration and accountability.
Interested in talking through your offshore aspirations or experiences? I am always keen to explore and discuss these "human meets tech" fields. Get in touch via LinkedIn or our Contact Page any time.