Last week, we discussed the challenges small teams face and how to best deal with them. On the other end of the spectrum, large teams suffer from a different set of challenges, so the large team Agile best practices differ.
Some of the most common issues for large teams include:
Communication Complexity: As team size increases, communication channels grow exponentially, making information dissemination more time-consuming and less effective. Miscommunications and misunderstandings are more likely to occur, and ensuring everyone is on the same page becomes increasingly difficult.
Coordination Overhead: Larger teams require more effort to coordinate. Organizing meetings, making decisions, and managing dependencies can become cumbersome and inefficient. More time and energy are spent on managing the team dynamics and less on the actual work, which can delay delivery.
Reduced Individual Engagement: In larger groups, individual contributions might become less visible, leading to decreased accountability and potentially reducing the level of engagement and responsibility team members feel. This phenomenon is sometimes referred to as “social loafing.”
Slower Decision-Making: The decision-making process tends to slow down with larger teams due to the increased need for consensus-building. More people will want to voice their opinions, and reaching a mutual agreement becomes more time-consuming.
Dilution of Shared Understanding: Maintaining a consistent, shared vision and understanding of the project goals, strategies, and ongoing tasks is more challenging as team size increases. Disparities in knowledge, understanding, and focus can lead to inconsistencies in the development process.
Increased Risk of Groupthink: Larger teams are more prone to groupthink, a psychological phenomenon where the desire for conformity leads to irrational decision-making. People may feel pressured to agree with the dominant viewpoint, suppressing innovative ideas or critical thought.
Less Flexibility and Responsiveness: Agility requires the ability to quickly respond to change, which becomes increasingly difficult with larger teams. Bigger groups tend to be less flexible and slower to react to new information, customer feedback, or changes in market conditions.
Resource Management Issues: It’s harder to efficiently allocate work in large teams, as there might be an imbalance in workloads, with some members being underutilized while others might be overburdened.
Definitions:
Ideal team size: The ideal size for a Scrum team is often cited as between 3 and 9 members, excluding the Scrum Master and Product Owner. This recommendation comes from the Scrum Guide, the foundational text for Scrum written by Jeff Sutherland and Ken Schwaber. A team of this size is optimal because it reduces communication complexity and increases cohesiveness, efficiency, and agility. It allows the work to be distributed across enough skill sets without becoming so many it’s hard to manage.
Two-pizza team concept: The “two-pizza team” was popularized by Jeff Bezos, the founder of Amazon, which posits that a team should be small enough to be fed with two pizzas. This idea emphasizes the importance of small units for boosting productivity and communication. The two-pizza team concept hinges on the principle that smaller teams are more efficient due to simplified communication and decision-making processes. With fewer people, teams can avoid bureaucracies and communication mishaps that often plague larger groups. This small size encourages a more intimate atmosphere, allowing everyone to have a voice and contribute actively to foster a more agile, responsive, and collaborative working environment. In essence, if a team is too large to share two pizzas, it’s considered less effective because it may suffer from reduced productivity simply due to its size.
Self-Organizing Team: Refers to a group of individuals who manage their own work and make their own decisions about how to achieve their goals rather than being directed by managers or following a prescribed plan. These teams are given the autonomy to decide how best to accomplish the work within the constraints provided by the broader organization or framework. The key characteristics of a self-organizing team are autonomy, collaboration, cross-functionality, responsibility, continuous improvement, empowerment, and feedback. In Agile frameworks, the belief is that empowered and trusted self-organizing teams can be more adaptive, responsive, and innovative when solving complex problems compared to traditionally managed teams. This is because they can leverage the collective intelligence, skills, and insights of all team members, making decisions that closely align with the ground realities of the team and organization.
Psychological Safety: Refers to a shared belief within a team that it is safe for members to take interpersonal risks and communicate openly and honestly. Leaders and facilitators in Agile environments often work to nurture psychological safety by encouraging respectful communication, showing empathy, appreciating diverse viewpoints, and creating a blame-free culture. This effort significantly contributes to a team’s ability to thrive, innovate, and adapt in fast-paced and ever-changing environments.
Going from Suck to Awesome
Suck – Not knowing who is on your team and what roles they play.
Still sucks – Knowing who is on your team but having so many members, it isn’t clear who does what.
Sucks a little less – Everyone knows their roles, but the process feels sluggish and cumbersome because there are so many people to reign in.
Awesome – A team with the ideal number of members and clearly defined team members and roles.
Large Team Agile Best Practices
There are several techniques for handling large teams, which bring with them unique challenges and constraints, especially when you are applying Agile. Another way to state the issue: When a team is too big, what options do you have if you don’t have enough people to create two teams with a balanced distribution?
Approaches for Reducing Team Size
One approach is to reduce the size of the team. If other teams in the organization don’t have enough members, they may welcome one of your team members to create two groups with more optimal numbers.
Another option is to temporarily lend one of your members to another team. Cross-pollination between teams has several advantages. For instance, mindfully moving members between teams can create greater consistency across the teams.
Although not required consistently, when organically cultivated, this option makes all sorts of department-wide or company-wide operations easier. For example, if all the teams estimate their stories with approximately the same values, planning across all the teams is easier.
As you review your large team, confirm all the members are getting value from the process. Sometimes teams are very inclusive, and they pull in everyone. That sounds great, but I have seen many with members who were not involved in the day-to-day work of the team. Examine team participation to determine if everyone is either getting value or adding value. If an individual is doing neither, they may not belong on that team.
Be careful, as sometimes certain team members are either unfamiliar with the Agile process or are generally more reserved. Before assuming a team member is not participating because they have nothing to add, meet with them, the Scrum Master, and the Product Owner to evaluate their team membership.
If, by some chance, executives are participating on your team, I would recommend removing them. It is very difficult to manage executives, and unfortunately, they may inadvertently reduce psychological safety.
When tallying up who is on the team, don’t count Agile Coaches. Coaches of any sort typically don’t participate in the work being performed. Even if coaches are participating in the ceremonies, it is usually as a conversation starter or part of team training.
A Team Within a Team / Proxy
Although the best teams are cross-functional, having a single person represent or proxy a group of individuals is possible.
For example, if your team includes dedicated security experts because your project has exposed numerous threats, it may be possible to have a single security representative participate on your team. That person may frequently consult or leverage other individuals concerning security.
The question to answer is: does the team need more than one security expert on the team, or can a single person represent that specific domain knowledge?
Again, this approach comes with risks. For instance, the people being proxied who are not formally part of the team may be missing a lot of context.
Additionally, it could orphan individuals in such a way that they aren’t part of any team.
Being part of a team isn’t just good for the team; it also helps individuals with career growth, a sense of belonging, and overall job satisfaction.
When to Split into Multiple Teams
If you have a team with 18 members, it should be easy to divide the team. Most issues occur when you have between 10 and 16 members.
Here are a couple of items to consider when approaching the issue of splitting a large team into two smaller groups:
How will you handle unique skill sets?
Who will be the Product Owner and Scrum Master for each team?
Will you create one great team and one weak team because the second team is too small?
Will you create two weak teams because they are both too small?
Once two teams are formed, how will the work between the teams be coordinated?
So, when does it make sense to divide a team into two teams? Here are some common triggers:
If you have more than ten people on a single team.
If the type of work is different. For example, is the work relevant to everyone, or does the work feel like it can be broken down into two separate groups?
Is there enough duplication within the roles? For instance, it is easier to split a development team if several people are mobile developers and back-end developers. This way, the new teams will have at least one of each skill set.
If the work can be completed by multiple groups without many dependencies between the groups.
There are communication breakdowns, delayed decision-making, and overcomplicated coordination.
The team is having a hard time staying cohesive.
As an approach to dividing teams, I recommend having the Product Owners and Scrum Masters work for both teams and then divide the team of developers. If the new teams stick, additional Product Owners and Scrum Masters can be hired.
Instead of having a single large team break into two smaller teams, having multiple teams slightly reduce their member count and collectively form a new unit may be possible. For example, three large teams could each part with one or two team members to form an additional small team with balanced roles. This approach may yield better results because it considers the organization rather than a single group.
One team that needs to be reduced by several members may act as the catalyst, but reducing the size of several teams could help rebalance team structure across the organization.
Ceremony Optimizations for Large Teams
With large teams, some of the ceremonies can start to consume valuable time. The first and most important step is to ensure you are running effective and efficient meetings.
If standups are keeping to the standard “What you did,” “What you are going to do,” and “impediments,” it shouldn’t matter if there are a couple of extra people in the ceremonies. Maybe the meeting goes 16 minutes instead of 15. Other meetings, such as planning, may be more difficult to optimize.
Here are some suggestions for each of the typical ceremonies:
Standups
Have a predefined speaking order for members. For instance, if you are meeting physically, go around the room, left to right. If you are meeting virtually, then follow the same order each time. Have the order visible to everyone.
Set a policy of starting the meeting exactly when it is supposed to start. If you wait around 5 minutes for a 15-minute session to start, you have wasted considerable time!
If you are meeting physically, if possible, stand up. You will be surprised how standing helps people stay focused and makes meetings more efficient.
Use a tool to guide you through the board. This way everyone can see as well as hear what the person is working on.
Wait to cover additional topics and conversations until the end of the meeting. If the information isn’t relevant to everyone, let people know explicitly that they don’t have to remain on the call/in the meeting longer than necessary.
Retrospectives
Set goals for the retrospective up front.
Have a predefined format ready for everyone. It is fine to rotate formats, but have whichever format prepared to go before the meeting starts. An example/suggestion is to use a virtual notepad (like Trello) where team members can fill in their feedback before the meeting. Then, use the meeting time only to discuss feedback as opposed to writing things down.
Time box the meeting to a certain amount of time. Let everyone know the limits ahead of time, so nobody feels like they aren’t being heard or are being cut off.
Stay positive and constructive. Non-constructive arguments can waste a lot of time. The idea is to bring areas of improvement to the surface. If there is a deeper issue between certain team members or one team member, in particular, has negative feedback they continue to come back to, the Scrum Master and the necessary people should discuss the issues privately, using it as an opportunity for coaching.
Planning
Planning is the hardest for meeting with large groups. Hopefully, a larger team is doing more work for each Sprint, which typically means more planning is required.
Be prepared. Product Owners should have the backlog refined and prioritized before the meeting. If there is no Product Owner for a team, then each person should have their items ready to review.
Proper facilitation. Planning is probably the longest ceremony of all. Some items may require a lot of conversation. If it appears an item will consume more time than normal, it may make sense to defer the item until later and have a team member reduce the uncertainties, dependencies, or whatever is driving the conversation to take so long.
Have a definition of Done ready, so the team has an aligned version of what is required to plan a story.
Demonstrations
Have a predefined format of how presentations are performed. Keep the structure consistent, so everyone understands it and how their work fits in.
Each participant should be ready to present. I have had great success with very large audiences when each team member is prepared to present. In the case of one team, each person had their browser window loaded and ready to go. They took turns presenting, so there was very little cutover time, and a lot of material could be demonstrated very quickly.
Don’t present too much. Quickly tell what the point of the story was (the why) and get right to what was done. Have set-up data ready and entered. If a stakeholder wants more information, they can ask for it.
Conclusion
First, although there are guidelines for team sizes, every company and team is different. There are no hard and fast rules. Sometimes having 12 people on a team is too many; other times, it is what is required.
Teams should be self-organizing and should continue to optimize. A couple of times a year, reexamine the size of the team to see if it’s too large and consider your options. Mature teams may independently suggest a change because they will know firsthand when their team has grown too large.
Working with the team will probably yield the best results because they can be part of the solution. Remember, great Agile teams are continuously improving and adjusting, and team size is just another adjustment the team may have to make.
Kommentare