More Effective Team With Less Efficient Workers!

Methods based on Agile and the Kanban Method both stimulate collaboration to achieve focus and flow. In practice this is often challenged by teams with specialists who have a tendency to maximize the utilization of the specialists.
So, is a team with a focus to finish work more effective than a team with focus on efficiently using expertise?

Cases

Imagine a team that realizes user stories, e.g. using Scrum. Before the stories can be built the team does refinement. A term coined for the team of engineers doing the preparation work is ‘ready team’.
Consider a team consisting of 2 analysts, three developers, and 2 test engineers. Three typical set-ups are often encountered in practice:

1. Ready Team. Team members are only allowed to work in ‘their’ own discipline, i.e. Analysts only analyze, Developers only develop, and Testers only do testing,
2. Half a Team. Analysts only analyze, Developers develop and help with analyzing, testing. Test engineers help with analysis and development,
3. One Team. Team members take all kinds of work.

The first case describes a ‘ready team’ that is in effect separate from the team actually realizing the stories. The third case is similar to a ‘virtual ready team’ in which the team collectively takes responsibility over both making the stories ready and realizing them.
The second case is somewhat in between the first and third case. An example is a Scrum team helping the Product Owner to write user stories, but the Product Owner does not do any work related to the Definition of Done.
This blog describes the results on team effectiveness and efficiency that we have gained from simulating these three cases.

Set-up

For the simulations we use a team consisting of three roles: 2 analysts, 3 developers, and 2 testers. All work flows though the columns ‘Ready’, ‘Analyzing’, ‘Developing’, ‘Testing’,’Ready for deployment’, ‘Deployed’. Work-in-progress is limited by setting them to the values 4, 2, 4, 3, ‘no limit’, ‘no limit’.
We will simulate one year of working by the team, i.e. the simulations run for 220 steps, or 220 project days which is approximately 1 calendar year.
For the purpose of this blog we define the team performance as the average cycle time, i.e. the average time it takes to complete a backlog item. The lower the average cycle time, the better the team performance.
Team members perform the most efficient in ‘their’ own expertise. When performing work in a different discipline, e.g. developers doing analyst’s work, their efficiency is by assumption only 50%.
We will also look at the team efficiency. During the simulation it is estimated how much effort the team members have performed during the day. This effort is applied to the work. Effort loss can happen in 2 cases:

• team members have effort left but no work item to work on,
• team members help in another role and are less efficient at what they do.

For the purpose of this blog we define the (team) efficiency as the ratio of the total effort applied and the total effort available.

Initial Results

The results are shown in the graph below.

 
 
 
 
 
 
 
 
 
 
The ‘Ready Team’ setup, i.e. a separate team refining the work, has a cycle time between 12 and 14 days. The other 2 set-ups where collaboration is stimulated have a short cycle time of around 9.5 days.
It is important to note that only the efficiencies are varied.
This result shows that by collaborating and helping each other to complete work items reduces cycle time. At the same time efficiency is reduced, but this is hardly an issue because the work is being achieved faster. Helping each other is less efficient for individual team members, but more effective for the team.
Next, we will have a look at the effect on the team’s throughput.

Further (Optimized) Results

Keeping WiP (Work in Progress) limits the same and moving to a collaborative team reduces the cycle time. The down side is that throughput also is reduced, i.e. the average number of work items completed over time is reduced. How come?
The reason is that we should also reduce the WiP limits. Reducing these limits to 1, 1, 2, 2, ‘no limit’, and ‘no limit’ we get the charts shown to the right.
The throughput distribution chart (the right-most) shows that the throughput is roughly 1 work item per day which is the same throughput as in the previous section (not shown).
The Cycle Time distribution chart shows that the average cycle time has dropped to 5 days. Efficiency (not shown) is around 70%.

Conclusion

The simulations show that cycle time is reduced (faster delivery times) while keeping throughput equal if:

• team members focus on finishing items by assisting each other, and
• at the same time reduce Work in Progress.

This works even when the efficiency of helping others is 50%!
So, based on these results, our recommendation for creating high-performing teams is to stimulate the formation of a team where team members focus on getting work done, helping each other whenever possible. A corollary is that we need to stimulate knowledge transfer between team members, since a prerequisite of team members helping each other is that they are actually able to help each other (meaning with an efficiency significantly higher than zero).