The Size and Performance of Agile Teams

In discussions around Agile team sizes, conventional wisdom holds that teams should be made up of seven, plus or minus two people.

The Scrum Guide, developed by the co-creators of Scrum, Jeff Sutherland and Ken Schwaber, actually advocates for a number between three and nine. Three people may seem absurdly small, but more than once, I’ve worked with high-producing scrum teams made up of exactly three people.

Here’s the guide’s take (page six, for those of you with your PDF’s handy):

Fewer than three Development Team members decrease interaction and results in smaller productivity gains. Smaller Development Teams may encounter skill constraints during the Sprint, causing the Development Team to be unable to deliver a potentially releasable Increment. Having more than nine members requires too much coordination. Large Development Teams generate too much complexity for an empirical process to manage.

Amazon’s Jeff Bezos advocates for what he calls “the two pizza rule,” which asserts, simply, that you should be able to feed your team with two pizzas. I was able to eat a whole pizza in college, which could have thrown things off, but the premise makes sense.

So where do these numbers come from? Many in the Agile community will refer to Miller’s “magic number,” although this is a misapplication of Miller’s term; and, it’s not really the concept he was trying to illustrate (and in Scrum, it’s not even the same range).

In Fred Brooks’ “The Mythical Man Month” (if you haven’t read it, go read it right now), Brooks writes:

If each part of the task must be separately coordinated with each other part, the effort increases as n(n–1)/2. Three workers require three times as much pairwise intercommunication as two; four require six times as much as two.

In Brooks’ math, where n is the number of persons on a team, a team of one (let’s call her Alice) only needs to communicate with herself. This is easy for any self-actualized person (though self-actualized persons may be, in and of themselves, a rarity).

Now let’s say Alice is on a team of three. Alice now has to communicate with two other people (Brian and Chris) who each have to communicate with two people (including Alice). You can map their communication by drawing a line from each person on the team to each other person on the team. Their communications network looks like this:

Team_of_3 (2)

Three people, three lines, three possible (and necessary) vectors of communication. Simple.

Ramp it up to five. Each person has to communicate with four other people. Their new communication network looks like this:Copy of Team_of_5

If you are counting, there are now ten possible communication channels in this team’s network.

Now let’s do 8. That’s 7 connections per person. Since connections go both ways, it’s 28 lines total.Copy of Copy of Team_of_8 (1)

What happens in a team of ten? Forty-five possible lines of communication in the team’s network. To quote The Scrum Guide again:

Having more than nine members requires too much coordination. Large Development Teams generate too much complexity for an empirical process to manage.

Often, I see organizations pushing for teams larger than this. Sometimes, it’s because they don’t have sufficient budget or human capital to scale their product ownership resources to accommodate more teams. (This causes problems that we’ll address in a later article.) Other times, management assumes that more people = more productivity (which seems reasonable, on its face). Other times, it’s an innocent matter of trying to make sure good people have good projects or teams to work on, whether those teams need more people or not.

In the mid 2000s, QSM published a study, oft-cited by members of the Agile community, which examines the effects of team size on schedule and productivity. In studying nearly 500 projects, their observations feel intuitive to anyone who’s ever worked on large projects. Yet the solutions to the problems they highlight still run counter to accepted wisdom in most organizations.

Firstly, the team found that productivity per person drops as team size grows, with a sharp drop after the team crosses into the 9- to 11-person range.

From Brooks’ math, we know that a 9-person team’s communication network is significantly more complex than an 8-person team’s network (36 channels of communication vs. 28). The 9-person team assumes almost 30% more communication overhead, simply by adding one person to its roster. This scales similarly in both directions.

Further, they found that projects with teams of 9 to 11 take nearly 2.5 times the effort, as measured in person-months, than project teams of 5 to 7 (167 vs. 69 person-months, respectively). Of course, much of that effort can be parallelized; so the projects, on average, take approximately 40% longer to deliver.

In all, they found that individuals worked most efficiently on teams of 3 to 5, but teams of 5 to 7 people were able to deliver projects slightly faster. Whether the faster delivery justifies the extra headcount is highly situational.

So why are smaller teams more effective?  In addition to the problems with communication overhead that arise in larger groups, we’ll take a look at the Ringelmann effect.

Ringelmann (1913) found that having group members work together on a task (e.g., pulling a rope) actually results in significantly less effort than when individual members are acting alone. Furthermore, Ringelmann discovered that as more and more people are added to a group, the group often becomes increasingly inefficient, ultimately violating the notion that group effort and team participation reliably leads to increased effort on behalf of the members.

