Practicing Agile with a Growing Team – Part 1: Individuals and Interactions

Our project teams usually fit into most people’s definition of a small team, even if you include key players from our client in the count. As a result, many of our default Agile practices are best suited to that smaller team size and need a few adaptations as team size grows.

On a recent project where we were joining an especially large client team, the combined project team started with about 10 people and grew to over 20 people. As you’d expect, that team growth started showing where the small-team practices would need to change.

In Part 1 of this series, I’ll focus on the first phase of the Agile Manifesto, the part that is most affected by team growth: Individuals and Interactions.

First, a Word about Team Size

Let’s consider a “small” team as no more than 10 people, roughly following Amazon’s two-pizza team rule that’s become so popular. That range fits my experience and represents the majority of Atomic project teams over our 18-year history.

Doubling that small size yields a good enough metric for my medium-sized team, 20 or so. Double that again, and you start getting into large-team territory—40+ people. That’s not what I’m going to be talking about here, because I haven’t worked on a team that large.

Here, I’m going to focus on the transition from a small to medium team size. This can be a tricky transition because of the gray area where the small-team practices might start to break down a little bit, but not obviously fail. By the time you get to a team of 40+ people, I imagine that some small-team practices are obvious non-starters (e.g., full-team stand-up meetings where everyone shares their plans for the day).

Individuals and Interactions

The Agile approach values individuals and interactions over process and tools. As team size increases, the number of relationships between team members increases non-linearly. For example, in a team of eight, there are 28 relationships that need to be maintained, while in a team of 16, there are 120 relationships. Assuming our team has 22 people, there are 231 relationships. This makes keeping up with the right interactions a challenge. And when the right interactions don’t happen, we don’t get the outcomes we need.

Some of the challenges we’ve observed include:

• Developers may make changes based on feedback from one team member who has reviewed a completed story, when the feedback really needs to be discussed with a designer and subject matter expert to determine a course of action.
• Members of the team may have different understandings of a requirement because different people have been part of different conversations or looked at different sources of documentation, but not discussed the issue directly with each other.
• There are surprises or disappointments when features are sent for review–usually the result of confusion about requirements I mentioned above.
• Developers are aware of the general timeframe for a desired release (next week), but not of the specific date (Tuesday) when the decision was made. This can cause some fear about getting stories completed in time.
• Team members feel left out of conversations and decisions that they care about.
• Large meetings get out of hand in all the usual ways: too many parallel conversations, some contributors squelch out others, or people have a sense of wasting time.
• A couple of developers discuss a detailed architecture for a series of stories, but then plans shift and someone involved in that conversation starts implementation without that knowledge.

Root causes

We decided to dig beneath the surface to look for patterns. We wanted to make sure we were treating the root causes and not just the symptoms of our problems. Some of the underlying causes we found included:

• Someone didn’t know who to talk to, which meant it took more work to initiate the right interaction, which in turn made it less likely to happen.
• Someone wasn’t comfortable initiating the right interaction. Team safety issues can happen in teams of any size, but they seem more likely on larger teams.
• A question went to multiple people, and nobody answered–the tragedy of the commons.
• Many people preferred to take action over always asking for permission. This can work well on small teams, but it can be at odds with a larger team’s need to distribute responsibilities. There are more toes to step on.
• Misalignment of expectations of who should be Responsible, Accountable, Consulted, or Informed (RACI) in various situations.
• Information wasn’t shared as widely as it should have been or in a durable enough format.

Improvements

Even with these issues, our team was far from dysfunctional. We were completing good work, but we knew it could be better. Below are some of the team practices we started or changed to improve the situation.

• Denote a single person to be responsible for recording disseminating information to any team members who were not part of a meeting, conversation, decision, etc.
• Write important dates in the team space and place them on the team digital calendar so they’re easily visible.
• Write more and make it accessible. Share written notes from meetings, capture the outcomes of discussions, and keep notes about stories with the stories. While we prefer to have just enough documentation, larger project teams often need more writing.
• Place a greater emphasis on very detailed requirements and implementation notes for every story. It takes more time and some trial and error to find the right balance, but for a larger team, it helps.
• Be in the same space to lower the barrier to interactions.
• On each story or epic, document which team members should be asked when clarifications are needed.
• Create time for the team to get to know each other.
• Employ more inclusive facilitation during meetings, allowing only one conversation at a time and knowing who’s likely to speak up quickly, and who’s not.
• Present information about ongoing planning, design, and research work to the developers to keep them aware of what work is coming up. We do this during sprint demo.
• Clarify responsibilities to avoid conflict and enable action: Who is Responsible, Accountable, Consulted, Informed (RACI) for different types of work, decisions, etc.?

If I had to distill all of this down to just a couple of points, a larger team requires a greater degree of general team trust, more clearly defined responsibilities and expectations, and a lot more durable communication (writing, audio, video) in order to function at its best.

Look for Part 2: Everything Else shortly.