Three steps to make distributed Teams work

Three steps to make distributed Teams work

As Agility in Mind launch our new training course designed to help distributed teams work effectively, we share our experiences on the reality of remote working.

Real life is about compromise
Designing an effective IT product delivery capability is a complex problem involving compromise. It will never match up to the perfect world described in the training course or the management book. The system you end up with is the result of multiple conscious or unconscious compromises, evaluated on the basis of benefits or drawbacks weighed up against the cost and difficultly of not compromising. One such compromise is the decision to surrender the ease of communication and collaboration that comes with co-located teams. Some examples of trade-offs we’ve seen from our clients in this scenario include the following:


  • Reduced operational costs.
  • Proximity to customers or internal business units.
  • Access to a wider range of people and specialist skills.
  • Time zones allowing “follow the sun” support.


  • Loss of spontaneous face-to-face communication.
  • Distance to customers or internal business units.
  • Time zones reducing time for whole-team collaboration.
  • Meaning can be lost when discussing requirements.
  • Difficulties and Costs in avoiding the need to compromise
  • Teams are already in place and would be highly disruptive to move.
  • Space is running out at the main site, putting pressure on desks.

Compromise is only effective with accountability
Crucial to making remote teams working effectively is to consider the whole picture and avoid optimizing isolated parts of the system. We’ve learned from our work with Scrum that having a product owner with both the autonomy and the accountability to make decisions leads to the best overall outcomes. When making decisions about an organization's software delivery capability, the best outcomes are likely to arise when decision making and accountability are not split across functions such as engineering, QA, facilities, and product management. The risk is that each specialism optimizes their output: providing the required headcount in development; the most cost-effective office space; leaving product management constrained in optimizing delivery. We’ve seen product managers unable to procure high quality video conferencing equipment as it would exceed the facilities budget; hiring decisions and team composition optimised to make line management easier; and many other examples where simplifying the reporting lines would lead to more compromise.


Print   Email