Die Diskussion ist in etwa so alt, wie agile Entwicklung alt ist und dennoch haben sich die Fragen (und “Vorwürfe”) kaum geändert: “Ja geht denn das auch für ‘große’ Projekte?” Varianten dieser Anmerkung lauten zum Beispiel: “Das mag ja für Spielprojekte funktionieren. Wir dagegen, wir machen Projekte mit hunderten von Mitarbeitern, da funktionieren nur die traditionellen Ansätze!”

Ob die traditionellen Ansätze (wenigstens) bei solchen Teamgrößen funktionieren, sei einmal dahingestellt. Die Projekte oberhalb der 100 Personen, an denen ich bisher mitgearbeitet habe, waren alle weit entfernt von dem ruhigen, sicheren Fahrwasser, das ich aus der agilen Entwicklung kenne. Obwohl sie alle am Ende zumindest vom Management als mehr oder minder erfolgreich dargestellt wurden, hätte das, was dort als Erfolg verkauft wurde, einen agilen Projektleiter vermutlich in die Resignation und in den Vorruhestand getrieben.

Spannender finde ich die Frage, was eigentlich “große” Projekte sind. Bei meiner letzten völlig unrepräsentativen Umfrage unter fünf Managern habe ich vor allem Definitionen über die Anzahl der Projektmitarbeiter erhalten: “Große” Projekte beginnen bei 50, 100, oder 1000 Mitarbeitern, je nachdem, wen ich befragt habe. Das bemerkenswerte an dieser Definition ist die Beobachtung, dass es niemals darum geht, was in dem Projekt erstellt wird. Der Bau eines neuen Bestandssystems für eine Versicherung mit einem 5-Personen-Team ist demnach ein kleines Projekt, der Bau eines Bestandssystems für die gleiche Versicherung mit 200 Mitarbeitern ist demnach ein großes Projekt? Vielleicht wird hier Projekt- und Teamgröße verwechselt.

Diese Verwirrung ist weit verbreitet. Gemeinhin wird die Bedeutung eines Managers oder Projektleiters an der Anzahl der Personen gemessen, für die er oder sie “die Verantwortung” trägt. Das bedeutet, dass ein Projektleiter um so wichtiger ist, je mehr Personen in seinem oder ihrem Projekt beschäftigt sind; Manager werden also sehr direkt dafür belohnt, ihr Team so groß zu machen, wie nur irgendwie möglich. Das ist vieles, aber bestimmt kein betriebswirtschaftlich rationales Denken.

“Na ja, mit so einem kleinen Team kann das ja jeder” kritisierte einmal ein Manager, nachdem wir eine Aufgabe in einem 4-Personen-Team innerhalb eines halben Jahres gelöst hatten, an der er vorher mit einem 30-Personen-Team nach über einem Jahr gescheitert war. Extrembergsteiger schleifen zum Training schon mal einen LKW-Reifen hinter sich her wenn sie ihren Hausberg errennen, um ihre sportliche Ausdauer zu verbessern. Das mag für Sportler interessant sein, Manager sollten sich allerdings solchen unnötigen Ballasts entledigen und Effizienz als Ziel sehen - also die gleiche Leistung mit einem möglichst kleinen Team zu bringen. Aufgaben so klein und so wirtschaftlich zu erledigen, wie möglich ist die eigentliche Kunst des Projektmanagements.

Fasziniert hat mich eine Meldung über Google (siehe meinen Eintrag [1] Agile Entwicklung bei Google): Dort bestehen normale Projekte aus 3-Personen-Teams bei einer Laufzeit unter vier Monaten. Große Projekte haben viermal so große Teams. Noch größere Projekte gibt es anscheinend nicht, sie müssen zunächst aufgespalten werden. Dass Google mit dieser Politik Microsoft in einem ihrer Kernbereiche (Office Software)erfolgreich angreifen kann, zeigt die Überlegenheit dieses zutiefst agilen Ansatzes gegenüber den “trägen Dinosauriern”.

Wie bekommt man ein Projekt klein? Die wichtigsten Regeln lauten:

1. Nutzen verstehen: Ein tiefes Verständnis der Abläufe und des Wertschöpfungsbeitrags hilft, die wichtigen Dinge zuerst zu tun. Das führt in der Regel dazu, dass zunächst unschöne Lösungen entstehen, die erst in den nächsten Schritten näher an das Zielszenario gebracht werden. Martin Fowler erzählt die Geschichte einer Web-Anwendung, bei der zunächst die Web-Formulare einfach ausgedruckt wurden, um sie anschließend manuell in dem Host-System zu erfassen (siehe [2] RollerSkateImplementation). Nicht schön, aber innerhalb weniger Tage zu realisieren. Erst mehrere Wochen später stand die volle Ankopplung zur Verfügung. Der Nutzen konnte aber sehr schnell generiert werden.
2. Kleinste Schritte: In den allermeisten Projekten werden viel zu große Schritte gemacht. Erst muss diese und jene Bibliothek gebaut werden, ein für alle Zunkunft verwendbares Framework entwickelt werden, oder das Problem geschachtelter Transaktionen in persistenten Objekten gelöst werde (alles sind reale Beispiele!). Damit schafft man massive Abhängigkeiten zwischen Teilteams und bläst Projekte künstlich auf. Wer die Technik wachsender Architekturen beherrscht und weiß, wie man Wucherungen rechtzeitig erkennt und vermeidet, kann in viel kleineren Schritten vorgehen - und dadurch viel kleinere und effizientere Projekte schneiden.
3. Vertrauen aufbauen: Anwender werden einen solchen Weg nur mitgehen, wenn sie das Vertrauen haben, dass aufgeschoben nicht aufgehoben bedeutet. Unsere Branche hat sich die letzten Jahrzehnten redlich Mühe gegeben, dieses Vertrauen zu verspielen. Es ist daher an uns, dieses verspielte Vertrauen wieder aufzubauen - nicht mit schönen Versprechungen und tollen Systemen, die lediglich auf der virtuellen Powerpointmaschine laufen, sondern zuverlässigen, häufigen Auslieferungen lauffähiger Software.

Diese Regeln ermöglichen es, dass die Beschränkung auf “kleine” Projekte keine Einschränkung darstellt, sondern ganz im Gegenteil einen wesentlichen, zusätzlichen Service für die Anwender bildet.