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.
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 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.
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
- Individual productivity
- Organisational productivity (not the same as either individual or team productivity)
