Agile Team Size
- Share
-
- |
Read later
My Reading List
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:
No direct answers have been given yet on ScrumDevelopmentList, but Tom Scott blogged about a presentation given by Dave Thomas at Spa 2007 that touches on this subject: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:
- Envisioning;
- Definition;
- Development and;
- Release.
And, Pascal Pratmarty on his blog wrote about the Inefficiencies and large teams:
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
Related Sponsor
Agile Project Management That Adapts With You. Provide your global development team a shared space that adapts to the way they work.
Four phase approach???
by
Dries Bellen
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.
We have 100 people so we need HOW MANY teams?
by
Deborah Hartmann
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
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.
One practical concern
by
Susan Davis
Two Pizza Teams
by
Tom Scott
We all agree small teams are better but...
by
Amr Elssamadisy
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...
Re: Four phase approach???
by
Amr Elssamadisy
IMHO, large projects require more of a UP approach.
Why?
a) the inception phase? (aka analysis/design paralysis)
b) the elaboration phase? (aka BDUF architecture not pulled by requirements)
c) construction? (aka follow the elaboration phase and build more)
d) transition? (testing/deployment? shoulda done it earlier)
Having fun with the UP - or is it now the 'Agile' UP ? ;)
Re: Four phase approach???
by
Dries Bellen
IMHO, large projects require more of a UP approach.
Why?
a) the inception phase? (aka analysis/design paralysis)
b) the elaboration phase? (aka BDUF architecture not pulled by requirements)
c) construction? (aka follow the elaboration phase and build more)
d) transition? (testing/deployment? shoulda done it earlier)
Having fun with the UP - or is it now the 'Agile' UP ? ;)
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.
Re: We all agree small teams are better but...
by
Deborah Hartmann
Why Large Teams in the First Place?
by
Dave Rooney
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.
Dave Rooney
Mayford Technologies
Big scrum teams don't work the same
by
Deborah Hartmann
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.
Educational Content
Co-making Great Products
Jeff Patton May 22, 2013
Hello stranger!
You need to Register an InfoQ account or Login to post comments. But there's so much more behind being registered.Get the most out of the InfoQ experience.
Tell us what you think