Was passiert, wenn der zugesagte Endtermin eines Projektes zu platzen droht? Wir versuchen, den Termin zu retten, indem wir einfach noch mehr Leute in das Projekt stecken. „Wir schießen mit Ressourcen auf Projekte“ – so nannte ein Kunde dieses Verhalten kürzlich.
Nicht nur Tom de Marco warnt genau davor, wenn er sagt, ein langsames Projekt wird langsamer, wenn man die Anzahl der Teammitglieder erhöht. Das liegt unter anderem daran, dass für alle Beteiligten eine Einarbeitungszeit anfällt, das Team sich ggf. noch nicht kennt, die Skills unterschiedlich sind und der Abstimmungsaufwand generell steigt.
Das ist in agilen Projekten nicht anders. Ken Schwaber setzt hier einen sogenannten Drag Faktor an, der auf initale Schätzungen angewendet werden kann. Beispielsweise erhöht sich die Schätzung um den Faktor 0,35 wenn ein Team weniger als 3 Monate zusammengearbeitet hat, bei einem hohen technischen und Domänen-Know How. Der Faktor steigt auf 0,8 wenn das Know How entsprechend niedrig ist.
Trotzdem scheint man diesem Verhalten mit Argumenten schlecht begegnen zu können. Jetzt hatte ich kürzlich die Gelegenheit, in einem agilen Team messen zu können, was passiert, wenn man ein Team verdoppelt – also von 3 Teammitgliedern auf 6 Teammitglieder erhöht. Und ja, ich kann rechnen: Aus 3+3 wurde 1,5. Statt also doppelt so viel zu erreichen, halbierte sich der Output des Teams anfangs.
In dem Projekt arbeiteten wir mit Scrum und einer auf Story Points basierenden Velocity. Die Velocity des Teams war nach 3 Sprints bei einem Wert von 10 bzw. einer Durchschnitts-Velocity von 7 angelangt. Das heißt, das Team liefert pro Sprint voraussichtlich User Stories (also Output bzw. Funktionalität) im Wert von 10 bzw. 7 Story Points. Obwohl allen Beteiligten klar war, dass die Velocity sinken wird, wenn sich die Teamgröße verdoppelt, waren wir dann doch alle überrascht von der tatsächlichen Auswirkung (siehe Grafik).
Im ersten gemeinsamen Sprint 4 hat sich die absolute Velocity mehr als halbiert. Erst in Sprint 6, also nach 2 Sprints ist diese wieder gestiegen auf 6 (nicht auf 10). Insgesamt hat es ca. 6 Sprints gedauert, bis sich die durchschnittliche Velocity wieder bei 7 eingependelt hat.
Barry Böhm hatte schon in den 80ern nachgewiesen, daß ab einer bestimmten Projektgröße Verdoppelung der Projektmitarbeiter die Projektlaufzeit nicht halbiert sondern verdoppelt.
Durch Einsatz von Modellierung kann die Velocity im Team verbessert werden und die Zuführung von Ressourcen zu Zeitgewinn und nicht zu Zeitverlust führen.
Liebe Susanne,
paradoxe Mathematik mit einer plastischen Essenz – sehr schön:
3+3 –> 1,5 (kurzfristig, ist zu erwarten)
3+3 –> 3 (mittelfristig, ab Sprint 7)
3+3 –> 3 bis 5 (langfristig, eventuell)
das sind ungefähr die Erfahrungen, die wir in unzähligen Projekten machen – unabhängig vom „klassischen“ oder „agilen“ Vorgehen.
Passend dazu das Buch „The Mythical Man-Month“ von Frederick Phillips Brooks, Jr. und sein Brooks‘ Law:
„“Nine women can’t make a baby…“
http://boeffi.net/blog/brookss-law/
CU
Boeffi