What to do when developers on the other side of the planet aren’t doing what you need.
By Frank Ray. Website / LinkedIn / Email
Offshore development is pretty common these days, but well-performing offshore teams are less so. Broken and incomplete features, delivered slower than expected, with increasing tech debt and a degraded codebase, are the hallmarks of outsourced and offshore development.
Being on the receiving end of a poorly performing remote development team is distressing, especially if you've tried everything you can to fix the situation but poor-quality interactions and high levels of rework remain the norm. It’s even more upsetting if you previously had an excellent local development team you waved goodbye to.
Lacking the expertise to manage a remote development team increases the chance of things going wrong, and not having deep enough pockets to withstand the difficulties can be catastrophic. Unfortunately, these experiences are only too familiar.
These are the guys on the other side of the planet. They don't want to be stuck in a poorly performing remote development team. What they really want is to write good code, submit PR's multiple times per day, and be praised for being rockstar developers.
This guide contains everything you need to get them performing well together.
Poor communication, in some shape or form, is almost always the problem. It’s not always easy to see, so here are the areas to focus on.
Expecting developers to magic something from a vague idea or a one-sentence user story isn’t a particularly helpful approach. Whilst technical staff are great at solving relatively well-bounded technical problems, they are dire at stepping into the customer’s shoes. Offshore software developers don’t usually speak to end users anyway.
Understanding stakeholder needs is the foundation of every software product and should be a continuous and ongoing activity. But moving beyond ideas and concepts is hard work because you need to really think about what should be done.
It’s not enough to ask users, “Tell me what you want”, because they don’t always know how to answer the question. Really understanding their needs and devising appropriate solutions is what requirements gathering is all about, a human activity that takes time and patience to do well.
Somebody must decide which features will best satisfy users and stakeholders, and when precisely to deliver them. Product decisions are highly visible, long-lasting and impact real users, making product ownership challenging but incredibly valuable and very rewarding.
Read more: How to gather better software requirements
Teams with poor software requirements don’t deliver well on them. Remote, outsourced and offshore teams with poor requirements fare even worse. I have never come across an underperforming development team that didn’t also have a requirements problem.
Select a few requirements from your team to inspect. Are they clear and effective? Do they convey the outcome required? Report back and tell me what you find.
Developers need a clear understanding of what to do. Some developers tolerate ambiguity better than others. However, they still need a clear understanding of what to do.
User stories describe what is needed and provide sufficient information for the developer to make the right decisions. Technical design and implementation are not prescribed, unless there is good reason to do so, as the developer’s job is to figure that out.
Refinement sessions ensure developers understand the stories and can work without unexpected blockers or the need for unplanned, ad-hoc conversations. Well defined user stories are your best chance of building what is required and avoiding waste and re-work later on.
Read more: How to write better software requirements
Developers struggle when the people who can answer questions are not readily accessible or available. Remote developers struggle more due to their lack of co-location and increased reliance on written communication. Difficulty getting answers in real-time, waiting on emails and language barriers are all things a local development team would never face.
Understand the offshore developers and accommodate their needs as best as possible, avoiding the temptation to impose local processes without first assessing their suitability. Meet up in real life, put some faces to names and get to know each other.
Offshore teams that work similar hours to the local business can more readily act as an extension of the local workforce. Active engagement and good communication between both sides support more intensive ways of working, such as a local Product Owner-led, remote Scrum team.
Alternatively, many offshore teams perform best when they are responsible for end-to-end feature development rather than bouncing part-finished work between distributed teams. This avoids the need to collaborate, reduces decision latency and promotes maximum workflow.
Offshore development is pretty common these days, but well-performing offshore teams are less so. Being on the receiving end of poorly built software is upsetting, especially if you've tried everything you can to fix the situation. But it doesn’t need to be like this.
The solution is knowing what to build and communicating it effectively to the developers doing the work. Good product ownership aims to better meet the needs of stakeholders in each software release, and well-defined user stories provide developers with the information they need to make the right decisions.
Improving remote development is easier and less costly than you may think, but it does mean changing how a company works. The development team and company management must really want to. Otherwise, inertia takes hold and everything stays the same.
If you are unhappy with your development team, they may need more detailed guidance. Better software requirements can help with this.
Raise an issue if there is a topic you feel this guide should include, or get in touch directly if you are considering making a direct contribution via a PR.
Please note, I work on this guide as and when time permits.
© Better Software UK. Better software requirements can change the world. Get in touch if you need our help