Scaling Scrum within a group of 100s of programmers

Question

Most Scrum teams lean toward 7-15 people ******, though it's not clear how to scale Scrum among 100s of people, or how the effectiveness of a given team might be compared to another team within the group; meaning beyond just breaking the group into Scrum teams of 7-15 people, it's unclear how efforts between the teams are managed, compared, etc.

Any suggestions related to either of these topics, or additional related topics that might be of more importance to account for in planning a large scale SCRUM grouping?

****** In reviewing research related to the suggested size of software development teams, which appears to be the basis for the suggested Scrum team size, I found what appears to be an error in the research which oddly appears to show that bigger teams (15+ ppl), not smaller teams (7 ppl) are better.

---

UPDATE, "Re: Scrum doesn't scale": Made huge amounts of progress personally researching the topic, but thought I'd respond to the general belief of some that Scrum doesn't scale by citing a quote from Succeeding with Agile by Mike Cohn :

Scrum Does Scale: You have to admire the intellectual honesty of the earliest agile authors. They were all very careful to say that agile methodolgies like Scrum were for small projects. This conservatism wasn’t because agile or Scrum turned out to be unsuited for large projects but because they hadn’t used these processes on large projects and so were reluctant to advise their readers to do so. But, in the years since the Agile Manifesto and the books that came shortly before and after it, we have learned that the principles and practices of agile development can be scaled up and applied on large projects, albeit it with a considerable amount of overhead. Fortunately, if large organizations use the techniques described regarding the role of the product owner, working with a shared product backlog, being mindful of dependencies, coordinating work among teams, and cultivating communities of practice, they can successfully scale a Scrum project.

SOURCE: (ran across the book thanks to Ladislav Mrnka answer)

Answer 1

It's not possible to have effective scrum with such a big group. Even with twenty-something you begin to struggle. You have to divide these 100 people into much smaller task groups, which each group having their scrum. Then you can have scrum of team leaders/representatives. This is known as the scrum of scrums.

Answer 2

Scrum is intended for small teams, because the authors of scrum found that small self-organizing teams tended to be very effective in their experience. This makes sense if you consider the lean principle that hand-offs are wasteful and larger teams tend to necessitate hand-offs.

The general take on how to manage larger groups is to create a "scrum of scrums", in which case each team copes with their own sub-project, and then a member from each team represents the sub-project in a team of similar representatives from other sub-projects. This scales up as a pyramid:

           MT (Master Team for full project)
          /|\
         / | \
        /  |  \
      T1   T2  T3 (Teams of Sub-projects)
     /|\
    / | \
   /  |  \
 ST1 ST2 ST3 (Teams of sub-sub-projects)

Coordination of this sort of thing is tricky, but it has been done. The notion of effectiveness can be seen through the visibility inherent is scrum--burn downs and the like.

Really, if your project is so big that you need hundreds of developers, the odds are against you. You need to decompose it into workable projects that can be understood by those working on them.

Answer 3

If you have single project with 100s of people and you want to jump directly into agile and especially Scrum you are most probably performing project suicide.

Agile development and Scrum is skill as any other. If you want to use it you must start with small project. Once you master small project you can start scaling by small steps. The best way to say that agile is not working is to convert big project from plan driven approach to agile approach without any previous experience with scaling agile.

Scaling agile is about incorporating plan driven methods on higher level. You cannot scale Scrum infinitely. The more you scale it the more plan driven mechanism will be needed. There is something called Scrum of Scrum but that is exactly something you can do only if you master pure Scrum with small team. Scrum of Scrum has also its limits - I guess something like 5-6 teams / up to 40 people.

Edit:

The last assumption comes from a lot of sources including CSM and CSPO trainings, books like Succeeding with Agile and Balancing Agility and Discipline and my own experience when participating on both small Scrum team (up to 5 people) and bigger team with 15+ people divided into three teams working on the same project. The bigger the project is the more agility on higher level will be replaced with some old plan driven techniques.

Even trainer on my CSM training claimed that scaling Scrum is one of the biggest challenges the Scrum itself faces.

Answer 4

Nearly all Agile methodologies are designed for small teams, they always talk about communication as a primary aspect of the method, and the larger a team gets the more difficult effective communication becomes.

Alistair Cockburn (one of the founding fathers of Agile) has a methodology called Crystal that has different aspects depending on team size. These guidelines differ slightly but still keep to Agile principles.

An alternative is AUP, which is 'part Agile' and more suited for large teams too.