Scrum-Empfehlungen zur Teamgröße nennen typischerweise den empfohlenen Bereich (üblicherweise 3-9 Developer), ohne zu erklären, was sich konkret verschlechtert, wenn ein Team ihn überschreitet. Die tatsächlichen Fehlermuster zu kennen, ist nützlicher als die Zahl zu kennen, weil es erklärt, warum die Zahl existiert und worauf zu achten ist, während sich ein Team ihr nähert.
Kommunikationsaufwand wächst schneller als das Team. Die Anzahl möglicher Eins-zu-eins-Kommunikationskanäle in einer Gruppe wächst ungefähr quadratisch mit ihrer Größe, nicht linear. Ein Team von fünf hat zehn mögliche Paare; eines von elf hat fünfundfünfzig. Das ist kein abstraktes Anliegen: Es zeigt sich konkret als Daily Scrums, die weit über ihre Timebox hinausreichen, weil es genuin mehr zu sagen gibt, und als wachsende Zahl an Entscheidungen, die eine Rücksprache mit Menschen erfordern, die nicht im ursprünglichen Gespräch waren.
Untergruppen bilden sich, ob geplant oder nicht. Ab einer bestimmten Größe gruppieren sich Menschen natürlich in kleinere informelle Kreise, basierend darauf, wer nebeneinander sitzt, an verwandten Arbeitspaketen arbeitet, oder einfach am leichtesten miteinander spricht. Das ist keine Dysfunktion (es ist eine natürliche menschliche Reaktion auf eine Gruppe, die zu groß ist, um sie als einzelne Einheit zu erfassen), aber es untergräbt Scrums Annahme eines Teams mit einem geteilten Verständnis seiner Arbeit, und erzeugt oft genau die Art von siloartigen Informationslücken, die ein einzelnes kleines Team nicht hätte.
Der Daily Scrum erfüllt seinen Zweck nicht mehr. Fünfzehn Minuten teilen sich ungleichmäßig auf mehr Menschen auf, und der Daily Scrum eines großen Teams tendiert dazu, entweder regelmäßig seine Timebox zu überschreiten, oder so knapp zu werden, dass er keinen echten Synchronisationswert mehr liefert, während Menschen bei Updates abschalten, die sie nicht betreffen.
Individuelle Verantwortlichkeit wird schwerer nachzuverfolgen. In einem kleinen Team ist relativ leicht zu wissen, wer woran arbeitet, und zu bemerken, wenn jemand kämpft oder unterfordert ist. In einem größeren Team verschlechtert sich diese Sichtbarkeit, und Probleme, die in einem kleineren Team früh aufgefallen wären, bestehen länger, bevor sie jemand bemerkt, einfach weil es mehr Fläche gibt, auf der etwas unbemerkt bleiben kann.
Entscheidungsfindung verlangsamt sich selbst bei einfachen Fragen. Eine Entscheidung, die ein fünfköpfiges Team in einem zweiminütigen Gespräch treffen kann, könnte in einem elfköpfigen Team eine geplante Diskussion oder mehrere Runden asynchronen Inputs erfordern, einfach weil sich mehr Menschen berechtigt fühlen mitzureden, und echter Konsens (oder auch nur informierter Widerspruch) mit mehr Stimmen länger dauert.
Was tatsächlich zu tun ist
Die Aufteilung in mehrere kleinere Teams, jedes mit klarer Eigentümerschaft an einem kohärenten Teil des Produkts, adressiert das Koordinationsproblem direkt, führt aber ein neues ein: die Koordination über die jetzt mehreren Teams hinweg. Das ist kein Grund, die Aufteilung zu vermeiden; es ist ein Grund, bewusst in teamübergreifende Koordinationsmechanismen zu investieren (genau das, wofür Frameworks wie Flight Levels gestaltet sind), statt anzunehmen, die Aufteilung allein löse alles.
Die praktische Schwelle ist nicht wirklich eine feste Zahl: Es ist der Punkt, an dem das Team selbst zu berichten beginnt, dass Koordination sich schwerer anfühlt als die Arbeit selbst, dass Entscheidungen länger dauern, als sie sollten, oder dass Untergruppen begonnen haben, etwas unabhängig vom Ganzen zu operieren. Das ist das Signal, auf das reagiert werden sollte, ob es bei acht oder vierzehn Personen auftritt.