Inhalt
Am 31. März 1966 liefert IBM die erste Version seines Betriebssystems OS/360 aus – fast zwei Jahre nach der Ankündigung. Geplant war ein einziges System, das schon auf Maschinen mit 32 KiB Speicher läuft. Geliefert wird eines, das mindestens 44 KiB braucht. Der Mann, der das Projekt geleitet hat, zieht daraus einen Satz, den Softwareentwickler bis heute kennen. Ein Beispiel zum Teamprinzip der Größe.
Ein Projekt gerät in Verzug
Situation
Frederick P. Brooks Jr., geboren 1931, kommt 1956 zu IBM. Er leitet dort die Entwicklung der Rechnerfamilie System/360 und danach ihres Betriebssystems. OS/360 wird 1964 angekündigt. IBM beziffert den Umfang auf etwa 1,5 Millionen Befehle. Der Zeitplan hält nicht. IBM bringt als Notlösung einfachere Systeme heraus, darunter DOS/360. Die große Variante MVT folgt nach weiteren Verzögerungen erst 1967.
Bezug zum Teamprinzip
Die Aufgabe war riesig, und ein kleines Team hätte sie nicht bewältigt. Das Teamprinzip der Größe bestreitet das nicht. Es sagt: Jedes weitere Mitglied bringt Kraft und kostet Abstimmung – ein Team ist so klein, wie die Aufgabe es erlaubt. Die Frage ist also nie „groß oder klein“, sondern: Was kostet der nächste Kopf, und was bringt er?
Mehr Leute, mehr Verspätung
Situation
Als das Projekt in Rückstand gerät, stockt Brooks das Personal auf. Das ist der naheliegende Griff: Wenn die Arbeit nicht reicht, braucht es mehr Arbeiter. Im Rückblick urteilt Brooks, diese Entscheidung habe die Verspätung vergrößert.
Bezug zum Teamprinzip
Hier wird der Kernsatz sichtbar. Jeder Neue bringt Kraft – aber erst später. Die Abstimmung kostet er sofort. In einem Projekt, das bereits zu spät ist, kommt die Kraft zu spät und die Kosten kommen pünktlich.
Das Gesetz und seine drei Gründe
Situation
IBM-Chef Thomas Watson Jr. fragt Brooks, warum Softwareprojekte schwerer zu führen seien als Hardwareprojekte. Aus der Antwort wird 1975 das Buch „The Mythical Man-Month“. Sein bekanntester Satz ist Brooks' Gesetz: Wer einem verspäteten Softwareprojekt Leute hinzufügt, verspätet es weiter. Brooks nennt drei Gründe. Erstens müssen Neue eingearbeitet werden und binden dabei die Erfahrenen. Zweitens wächst die Zahl der Verständigungswege schneller als die Zahl der Köpfe, nämlich nach der Formel n(n−1)/2. Bei 50 Entwicklern sind es 1.225. Drittens lässt sich manche Arbeit nicht teilen.
Bezug zum Teamprinzip
Die Formel macht die Abstimmungskosten zählbar. Rechne sie für dein Team: Fünf Personen haben zehn mögliche Zweierverbindungen, zehn Personen haben 45. Die Kopfzahl verdoppelt sich, die Verbindungen wachsen auf mehr als das Vierfache. Dazu passt ein Befund der Forscher Bradley R. Staats, Katherine L. Milkman und Craig R. Fox aus dem Jahr 2012: In zwei Experimenten und in den Daten von 594 Softwareprojekten wurde der Aufwand umso stärker unterschätzt, je größer das Team war. Wir sehen die zusätzliche Kraft und übersehen den zusätzlichen Preis.
Das Chirurgenteam
Situation
Brooks belässt es nicht bei der Warnung. Sein Gegenvorschlag ist das „Chirurgenteam“: ein kleiner Kern um einen leitenden Programmierer, dem die anderen zuarbeiten – wie im Operationssaal, wo einer schneidet und die übrigen ihn dabei unterstützen.
Bezug zum Teamprinzip
Das ist der zweite Halbsatz des Prinzips als Bauplan. Wenn die Aufgabe viele Hände braucht, dann ordne sie so, dass nicht jeder mit jedem sprechen muss. Wenige entscheiden, viele unterstützen. So wächst die Kraft, ohne dass die Abstimmung im selben Maß mitwächst.
Die Grenze des Gesetzes
Situation
Brooks selbst nannte seinen Satz eine grobe Vereinfachung. Er gilt für Projekte, die bereits verspätet sind. Wer früh erfahrene Leute dazuholt und die Arbeit in gut getrennte Teile schneidet, mildert den Effekt.
Bezug zum Teamprinzip
Das Prinzip ist kein Verbot zu wachsen. Es verlangt eine ehrliche Rechnung zum richtigen Zeitpunkt. Früh, mit klaren Teilaufgaben und erfahrenen Leuten kann ein weiterer Kopf sich lohnen. Spät und ohne Zuschnitt verschärft er das Problem, das er lösen soll.
Das nimmst du mit
Die wichtigsten Lektionen
- Bevor du in einer Krise Verstärkung holst, rechne: Wer arbeitet die Neuen ein, und was bleibt in dieser Zeit liegen?
- Zähle nicht nur Köpfe, sondern Verbindungen. Die Formel n(n−1)/2 passt auf jede Teamliste.
- Wenn die Aufgabe viele Menschen braucht, baue einen kleinen Kern, dem die anderen zuarbeiten.
- Prüfe, ob sich die Arbeit überhaupt teilen lässt. Was sich nicht teilen lässt, wird durch mehr Leute nicht schneller.
- Erweitere früh oder gar nicht. Die teuerste Verstärkung ist die kurz vor dem Termin.
Zusammenfassung
Frederick Brooks hat an einem der größten Softwareprojekte seiner Zeit erlebt, dass Menschen und Monate nicht beliebig tauschbar sind. Er holte Leute in ein verspätetes Projekt und sah es weiter zurückfallen. Sein Gesetz ist die bekannteste Praxisformel für das Teamprinzip der Größe: Der neue Kollege kostet sofort Einarbeitung und Abstimmung, seine Kraft kommt später. Die Antwort ist nicht, klein zu bleiben um jeden Preis. Die Antwort ist, die Größe an der Aufgabe zu messen – und sie so zu ordnen, dass Abstimmung nicht alles auffrisst.