2 Fs for team productivity: Flow and Frequent Integration

Jason Yip
4 min readDec 31, 2020

--

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.

  • Optimise for flow by 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.

Team bottlenecked, add initiatives to increase utilisation of team members

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.

4 people in a sequential process with the 3rd person overloaded as the bottleneck and the 4th person with nothing to do. “Everyone is busy, why aren’t we finishing faster? Must be the lazy person at the end.”
Adding more work to a team without addressing bottlenecks will not improve team productivity

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;
Use non-experts to free up experts to focus on bottlenecks
Even non-experts should help, if they can, at bottlenecks

It is actually better for other team members to do nothing rather than to interrupt the bottleneck to try to keep themselves 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.

Split up initiatives and prioritise the valuable parts first to further optimise completion times

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.

A serial approach is prone to bottlenecks; a parallel approach requires integration

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.

Delaying integration until the end leads to “integration hell”

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

Frequent integration means 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.

Divide and conquer contributes to “integration hell”

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.

Instead of “divide and conquer”, “conquer and divide”

This approach is called Conquer and Divide.

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

See also

--

--

Jason Yip

Senior Manager Product Engineering at Grainger. Extreme Programming, Agile, Lean guy. Ex-Spotify, ex-ThoughtWorks, ex-CruiseControl