Maximilien Ringelmann proved that, as teams grow, individual contribution shrinks, caused by lack of motivation and loss of coordination. One possible cause of coordination loss may be accounted for by network overhead, but on a task like rope pulling, there isn’t much to communicate. Agile methods try to fix the motivation problem by involving people in the reasoning behind their work, though this could be an article unto itself. We mitigate the loss of coordination simply by limiting the number of things we need to coordinate: tasks, user stories, and in particular, people.

On paper, the corroborating evidence in support of keeping teams small seems pretty overwhelming. Yet organizations who endeavor to design the structure of their Agile teams (which may be, in and of itself, problematic for self-organization), will frequently over-staff teams, and as project importance increases, so does the probability of making such a miscalculation and often the probability of failure.

Leaders, Teams, and Agilists alike should understand the cost and benefits of scale. But for anyone who’s ever seen a small team become hyperproductive, it’s not even a discussion worth having.

Agile for Executives: Using the daily standup meeting as a C-Suite tool

Recently, the Harvard Business Review did a featured set of articles on the practice of agile. Initially created as a better framework for building software, agile has begun finding its way into business functions — today you see it in use across marketing, operations, and even sales teams. Senior executives looking to improve communication amongst their leadership team, remove organizational silos, and increase their organization’s velocity, should strongly consider taking a look at agile processes.

One specific example of an agile tool that works well with senior leaders: the daily standup, also known as “the daily huddle.” The daily huddle gives busy senior executives a common time and place to discuss issues, challenges, and team activities. The ultimate goal is to identify blockers between organizations and find ways to quickly and effectively mitigate them.

How it works: A dedicated time is set on the calendar for 15 minutes per day for the leadership team to get together. Each team member makes every effort to attend at the time; the meeting is not rescheduled or moved if individuals can’t make it. In the busy world of executive travel, it is ok for team members to skip if needed. During the meeting, each team member answers 3 simple questions:

  • What are the highlights from your organization yesterday?
  • What is underway today?
  • What blockers are being raised that could be addressed?

Here are the 4 keys to making an executive huddle successful:

  • Educate, educate, educate: It may seem like a simple 15-minute meeting, however, the more you educate and coach the team on the goals and structure of the meeting, the better it will perform. If the CEO has an impression that the meeting is just time for them to provide a general update, the meeting will not be successful. Instead, educate the team on how to best run the daily huddle.
  • Commit to 15 minutes and stick to it: The meeting should be short and sweet. It should not seem like a chore or just another calendar meeting.
  • Use an independent and trained agile coach to implement the meeting: Don’t go it alone, executive time is too valuable. To get the maximum value out of the meeting, bring on an executive agile coach for a short period of time to get going.
  • Don’t make it a strategy meeting: The meeting is intended to help department heads serve as servant leaders and address issues that their teams may have. Strategy meetings should continue to remain separate.

 

Blogging 101: 5 Things Every New Blogger Should Know

So, you want to start writing a blog? Ok, great! What now?

Getting a blog going can be incredibly exciting. It’s a constructive way to express your thoughts and share them with anyone who wants to read them. It can also be a bit overwhelming, especially for bloggers who have never actually done it before. Here are 5 important things to keep in mind as you get started:

  1. Write the way you speak.

Keeping it conversational can help you connect better with your readers. When things are a little more loose and relaxed, your blog is an easier read, and it can also help break down some of your more specialized topics into ideas that everyone can digest.

  1. Find your niche.

It’s important to find blog topics that will resonate with your target audience. There are millions of blogs out there. The only way to stand out from the pack is to find something specific that you’re passionate about, and write about the most interesting aspects of that topic. You’re not going to be loved by everyone, but that’s not realistic. The main goal is to appeal to those folks who have an interest in what you’re writing about, and keep them coming back for more.

  1. Research, research, research.

It’s not just about the writing… reading is just as important. Even with a topic that’s in your wheelhouse, you still need cited facts to back you up. There’s always more information out there that can give your blog a little something extra. Linking to articles where you found quotes, statistics or data to support your point will go a long way toward establishing the kind of credibility that you crave.

  1. Share and share alike.

Whether you love it or loathe it, social media is going to be a driving force behind marketing yourself and your blog. Share links to your writings on Facebook, Twitter, LinkedIn and any other place that will push traffic to your site. You’re starting from scratch, so it will likely take a little while before the readers are coming in droves, but social media is always one of the best ways to get noticed.

  1. Keep at it.

You’re new at this, so try not to get discouraged, especially early on. Gaining a following will take time, so be patient. Make an editorial calendar, so that you know what topics you’ll be covering and when you’ll be tackling them. It’s important to generate content on a regular basis, with whatever frequency you chose to post. If you don’t like the direction things are heading with a particular topic, change gears to something that suits you better. Trial and error is just part of the process.