Why are teams twelve times faster?

In my writing about team effectiveness, and in other prominent places too, something like the following quote might appear:

How bad is backlog coupling? At an Australian telecommunications company, my colleagues did a study of hundreds of pieces of work or tasks passing through a delivery centre. Some tasks could be completed by a single team without dependency, specifically without scheduling work by members of another team. The tasks that had to wait for another team were 10-12x slower in elapsed time. So dependencies have a real significant impact.

I should have published something at the time, but I’ll own up to being that colleague and share a little more about the study here.

Context

A number of us from Thoughtworks were helping a delivery group of 100-150 people with agile transformation. This group was previously organised along functional lines, and waterfall projects would request fractional FTEs from functional pools. One day, some brave leaders reorganised wholesale into about one dozen multidisciplinary teams, designed for end-to-end feature delivery, with a mandate to deliver early and often. I was embedded in one of these teams. Much of their work cycled quickly, but we noticed that things that depended on other teams got stuck in the “waiting” column for quite some time.

Data collection

Workflow

The team’s workflow, managed with a physical card wall kept in sync with a Mingle digital twin, was very simple:

To do
Doing
Waiting (on another team)
Done

Items could move from doing to waiting and back multiple times.

Mingle transition recording

Mingle was a very flexible tool, and it was possible to set a custom card property each time the card changed between certain states. Thus we could record the date when a card first went into doing, whenever it went into waiting, whenever it came out of waiting, and when it was done. The data looked something like this:

Card ID	Started	Last entered waiting	Last exited waiting	Finished
1	YYYYMMDD	<invalid> or YYYYMMDD	<invalid> or YYYYMMDD	YYYYMMDD
…
180

Analysis

From the data collected, we could also derive the following:

Card ID	External Dependency	Lead time	Last waiting cycle time	Other features
	If waiting dates set	Days between started and finished	Days between last entered and exited waiting	Any other property of card from ID
123	Y/N	42	7	XL

The major findings were:

Approximately 1/6 of cards had an external dependency; the remaining 5/6 stayed within the team
The median lead time for cards with external dependencies was 23 days, vs median 2 days for cards that stayed within the team (this is where the 12x figure comes from)
The median last wait cycle was about 6 days IIRC
The distribution for cards with external dependencies had a fat, spiky tail, while the cards that stayed within the team had an orderly, thin tail
External dependency wasn’t strongly correlated with any other card properties, like estimated size, and analysing lead time against any other card property didn’t show such stark differences as external dependency (or even any significant difference)

Impacts and actions

It was acknowledged that external dependencies had a very significant impact on delivery responsiveness. In particular that delivery forecasts required on a weekly schedule for any cards that had gone into waiting were a guessing game at best, without targeted intervention. Unsurprisingly, these were often critical to overall program delivery.

This provided impetus, among other analyses, for subsequent reorganisation into clustered “superteams” to ensure the impact of dependencies on delivery lead time was minimised.

We were invited back by the client about 4 years later on the 100th fortnightly delivery iteration of their agile operating model (and something like the 14,000th Mingle card). It was a testament to their willingness to embrace and continually adapt new ways of working, in the true spirit of agile.