Three easy ways to improve offshore software development
Poor communication, in some shape or form, is almost always the problem.
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.
1. Knowing what to build
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
2. Communicating effectively
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
3. Working well together
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.
I’m Frank, an autistic software engineer and owner of Better Software UK, a software requirements consultancy.
