2

As one who comes from outside the IT/software world, I'm curious about the scaling of Agile & Scrum. While I understand the principles, is there an upper limit for the size of project or number or team members before it becomes counter=productive?

As I understand it, a large part of the benefit comes from daily meetings. From my own experience, I've been involved in a number of construction projects in which we had daily meetings that involved all trades. This basically amounts to 40-50 people in one room trying to coordinate. It doesn't work at that scale. Inevitably these meetings end and break up into 10-20 little groups coordinating between themselves. So for us, Agile works on a limited scale, usually in daily crew meetings, but not on a 'project' level.

So is there a point (number of team members, dollar value, ???, etc.) where Agile becomes unfeasible?

flag

4 Answers

3

5 -7 is the rule for team size... straight from the original texts. I have found this to hold having experiments with both larger and smaller.

Larger projects often need larger teams than that, in that case you need to have multiple teams with some kind of get together "Scrum of Scrums" in Scrum to ensure things are kept in sync. Either that or divide the work along sensible boundaries wher you do not require strong inter team communication (should the project lend itself to that).

Scaling Scrum / Agile is hard and many of the texts do not help greatly in this regard, partly because every situation demands a tailored approach by the team. inspect-and-adapt. However it can and has been done very successfully in many organizations.

link|flag
In some cases, the scaling has to be through time instead of through a lot of concurrent teams. As many as three concurrent teams often has enough communication problems that 6 more months of schedule and 5 fewer people will deliver the same functionality with higher overall quality. – S.Lott Dec 22 at 19:40
I agree with what Mick says here, what I'd add is that your team size has to be of a size that means it can function efficiently, too small and you won't accomplish much, too large and weaker or lazy team members can hide in the melee. I've recently worked with a team of 12 (imposed by the client) which was OK for the most part but I'd have preferred to split them into 2 teams of 6. – Scrimmers Jan 8 at 9:33
2

  1. It's hard to say agile becomes unfeasible for a bigger groups of people. It just becomes harder and harder as the team grows.

  2. Scaling single agile team beyond 9 people starts to be a bit of waste of time. If you pass that you theoretically do Scrum of Scrums. Having said that it's easier to organize 30 people in 4-5 agile teams and put one Scrum of Scrums over there than organize 14 or 15 people Scrum-way. You either end up with a couple of teams and very artificial Scrum of Scrums done for 3 people or you have a single overgrown team.

  3. Beyond 50 people you should start thinking about another layer of Scrum (Scrum of Scrums of Scrums) which is the place where the hassle becomes probably too big and you may reconsider your methodology.

  4. There's no money limit in Scrum projects. It's rather team size which limits you. If you're able to do $20M worth project with a reasonably small team that's perfectly fine.

  5. One type of projects which can be hard do deal with using Scrum and 15+ people is one where there are a lot of interrelated tasks everywhere and many people need to work with each other very often. Then you have a situation when you just have to keep all folks in one team even though Scrum practices would work better if they were split among a few different groups.

link|flag
1

Two data points I can give-

Salesforce.com is 100% Scrum Agile. They have over 1500 people. They are still working in 5-9 person teams, that then have a heirarchy over them.

Jeff McKenna, one of the people who created the first Scrum team, is making a living helping people do enterprise scale implementations of Scrum.

It can be done, the how is still in its infancy with several ways to do it.

link|flag
0

Communication lines are the issue in team size scaling:

  • 2 people, 1 line
  • 3 people, 2 lines
  • 4 people, 5 lines
  • 7 people, 21 lines
  • 10 people, 45 lines

It's a fully-connected graph, and more communication lines always means slower-moving.

Where N is the number of people, the number of lines of communication is N(N−1)/2. That will introduce a practical limit at some point.

link|flag

Your Answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.