Agile Team Size

Using Agile methods with large teams is a reality - the old Agile = Small Team equation is no longer valid. Nonetheless, team size is still an issue. How important is team size and what, if anything, should we do about it?

An interesting discussion started on the ScrumDevelopmentList when one member suggested that team size should be anywhere between half a dozen to two dozen:

split the team - depending on the source, the recommended size seems to vary between half a dozen and two dozen team members.

Huh? In Scrum the recommended team size is 7 plus or minus 2. Isn't this a Scrum forum?

A conversation ensued regarding the definition of Scrum and team size. When the dust started to settle, Roy Morien commented and asked:

Scrum overcomes these problems to a considerable extent with it's emphasis, at least philosophically, on regular, but short, meetings, on collaborative actions, on 'information radiators' etc. But Scrum itself cannot fully overcome the problem of big teams. This matter goes back decades ... James Martin over 10 years ago talked about "SWAT" Teams (Specialists with Advanced Tools, if I recall correctly), which were of limited size ... 5 or 7 or so, but the emphasis on small, for effectiveness.

What seems to me to be a more rewarding and informative discussion is about the ability of agile methods, and agile project management methods, to 'scale up' to large teams, and large projects. Or, probably more to the point, the best team sizes, and the possibility of multiple teams, and the problems of multiple teams, if and when using agile methods.

So ... straight question(s) ... what is the optimal team size (regardless of any prescription by Scrum officianados)? Is Scrum able to scale up to be used by larger teams? How can Scrum principles and practices be applied in a multiple team environment? AND is there any research, experience, or anecdotal evidence and publications to support the answers?

The answer? [to the question How can small teams can deliver big projects?] Divide the big project into small independent projects. Nothing too shocking about that. But there is still a question about how to organise the work and structure the project. Earlier in the year I attended Spa 2007 where Dave Thomas outlined one approach.

The objective is to let projects have freedom to create the solutions to specific problems but to coordinate activity between projects. The approach is to structure the work into four phases:

When is it profitable for a team to grow? Do we really need big teams to handle big projects?

I deplore the fact that so many people measure the importance of a software project by the sole size of the team working on it.

Many members certainly imply more brainpower potential, but also a greater difficulty to realize this potential. Actually, I notice two common pitfalls for crowded teams, namely miscommunication and lack of motivation.

There is consensus that small teams are much more efficient and productive than large teams. But larger teams are still being used to cut more code because small teams lack the capacity to produce as much code - or do they?s

The approach is to structure the work into four phases: Envisioning; Definition; Development and; Release.

Haven't I seen a four phased approach before? IMHO, large projects require more of a UP approach. The larger your project gets, the more difficult it gets for small teams to see the big picture. Therefore a well (not necessarily over-) documented process is indispensible.

This is a trick question, asked by a department that had already hired programmers and assigned budget, and decided to go Agile after the fact.

The real question is: we have x high-value stories, initially estimated at y and the client needs this part of the project done by z. We need how many teams for the next 3 iterations?

The issue is that you can do this work two ways: throw everyone at it, and suffer massive ineffectiveness as a large team chews up time and energy trying to find ways to communicate; or start small, grow your teams as the requirements start to get fleshed out, and see if you can really do it with half the people.

Because, we've all seen it happen: 100 people start working, they spend weeks/months getting up to speed, and then everything changes... oops, we only need half this software, suddenly!

The problem is: this would leave a bunch of skilled developers sitting idle, and once grabbed up by other departments (if they have budget) they're not likely to be coming back... something needs to change in the way we staff development work. Part of the problem is the traditional perception of the word "Project" imo.

Splitting developers into teams will get you only so far
by
Steven Devijver

Splitting developers into smaller teams will only get you so far. You also need to manage the overhead at the project management level, and there things like Technical Debt, code quality and your architecture start to play an increasingly important role as projects come to a close.

In my opinion, regarless of your methodologies large teams don't scale. In fact, the usual problems become much bigger and in the end unmanageable.

Customers are certainly to blame for big team sizes. Many customers want huge applications and want everything together, instead of building things incrementally.

