Your team is not slow. The work needs too many people.

Take the last change your team shipped. Ignore the code. Follow the route.

A product decision. A schema review from a team in another department. A security check. A platform ticket for a configuration change the team is not allowed to make. A legal sign-off, because one field turned out to be personal data. A vendor contact who answers on Thursdays. A release slot.

The work was small. The route was not.

The board shows the item in progress. The standup shows everyone busy. Nobody can name a blocker, because nothing is blocked in the way the board understands blocking. The item is waiting for the next person on its list.

Then the team gets the improvement plan. Better estimates. Better refinement. More discipline in the daily.

None of that shortens the route.

Count who the work has to recruit

A study of modification requests in a large distributed software organization compared work split across sites with comparable work done in one place (Herbsleb & Mockus, 2003). The split work took much longer. The interesting part is why. Distributed items pulled in more people, and the number of people involved tracked closely with how long an item took to close.

That study is old. The tooling it describes belongs to an earlier era of email, phone calls, and shared repositories. Treat it as evidence about a mechanism, not as a verdict on distributed teams or remote work. Every additional person a change has to recruit is another calendar, another queue, another chance for the item to sit still.

Call that the coordination footprint of a work item. How many distinct people and groups had to act before it was done.

The board does not show this. It shows status and assignee. The route stays invisible.

Copying more people in is not coordinating

Across two large projects, researchers separated two things that get confused in practice (Cataldo & Herbsleb, 2013). Work has coordination requirements, created by technical and task dependencies. Actual coordination either matches those requirements or misses them. Where the match was poor, they found more software failures. Where it was good, productivity looked better.

This is observational work, so read it as a pattern rather than a proven cause. It still cuts against a habit you will recognize. A change does not become safer because six more names are on the ticket. It becomes safer when the people who own the actual dependency talk to each other about it.

That is how a long approval list and a broken handoff end up living in the same process.

Kula et al. (2022) combined practitioner surveys at a large bank with repository data from its delivery teams. Requirements refinement, task dependencies, organizational alignment, and organizational politics all showed up as factors people tied to delivery. Project size, dependency count, past delivery performance, and team familiarity helped explain schedule deviation. This is one enterprise, so do not read the specifics as universal. The direction is still useful. When work lands late, look at the dependencies and the organizational setup before you look at the estimate.

Do not turn this into a score

Flournoy et al. (2025) analyzed a very large set of cycle time observations across hundreds of organizations, using a model that keeps variation between individuals and between organizations visible. Collaboration factors showed real but modest associations with cycle time. Most of the variation stayed unexplained, both across people and within the same person over time.

Read that as a warning about your own dashboard. A "people touched" number will not predict cycle time, and it will not rank teams honestly. Put it on a scorecard and it will be gamed. The easiest way to game it is to cut the reviewer the work actually needed.

Use the footprint to find specific items worth investigating. Not to grade anyone.

Trace twenty finished items

Pull the last twenty completed items from one product or service. Not the slow ones. All twenty.

For each item, write down:

• elapsed time from start to done

• distinct people who took an action

• distinct teams or groups involved

• external waits, and how long each one sat

• handoffs that came back for clarification or rework

• whether the required group was known at intake or discovered later

• whether one person stayed accountable across every boundary

Plot elapsed time against the number of groups touched. Twenty items prove nothing statistically. You are not testing a hypothesis. You are picking the three slowest items to walk through with the people who worked them.

For each external touch on those three, decide which of five things it is:

• remove: nobody needs it any more, it survived the last reorg

• embed: give the team the capability or the decision right

• automate: make the evidence or the check self-service

• prepare: pull the group in at intake instead of at week three

• protect: keep it, because the risk is real

Prepare is the cheapest of the five to test. Nothing gets removed and no capability moves. The group was always going to be needed. It just found out too late.

Then change one thing and watch four weeks of finished work. Compare the wait ages, how often items crossed back for rework, and the spread of cycle time. If nothing moves, you removed the wrong touch, and you now know more about the route than the board ever showed you.

References

Cataldo, M., & Herbsleb, J. D. (2013). Coordination breakdowns and their impact on development productivity and software failures. IEEE Transactions on Software Engineering, 39(3), 343–360. https://doi.org/10.1109/TSE.2012.32

Flournoy, J. C., Lee, C. S., Wu, M., & Hicks, C. M. (2025). No silver bullets: Why understanding software cycle time is messy, not magic. Empirical Software Engineering, 30(6), Article 174. https://doi.org/10.1007/s10664-025-10735-w

Herbsleb, J. D., & Mockus, A. (2003). An empirical study of speed and communication in globally distributed software development. IEEE Transactions on Software Engineering, 29(6), 481–494. https://doi.org/10.1109/TSE.2003.1205177

Kula, E., Greuter, E., van Deursen, A., & Gousios, G. (2022). Factors affecting on-time delivery in large-scale agile software development. IEEE Transactions on Software Engineering, 48(9), 3573–3592. https://doi.org/10.1109/TSE.2021.3101192