Remote developers often get blamed when something goes wrong. Broken features, slow delivery, tech debt. It doesn’t really matter, the finger is quick to point to ‘poor quality developers’ or ‘bad engineering’. Whether deserved or not.
Sometimes, it’s almost like everyone prefers having a team who are the clearly marked scapegoats. Their real purpose is to shoulder the collective failings, unquestionably. Maybe they should get paid danger money. Anyhow, I digress.
I can’t remember ever coming across an underperforming remote team that didn’t also have a requirements problem of some sort or other. Personal experience tells me to look for this in every remote development team, before considering anything else.
Got a remote team? See for yourself. Select a few requirements to inspect. Are they clear and effective? Do they convey the outcome required? Report back and tell me what you find (nb. ask if you need some help when assessing the requirements, I’ve got a standard approach I can send you).
Low-quality requirements should be no surprise, but the exploration shouldn’t stop there. Enquire who produces the requirements (nb. almost always the client), and if by chance, similar requirements have been used previously by local developers that performed just ‘fine’. Does this resonate with your own situation?
What is happening is the remote team’s performance is more a reflection of, well, the practicality of remote development in a context of fairly poor guidance (aka ‘requirements’). Which, many forget, is very different from local development in a context of fairly poor guidance.
Are the ‘broken features, slow delivery and tech debt’ really down to ‘poor quality developers’, or are we simply seeing the consequences of a team working remotely?
Physically separate and isolated, difficulty hustling answers in real-time, waiting on emails, language barriers, feature factory expectations, low pay and sometimes questionable conditions, developers unsure whether it’s actually ok to ask questions. These are things a local development team would never face.
Developers struggle when the people who can answer questions are not readily accessible or available. Remote developers struggle even more, which is why I have plenty of sympathy for them. Perhaps we should thank the remote team for highlighting the need for improvement, rather than unfairly blaming them.
Improving the software requirements is the solution, and it almost always delivers immediate results. It’s also usually easier and less costly than you may think. Sometimes, nothing further is required.
If you are unhappy with your development team, they may need more detailed guidance.
Better software requirements can help with this.
|
Frank Ray Consulting. Software requirements for agile development teams, particularly remote, outsourced and offshore development teams working in financial services. |