Team productivity is about “flow over utilisation” and integration

Some individual productivity practices translate well to team productivity

Team productivity has factors that overlap with individual productivity:

  • Increasing focus, by reducing multi-tasking and interruption;
  • Frequent customer feedback, via regular demos, user testing, releasing to early adopters, etc.;
  • Reducing friction. For teams, this is typically around lack of clarity of direction, lack of agreement on how to work together, clunky tooling and/or technology, etc.

However, team productivity goes beyond just a translation of individual productivity practices.

  • Watching the work product, not the workers;
  • Frequent integration

Watch the work product, not the workers

Let’s imagine that you optimise for team member utilisation, that is, team members should spend most of their time on value-adding activities, especially activities associated with each person’s particular specialties so as not to waste their individual talents.

This sounds very reasonable and is guaranteed to slow completion times.

Let’s imagine a team working on a single initiative that is bottlenecked on a single team member who is extremely busy while everyone else on the team doesn’t have much to do.

If you’re optimising for team member utilisation, you should add more initiatives to the team. This won’t create any improvement in how fast initiatives are completed because the team is still constrained by the bottleneck. In fact, it’s more likely that it will make things slower given increased psychological pressure and interruption to the bottleneck team member.

Instead, if you optimise for the flow of work, you should NOT add more initiatives to keep people occupied, but rather people should help out on the bottleneck activity.

There are a couple ways to do this which I described in “Why T-shaped people”:

  • Offload non-expert tasks from the bottleneck;
  • Help out with the bottleneck activity even with partial ability;

It is actually better to do nothing than to interrupt the bottleneck to keep people busy. In practice, there are typically general improvement and/or learning activities that can be done rather than doing nothing.

See also the Five Focusing Steps from the Theory of Constraints.

Not every part of an initiative has the same level of priority

What if you broke up initiatives and prioritised the smaller parts? It may not be the case that every part of an initiative has the same importance. You may want to do this breakdown and sequence them to optimise the completion times of the different parts.

To address serial bottlenecks, parallelise the work; now you have both bottleneck AND integration problems.

A typical way to reduce the impact of serial bottleneck problems in product development is to parallelise. Instead of me waiting for you to finish before starting, we can each work independently and merge our work later. This need to integrate individual activities to create a coherent overall outcome is the biggest difference between individual and team-based work.

Without frequent integration, it feels productive to work independently… until integration hell hits at the end

Integrating and resolving integration issues feels like an interruption from an individual productivity perspective so there may be a belief that it would be more productive for the team to delay integration until after everyone is done their individual parts. This is an illusion that leads to what is commonly known as integration hell.

Instead, integrating frequently means that individual efforts never drift too far apart.

Mob Programming, where the whole team all works together on a single task, that is, not parallelising, is another way to avoid integration problems.

Make something integrated that works first, then divide up the work… and re-integrate frequently

Many integration issues come from a premature dividing of work. In order to get all the individuals going, we allocate out tasks before we really understand the essence of the problem, the target solution, and the appropriate interfaces. This can be mitigated with frequent integration but it’s unnecessarily messy.

Instead, it’s more productive to figure out and build an initial, integrated core together before splitting up to individual activities… and re-integrating frequently.

This approach is called Conquer and Divide.

See also John Cutler’s ideas about Starting and Finishing Together.

See also

Senior Agile Coach at Spotify, ex-ThoughtWorks, ex-CruiseControl

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store