Brooks’s Law – Wenn mehr Hände nicht zu schnelleren Ergebnissen führen

Wenn Arbeit zu viel wird oder Projekte sich verzögern, dann folgt der spontane Ruf nach “mehr Leuten”. Um mit mehr Druck und roher Gewalt die gewünschten Ergebnisse doch noch zu erreichen. Dieser Impuls ist so natürlich, wie das Trinken auf den Durst folgt. Schließlich sind wir in der Tradition des Taylorismus und des Scientific Management sozialisiert. 

Mehr Leute sind eine gute Strategie, solange Du mechanische und einfache Arbeiten zu erledigen hast. Also, wenn Du 100 IKEA-Regale aufbaust, dann geht das mit 10 Leuten schneller als alleine. Wenn Du allerdings komplexe Aufgaben und moderne Wissensarbeit wie z.B. Softwareentwicklung erledigst, dann funktioniert diese Strategie nicht. Im Gegenteil: Denn Brooks's Law besagt, dass der Aufwand sogar steigt und die Fertigstellung der Arbeit noch weiter hinauszögert. Und das hat tatsächlich logische Gründe.

Die Gültigkeit von Brooks Law und der Umstand, dass mehr Leute nicht zu schnelleren Ergebnissen führen oder Projekte sich sogar weiter verzögern, kannst Du vor allem mit zwei Argumenten belegen:

1. Steigender Kommunikationsaufwand im Team
2. Unteilbarkeit von Aufgaben

Wem das noch nicht ausreicht, der lässt sich vielleicht von empirischen Studien überzeugen.

Wenn neue Kollegen in ein wissenslastiges und komplexes Projekt kommen, dann hat das zwei Auswirkungen. 

1. Wissenstransfer ist notwendig, neue Mitarbeiter müssen “ongeboardet” werden. Das kostet Zeit, die "eigentliche" Arbeit bleibt liegen.

2. Mehr Abhängigkeiten und Kommunikationspfade, d.h. es braucht mehr Austausch, damit das Team auch synchronisiert bleibt. Also mehr Meetings, mehr E-Mails etc. 

Die Anzahl der Verbindungen und möglicher Abhängigkeiten in einem Team kannst Du sogar mathematisch mit der Formel x*(x-1)/2 berechnen.  

Das heißt, bei einem Team von 3 Personen resultieren 3 Verbindungen, ein Team von 5 Mitarbeitern hat bereits 10 und ein Team von 25 Personen sogar 300 Abhängigkeiten. Auch wenn nicht immer jeder mit jedem kommunizieren und arbeiten muss, kannst Du damit einfach erklären, dass die Komplexität und der Aufwand durch die Hinzunahme von weiteren Kollegen steigt. Zudem sind wir nunmal “social animals”, das heißt, neue Kollegen müssen nicht nur auf inhaltlicher Ebene, sondern auch auf einer sozialen Ebene ihren Einstieg ins Team finden.

Ein weiterer Grund, warum mehr Leute nicht zu schnelleren Ergebnissen führen, ist die Unteilbarkeit mancher Aufgaben. Eine Schwangerschaft dauert knapp 10 Monate und auch 10 Frauen können ein Kind nicht in einem Monat austragen. In jedem Team und Projekt gibt es Aufgaben, die Du schlichtweg nicht auf mehrere Mitarbeiter aufteilen kannst.

In einer groß angelegten Studie wurde die Performance großer Teams (20 und mehr Entwickler) und kleiner Teams (5 oder weniger Entwickler) für die Programmierung von 100.000 Zeilen Code verglichen. Das Ergebnis: Kleine Teams brauchten nur unwesentlich länger und waren im Schnitt 4 mal produktiver als große Teams. Also ein klarer empirischer Beleg dafür, dass mehr Leute arbeiten nicht beschleunigen und Brooks Law eine hohe praktische Relevanz hat. 

Hier ein paar Tipps und Ideen, wie Du Brooks's Law aushebeln oder es gar nicht erst zu einer Situation kommen lässt, in der Du geneigt bist ein verspätetes Projekt durch "rohe Gewalt” oder einfach  nur "Manpower" zu retten.

1. Scope reduzieren - Meistens werden Schätzungen ja am Whiteboard lange vorher gemacht und so getan, als würde der “Cone of Uncertainty” nicht existieren. Statt also dem spontanen Impuls nach “brute force” nachzugeben, reduziere den Scope und halte die Timeline ein. 
2. Bottlenecks identifizieren - Statt spontan nach mehr Leuten zu rufen, identifiziere das Problem und den größten Engpass. Schließlich ist die Leistungsfähigkeit eines Teams gemäß der Theory of Constraints durch den größten limitierenden Faktor determiniert. Erst wenn Du das Bottleneck identifiziert hast, suchst Du genau dafür eine Lösung, statt pauschal “brute force” als Lösung zu akzeptieren.
3. Modularität, Softwarearchitektur - Durch eine gute Softwarearchitektur und die Einhaltung guter Entwicklungspraktiken kannst Du dafür sorgen, dass Du eine höhere Flexibilität auch in Bezug auf die Hinzunahme weiterer Entwickler gewinnst.
4. Team- und Organisationsdesign - Forciere das Arbeiten in kleinen, möglichst autonomen Teams.  Das hängt einerseits mit deiner Software-Architektur zusammen, kann aber auch nachhaltig durch Team-Topologien beeinflusst werden. 
5. Release often, release early - Inkrementelles Arbeiten sorgt für permanente Feedbackschleifen, macht drohende Verzögerungen schneller sichtbar und deckt frühzeitig Bottlenecks auf. Das reduziert das Risiko, deckt Planungsfehler schnell auf und reduziert Stress zum Ende eines Projektes. 

Wenn alles nicht mehr hilft, das Projekt kurz vor Abgabe ist, dann bist Du am besten beraten, Brooks Law dahingehend zu beherzigen, dass Du eine Verspätung akzeptierst und nicht auf “brute force” setzt.

“Brute Force” ist eine der größten Denkfehler des traditionellen Managements in Bezug auf Software- und digitale Projekte. Dieser wird meistens dadurch verschlimmert, dass Roadmaps frühzeitig am Whiteboard geplant werden. Das Beste, was Teams und Stakeholder im Sinne von Brooks Law tun können, um gar nicht erst in die “brute force” Falle zu tappen, ist ein gut gemanagter agiler Prozess, viel Dialog, ein Organisationsdesign im Einklang mit deiner Softwarearchitektur begleitet von einer klaren und ehrlichen Priorisierung auf strategischer Ebene.