Key Principle: Tighten Feedback Loops

ABOUT THIS CHAPTER   In more than 20 years of working with companies that have established geographically distributed development teams, we have seen only a small number of examples in which productivity was comparable to a team that was co-located. We have not seen any indication that geographically distributed Agile teams will ever be as effective as co-located teams. However, distributed teams are a fact of life for most large companies today, so this chapter describes how to make them work as well as possible.

One principle of effective software development is to tighten feedback loops as much as possible. Many of the details in this book can be inferred from that principle. Why do we want a Product Owner within the Agile team? To tighten the feedback loops related to requirements. Why do we use cross-functional teams? To tighten the feedback loop needed for decision making. Why do we define and deliver requirements in small batches? To tighten the feedback loop from requirements definition to executable, demonstrable software. Why do we perform test-first development? To tighten the feedback loop between code and test.

Tight feedback loops become all-the-more important when working in Cynefin’s Complex domain because the work cannot be mapped out in advance; it must be discovered through numerous $probe - sense - respond$ cycles. Those cycles are a type of feedback loop that should be as tight as possible.

Geographically distributed teams have the effect of loosening feedback loops. That slows decision-making increases error rates, increases rework, reduces throughput, and ultimately delays projects. Any communication that can’t occur face to face inserts more potential for miscommunication, which loosens the feedback loop. Time-zone differences insert delayed responses, which has the same effect. Work done in larger batches before being sent offshore, such as during the time an onshore Product Owner visits the offshore team to support face-to-face communication, again loosens the feedback loops. Add differences in language, national culture, site culture, and the timezone fatigue that accumulates from participating in remote meetings at awkward hours, and the feedback loop loosens, and mistakes increase even more.

We worked with a company at which the offshore team was significantly underperforming the onshore team. When we brought some of the offshore individuals onshore, their productivity increased dramatically for the short time they were working onshore, but it fell again when they returned home. This demonstrates that the performance problem was not because of the individuals involved—the communications gap and delays caused by 12,000 miles of separation made it impossible for the offshore team to perform effectively.

Loose feedback loops are the biggest problem I see with distributed teams. These appear in a number of forms, illustrated below, all of which I’m inclined to call classic mistakes:

• Development at one location; test at another

• Product ownership at one location; development at another

• Work on shared functionality that’s split 50/50 across two sites

None of these configurations work well—each creates a situation in which people who need to communicate with one another frequently are delayed in their communications.