Brooks’ Law besagt, dass zusätzliches Personal ein bereits verspätetes Projekt weiter verzögert. In dieser Pauschalität ist der Satz nicht belegt. Belegt ist etwas anderes: Der Koordinationsaufwand wächst überproportional zur Teamgröße, die Leistung pro Kopf sinkt, und die Kosten steigen deutlich schneller als das Tempo. Entscheidend ist nicht die Kopfzahl, sondern die Zahl der Übergaben zwischen Fachbereich, IT und Dienstleister.
- COCOMO II rechnet mit einem Skalierungsexponenten zwischen 1,01 und 1,226 — der Aufwand wächst schneller als die Teamgröße.
- QSM, 564 IT-Projekte: Teams über 20 Personen brauchten 8,92 Monate, Teams unter fünf Personen 9,12 Monate. Rund eine Woche Vorsprung für ein Vielfaches an Personal.
- QSM, 390 Anwendungen: zusätzliches Personal verkürzte den Zeitplan um 30 Prozent, trieb aber die Kosten um 350 und die Fehlerzahl um 500 Prozent nach oben.
- ETH Zürich (58 Projekte, 580.000 Commits) misst sublineare Produktivität, eine PLOS-ONE-Studie das Gegenteil. Die Teamgröße allein entscheidet also nicht.
- Der belastbare Hebel ist die Zahl der Übergaben, die eine Information durchläuft, bevor jemand sie in Arbeit umsetzt.
Ein Projekt läuft aus dem Ruder. Der Lenkungsausschuss beschließt drei zusätzliche Entwickler. Zwei Monate später ist das Team größer, das Budget deutlich stärker belastet und der Termin genauso weit weg wie vorher. Fast jeder IT-Leiter kennt diese Schleife, und fast jeder zitiert danach Brooks’ Law. Nur: Was davon ist eigentlich bewiesen?
Was ist an Brooks’ Law tatsächlich belegt?
Frederick Brooks formulierte den Satz 1975 in „The Mythical Man-Month“, aus seiner Erfahrung mit der IBM-OS/360-Entwicklung. Wichtig ist der Halbsatz, der fast immer weggelassen wird: Brooks leitete sein Gesetz mit dem ausdrücklichen Hinweis ein, dass er hier maßlos vereinfache. Er nannte auch die Bedingung, unter der es gilt. Aufgaben müssen so stark verzahnt sein, dass sie sich nicht sauber aufteilen lassen. Für teilbare Arbeit gilt sein Gesetz explizit nicht.
Ein kontrolliertes Experiment zu genau dieser Frage gibt es bis heute nicht. Kein Unternehmen teilt identische Projekte per Zufall in zwei Gruppen auf, um zu messen, was Personalaufstockung bewirkt. Wer „wissenschaftlicher Beweis“ im strengen Sinn verlangt, bekommt ihn hier nicht. Was es gibt, sind mehrere unabhängige Datenquellen, die alle in dieselbe Richtung zeigen.
Wie viel Zeit gewinnen größere Teams wirklich?
Die Softwareindustrie rechnet seit Jahrzehnten mit Skalierungsfaktoren, die genau diesen Effekt abbilden. Im COCOMO II Model Definition Manual von Barry Boehm liegt der Skalierungsexponent zwischen 1,01 und 1,226. Ein Wert über 1,0 bedeutet: Der Aufwand wächst schneller als die Größe. Als Ursache nennt das Handbuch zwei Faktoren, nämlich wachsenden Kommunikationsaufwand und wachsenden Integrationsaufwand.
Die Beratung QSM hat das an ihrer Projektdatenbank durchgerechnet. In einer Auswertung von 564 IT-Projekten brauchten große Teams mit mehr als 20 Personen für ein Vorhaben von 100.000 Codezeilen 8,92 Monate. Kleine Teams mit weniger als fünf Personen brauchten 9,12 Monate. Der Vorsprung der großen Teams betrug also rund eine Woche, bei einem Vielfachen an Personal. Eine spätere Auswertung von 390 Anwendungen zeigt dasselbe Muster: Zusätzliches Personal verkürzte den Zeitplan um etwa 30 Prozent, trieb die Kosten aber um 350 Prozent und die Fehlerzahl um 500 Prozent nach oben.
Eine Einordnung gehört dazu. QSM ist ein kommerzieller Anbieter von Schätzwerkzeugen, die Daten stammen aus der eigenen Datenbank. Die Größenordnung ist aber über zwanzig Jahre und mehrere Auswertungen hinweg stabil geblieben.
Unabhängig davon bestätigt sich das Bild in einer zweiten, akademischen Datenbank. Diego Rodríguez, Miguel-Ángel Sicilia, Elena García und Rachel Harrison werteten 951 Datensätze aus 4.105 Projekten des ISBSG-Repositorys aus, einer von QSM unabhängigen Quelle, und fanden dasselbe Muster: kleinere Teams sind produktiver, und die Terminleistung verschlechtert sich messbar, sobald die Teamgröße zweistellig wird.
| Quelle | n | Methode | Kernbefund |
|---|---|---|---|
| COCOMO II (Boehm) | Skalierungsmodell, an Praxisdaten kalibriert | Formel-Ableitung | Aufwand wächst mit Exponent 1,01–1,226 überproportional zur Teamgröße |
| QSM 2019 | 564 + 390 Projekte | Datenbank-Auswertung | ~1 Woche Vorsprung bei Vielfachem an Personal; +350 % Kosten, +500 % Fehler |
| Rodríguez et al. 2012 | 4.105 Projekte (ISBSG) | Regressionsanalyse | kleinere Teams produktiver, Terminleistung fällt ab zweistelliger Größe |
Warum sinkt die Leistung pro Kopf, wenn Teams wachsen?
Die bislang größte unabhängige Untersuchung stammt von der ETH Zürich. Ingo Scholtes, Pavlin Mavrodiev und Frank Schweitzer analysierten 58 Open-Source-Projekte mit über 580.000 Commits und mehr als 30.000 Entwicklern. Sie maßen nicht die Zahl der Commits, sondern deren tatsächlichen Umfang. Ergebnis: Die Produktivität wächst sublinear. Jeder zusätzliche Entwickler bringt weniger als der vorherige.
Es gibt allerdings ein Gegenergebnis, und wer redlich argumentiert, muss es nennen. Didier Sornette, Thomas Maillart und Giacomo Ghezzi fanden in einer Untersuchung von Open-Source-Projekten in PLOS ONE das Gegenteil, nämlich superlineare Produktivität. Eine Verdopplung der Gruppe multiplizierte den Output typischerweise mit 2,5. Der Effekt hielt für Gruppen von fünf bis zu einigen hundert Entwicklern, war bei großen Gruppen aber deutlich schwächer.
Zwei seriöse Studien, zwei gegenläufige Befunde. Das ist kein Widerspruch, sondern ein Hinweis. Die Teamgröße allein entscheidet nicht. Entscheidend ist, wie die Arbeit organisiert ist.
An wie vielen Stellen verlieren Ihre Anforderungen Kontext?
Der WERT³ Quick-Check zeigt Ihnen in 10 Minuten, wo Ihre größten Hebel liegen. Kostenlos, ohne Verkaufsgespräch.
→ WERT³ Quick-Check starten
Woran liegt es dann, wenn nicht an der Kopfzahl?
Open-Source-Projekte, in denen zusätzliche Entwickler die Produktivität steigern, haben eine Eigenschaft gemeinsam. Die Beteiligten arbeiten am selben Artefakt, sehen dieselben Diskussionen und brauchen niemanden, der ihnen den Zweck ihrer Arbeit übersetzt. In einem typischen Mittelstandsprojekt sieht das anders aus. Der Fachbereich schreibt Anforderungen und wirft sie über den Zaun. Die IT übersetzt sie in eine Spezifikation und wirft sie an den Dienstleister weiter. Der Dienstleister zerlegt sie in Tickets für ein Nearshore-Team.
Wer in dieser Kette Personal ergänzt, ergänzt selten Arbeitskraft am Problem. Er ergänzt eine weitere Station, an der Information übersetzt, gefiltert und um ihren Kontext gebracht wird. In meiner Beratungspraxis beobachte ich, dass die neuen Leute genau dort andocken, wo ohnehin schon die meiste Reibung sitzt, also an der Schnittstelle zwischen Fachbereich und IT.
In der Praxis heißt das: Die Frage ist nicht, wie viele Menschen an einem Projekt arbeiten. Die Frage ist, wie viele Übergaben eine Information durchläuft, bevor jemand sie in Arbeit umsetzt.
Wie helfen die fünf Kräfte bei der Diagnose?
Genau an dieser Stelle setzt das WERT³ Modell an. Es beschreibt Wirksamkeit über fünf Kräfte, von denen drei das Tempo erhöhen und zwei es bremsen.
Die drei treibenden Kräfte sind die Kollaborationsgeschwindigkeit (wie schnell kommt eine Idee beim Kundennutzen an), die Kundenintegration (wie nah ist der echte Nutzer am Team) und die Feedback-Lerngeschwindigkeit (wie schnell verändert Rückmeldung die Arbeit). Die zwei bremsenden Kräfte sind die Kommunikationsreibung (Latenz und Verlust bei jeder Klärung) und die Übergabehäufigkeit (wie viele Stationen eine Information durchläuft).
Der Zusammenhang mit der Personalfrage wird damit sichtbar. Wer einem laufenden Projekt Menschen hinzufügt, erhöht in aller Regel die Übergabehäufigkeit und die Kommunikationsreibung. An der Kundennähe und an der Feedbackgeschwindigkeit ändert sich dabei nichts. Zwei bremsende Kräfte steigen, drei treibende bleiben konstant. Das Ergebnis fällt, und zwar unabhängig davon, wie fähig die neuen Leute sind.
Umgekehrt erklärt dasselbe Modell die Ausnahme. Wenn zusätzliche Menschen in einen abgegrenzten Bereich mit direktem Nutzerzugang gehen, ohne eine weitere Übergabestation zu erzeugen, dann steigt die Kopfzahl, ohne dass die Bremsen anziehen. Dann funktioniert Aufstockung.
Was heißt das für Ihre nächste Eskalation?
Bevor Sie Personal freigeben, klären Sie drei Dinge. Ist die Arbeit überhaupt teilbar, oder hängt alles an denselben Entscheidungen? Kommen die neuen Leute an eine bestehende Übergabestelle, oder schaffen Sie eine neue? Und ist das Projekt bereits spät, also in der Phase, in der Einarbeitung die produktivsten Köpfe bindet?
Zusammengefasst bedeutet das: Personalaufstockung erhöht die Kosten fast immer, verkürzt den Zeitplan selten nennenswert und verzögert dort, wo Arbeit nicht sinnvoll teilbar ist. Der wirksamere Hebel liegt woanders, nämlich beim Abbau von Übergaben. Ein direkter Draht zwischen der Person, die das Problem hat, und der Person, die es löst, spart mehr Zeit als drei zusätzliche Entwickler.
Wenn Sie wissen wollen, wie viele Übergaben Ihre Anforderungen wirklich durchlaufen
„Emails über den Zaun werfen ist keine Kommunikation“ zeigt anhand von fünf Kräften, warum Projekte scheitern, obwohl alle ihren Job machen. Das Buch zur WERT³-Methodik. 318 Seiten, April 2026 erschienen.
→ Buch ansehen
Häufige Fragen
Stimmt Brooks’ Law wissenschaftlich?
Ein kontrolliertes Experiment dazu existiert nicht. Belegt sind die zugrunde liegenden Mechanismen: überproportional wachsender Koordinationsaufwand, sinkende Leistung pro Kopf und reale Einarbeitungskosten. Der pauschale Satz „mehr Menschen gleich später“ geht über diese Evidenz hinaus.
Wie groß sollte ein Projektteam sein?
Auswertungen von QSM zeigen für mittelgroße Informationssysteme ein Optimum bei drei bis sieben Personen. Ab etwa neun Personen verschlechtert sich die Termintreue messbar. Diese Werte gelten für eine bestimmte Projektgröße und sind keine allgemeingültige Obergrenze.
Wann hilft es, ein Team zu vergrößern?
Wenn die Arbeit sauber teilbar ist, das Projekt noch früh läuft und die neuen Personen keine zusätzliche Übergabestelle erzeugen. Open-Source-Daten zeigen für solche Konstellationen sogar überproportionale Produktivitätsgewinne.
Wie erkenne ich, ob mein Problem wirklich Kapazität ist?
Zählen Sie die Stationen zwischen Fachbereich und Umsetzung und messen Sie, wie lange eine Rückfrage bis zur Antwort braucht. Wenn beides hoch ist, liegt der Engpass in der Zusammenarbeit. Der WERT³ Quick-Check macht das in 10 Minuten sichtbar.
Quellen
| Quelle | n | Datum | URL |
|---|---|---|---|
| Boehm, COCOMO II Model Definition Manual | Modell, keine Stichprobe | 2000 | rose-hulman.edu/class/cs/csse372/201310/Homework/CII_modelman2000.pdf |
| QSM „4 Key Studies on Team Size" | 564 + 390 Projekte | 2019 | qsm.com/blog/2019/4-key-studies-team-size |
| Scholtes, Mavrodiev & Schweitzer, Empirical Software Engineering | 58 Projekte, 580.000 Commits, >30.000 Entwickler | 2016 | link.springer.com/article/10.1007/s10664-015-9406-4 |
| Sornette, Maillart & Ghezzi, PLOS ONE | Open-Source-Gruppen, 5 bis mehrere hundert Entwickler | 2014 | journals.plos.org/plosone/article?id=10.1371/journal.pone.0103023 |
| Rodríguez, Sicilia, García & Harrison, Journal of Systems and Software | 951 Datensätze aus 4.105 Projekten (ISBSG) | 2012 | sciencedirect.com/science/article/abs/pii/S0164121211002366 |
| Brooks, „The Mythical Man-Month" | Buch, keine empirische Stichprobe | 1975 | openlibrary.org/books/OL5044740M/The_mythical_man-month |