If you're thinking about a co-located team, you can fit eight developers (four pairs) around a rectangular table, and have the property that no pair is farther away from any other than diagonally across the table, in earshot of each other. If you add a fifth pair, one of the pairs is going to have to sit somewhere where there'll be another pair between them and their farther-away teammates, which prevents them from easily asking questions... or from overhearing a conversation between pairing partners and chiming in.

I'm a (dirty, rotten, etc...) consultant. I can't really go into a company and tell them "you know, you should really get rid of 90 out of the 100 people you've got - just leave me with the best and we'll get things done better, faster, cheaper...". (I've tried - didn't work.)

It seems that:

1) once a team is big, then it is stuck, 2) once a company gets used to ultra-large teams (250+) it is an epidemic, 3) I'm not really willing to bet my life that 10 people can do the work of 100, let alone 250...

I think you're mixing up UP with traditional waterfall. Even -well practiced- UP starts testing as early as possible, so it's not something you postpone to transition. Even in inception test automation can be taken care of. Don't forget that UP is just as iterative as agile methods.Inception and elaboration are not only about analysis, design and architecture. It's all about finding out with a small (you might call it a two pizza or whatever) team whether it's feasable or not to bring in your 100 person team in construction and elaboration. You can however argue as a consultant that your customer isn't waiting for you to decide whether or not you will be needing the 100 persons that are already hired.

To come back on what you'd like to call 'Agile' UP: I consider software engineering in general as a set of - let's say - 10 best practices. If every methodology - beit UP, Lean, SCRUM ... - takes 5 to 7 of these best practices and puts them in its box, you will surely see some overlap. E.g. iterative development, continuous integration, test driven development.So on a day to day basis, there's not that much difference. In the end we all have to deliver a product.

A good friend of mine had his children at pretty well the same time I had mine. Once when our kids were quite young, we were comparing our respective backpacks full of support gear. I noticed that the bag he was carrying was considerably smaller than mine, with a proportionally lower weight!

He explained that his philosophy when buying a bag was to figure out what was the smallest bag possible that he could get away with, and then he bought the next smallest one.

In my experience, this philosophy applies to team size as well, at least at the beginning of a development effort. Determine the smallest possible team size and then (assuming that it isn't 1), subtract one from it. Only increase the size of the team when there is absolutely no other option.

The mistake that I have seen made many times is to assume that a project or development effort requires a large team. Even if the end product is large, that doesn't necessarily equate to having a large team to build it.

I've seen standups with 20 to 30 people in places where "7 plus or minus 2" was seen as a naive suggestion.

It just doesn't accomplish what it's supposed to. "7 + or - 2" comes from psychology - it's the number of things the average person can hold in their head at once (I'm paraphrasing). Yes, everyone speaks. But it's impossible to remember and synthesize all the information given. Also, people tend to give less meaningful information because the meeting is just too long otherwise. What actually happens is several logical teams gather in one huge circle, and people listen to the news from the people actually related to their own work (their "logical" team). All that's gained is the SM is split across too many people, too many problems to solve. The team can no longer hear one another becuase their space is either too big or subdivided.

Large teams, of necessity, compromise many other agile practices and principles. Team size is not an independent variable at all.

The classic answer, I believe, is: learn to write small, independent stories, and realize the importance of adequate Scrum Master coverage. Then you can split teams and still deliver the work.

InfoQ Weekly Newsletter

Join a community of over 250 K senior developers by signing up for our newsletter. If you are based in the EEA, please contact us so we can provide you with the protections afforded to you under EEA protection laws.

Is your profile up-to-date? Please take a moment to review and update.

Email Address

Note: If updating/changing your email, a validation request will be sent

Company name:

Keep current company name

Update Company name to:

Company role:

Keep current company role

Update company role to:

Company size:

Keep current company Size

Update company size to:

Country/Zone:

Keep current country/zone

Update country/zone to:

State/Province/Region:

Keep current state/province/region

Update state/province/region to:

Subscribe to our newsletter?

Subscribe to our architect newsletter?

Subscribe to our industry email notices?

By subscribing to this email, we may send you content based on your previous topic interests. See our privacy notice for details.

You will be sent an email to validate the new email address. This pop-up will close itself in a few moments.

We notice you're using an ad blocker

We understand why you use ad blockers. However to keep InfoQ free we need your support. InfoQ will not provide your data to third parties without individual opt-in consent. We only work with advertisers relevant to our readers. Please consider whitelisting us.