Challenges of switching an established external dev team [closed]

Question

Context

This is related to a question I asked regarding the challenges of a small company working with an external dev team which had some great feedback. For context, I am a PO of a small company in the UK which have an externally based dev team. I have heard horror stories from other businesses at various events when changing dev teams, with the majority of them saying to avoid it at all cost. There seemed to be a running pattern of external dev teams making it as difficult as possible for them to go elsewhere.

Question

I am not currently in a position where we are searching for another dev team but I wondered what the challenges might be when making the move to switch from an established external dev team to another team in the future (maybe an in house team or another external dev team) if it is deemed necessary? Are there any recommended fail safe procedures that can be put in place early doors to smooth it if it was to ever happen?

Answer 1

On the engineering side some of the things that help with team changes include:

• Living documentation - i.e. continually updated and used to ensure it is still useful
• Good regression test coverage - ensuring that people who are new to the code are confident enough to make changes
• Avoid accumulating technical debt - this will be harder for new people to deal with

Techniques like Behaviour Driven Development (BDD) are also really good at building maintainable code that can pass between teams.

Answer 2

There is no such thing as a "fail-safe." Everyone is replaceable. All the time. In every circumstance. I answer that in an absolute way because our history shows that everyone has been replaced and/or will be replaced. What you need to examine is the benefits of replacing a person or team with its associated costs and risks and choose the alternate path that yields the best benefit/cost-risk ratio.

The first thing you need to examine is whether you have a single point of failure with the team. Have you enabled an organization where, if the team is removed and replaced, the impacts are so adverse that recovery is long and painful? If your organization is like this, then you have already failed on a business capability principle and risk management. It is not really about you choosing to remove/replace the team but more about what happens if the team disappears overnight - the "airplane crash" type of scenario. If your organization is resilient, you would have the capabilities in place to recover and continue with minimal disruption.

Therefore, if you had those capabilities in place, replacing your team for whatever reason would be enabled. Enablers are redundancy, clear documentation (as barnaby wrote in another answer), cross training, a bench, and a healthy attrition rate to name a few.