In an Agile or classic context, we often find teams that exceed ten members. Frequently, these teams encounter difficulties in producing an optimal quantity of value, and in an efficient manner.
In most cases, maybe yours, this team suffers from obesity.
By that I mean that it is composed of too many members , which limits its performance.
I suggest that we see together how to diagnose the problem and cure your obesity to regain a healthy size and a performing dynamic!
The observation
In projects where the problem of a team that is too large is found, we can observe, among other things, the following elements:
• Too much capacity to handle the development needs on the product, exceeding the manageable limit
• The functional scope to be covered is extremely broad and becomes difficult to grasp
• The Product Backlog contains several products, reducing the focus
• Communication difficulties can lead to duplicated or unnecessary work
In these cases, one of the first reflexes is to add members to the team, thinking that adding one person will increase performance proportionally. This reflex is inherited from old methods and is no longer valid in most current environments. As time goes on, the size of the team is rarely revised downward, perpetuating the harmful symptoms.
Symptoms
To help you diagnose this problem in your team, it would be too easy to tell you:
“ Your team has more than 10 members, so it is too big ”
The problem is more complex than that. A team of 20 members can produce value with minimal loss while a team of 4 members can lose a lot of productivity unnecessarily.
“ The Scrum Team should be small enough to remain responsive and large enough to accomplish meaningful work during the Sprint, usually ten people at most .”
In this quote from the Scrum Guide 2020, we find the instruction giving the decision criteria for an optimal Scrum team size – also valid in a non-Agile context. Let's focus on the usual maximum size . It is in this last word that all the nuance lies. Since
no context is generalizable, we must therefore look into the question in more depth to determine if your team exceeds the maximum size that your context allows.
It is difficult, if not impossible, to apply the Scrum framework qualitatively in a large team context because it reduces transparency , makes inspection difficult , and makes adaptation laborious .
In this infographic, we illustrate the different communication channels between team members sweden telegram data You will notice that the more members there are in the team, the more communication channels there are to maintain. For a team of 3 people, we only have 3 communication channels and for a team of 7, 21 channels. We can also consider that a team of 20 people reaches 190 communication channels.
With so many channels to maintain, the benefits of collective intelligence are therefore reduced or even completely lost . For teams whose number of members exceeds the limit that it can support, the number of communication channels prevents the latter from being of quality.
A lot of time spent in meetings
Meetings should be useful moments where the team shares information and collaborates . But they can easily turn into inefficiency and therefore loss of value. That's why we will naturally seek to optimize this time.
There are several types of meetings to cite to illustrate my point:
• Presentation meetings : a briefing or presentation
• Sharing meetings : the Daily Scrum, where participants quickly share information
• Collaboration meetings : the Sprint Planning, Refinement or Sprint Retrospective.
These are sessions where participants must collaborate to produce one or more items.