Agile Programmierung ist zur Zeit ein großer Hype im Bereich der Software-Entwicklung. Es gibt kaum ein Unternehmen, welches sich noch nicht mit dem Thema befasst hat. Traditionelle Projektformen - wie das Wasserfallmodell - sind in der Vergangenheit aufgrund zunehmender Komplexitäten an ihre Grenzen gestoßen. Man denke an viele öffentlich bekannt gewordene Projekte, deren Budgets am Ende hoffnungslos überzogen wurden.
Um dies in Zukunft zu vermeiden, wurde die Projekttechnik der "agilen Programmierung" entwickelt, bei der am Anfang nicht das Pflichtenheft eines völlig durchgeplante Endprodukts steht, sondern eine Vision, in deren Richtung man sich iterativ von Sprint zu Sprint bewegt. Ein Sprint ist dabei der Zeitraum von einer Feature-Definition zur nächsten (Featurebasiertes Vorgehen). Für einen Sprint werden als Empfehlung in der einschlägigen Literatur für ein 8-Mann/Frau-Entwicklerteam als Best-Practice etwa 4 Wochen veranschlagt.
Die Eignung eines Projekts
Es gibt zunächst einmal einen Zusammenhang zwischen der Projektgröße und der Eignung eines Projekts für die agile Programmierung. "Je größer ein Projekt ist, desto hilfreicher oder notwendiger ist ein featurebasiertes Vorgehen" (Oesterreich, Weiss in "APM - Agiles Projektmanagement, dpunkt-Verlag 1. Aufl. 2008, S. 50). Dies heißt im Umkehrschluss, je kleiner ein Projekt, umso weniger geeignet ist es. Warum ist das so?
Die Anlaufzeit für ein agiles Projekt beträgt in der Regel ca. 3 Monate, bis man einigermaßen Stabilität in den Prozess gebracht hat. Kleine Projekte sind meist auf kurze Projektlaufzeiten ausgelegt, z.B. 3 oder 6 Monate. Außerdem werden sie mit wenigen Mitarbeitern durchgeführt (z.B. typischerweise 3-4). Ein solches Projekt ist also schon zuende, bevor sich die Projektorganisation stabilisieren kann. In diesen Fällen ist die Methode "vollständiges Pflichtenheft" immer noch vorzuziehen.
Befassen wir uns aber mit einem etwas anderen Beispiel für ein "kleines Projekt". Ein Unternehmen setzt 3-4 Personen über einen längeren Zeitraum in einem Software-Projekt ein, das über einen längeren Zeitraum, z.B. 1 Jahr laufen soll. In diesem Fall lohnt es sich natürlich, über agile Methoden nachzudenken.
Einfluss Projektgröße
Typisch für Empfehlungen bezüglich der Iterationsdauer wird in der folgenden Tabelle der Vorschlag von Oesterreich, Weiss zitiert:
| Maximale Projektgröße | Iterationsdauer |
|---|---|
| ca. 4 Personen | 2-4 Wochen |
| ca. 10 Personen | 3-5 Wochen |
| ca. 40 Personen | 6-8 Wochen |
| über 40 Personen | 6-10 Wochen |
Tab. 1: Iterationsdauer in Abhängigkeit der Projektgröße (s. ebenda, S. 56)
Ich möchte im folgenden nur den Unterschied zwischen Projekten mit ca. 4 Personen und mit ca. 8-10 Personen diskutieren, weil diese Projektgrößen vor meinem Erfahrungshintergrund den häufigsten Fall darstellen und für Softwareprojekte in kleinen und mittleren Unternehmen typisch sind.
Ich halte die Empfehlung der Autoren Oesterreich und Weiss, deren Buch zum Thema ich sehr schätze und die bei ihren Angaben im wesentlichen den Common Sense der Experten auf dem Gebiet der agilen Programmierung wiedergeben, für problematisch.
Ich möchte dies im folgenden begründen.
Wertefundament
Zunächst einmal gehe ich kurz auf das Wertefundament der agilen Programmierung ein. Dessen Bedeutung wird in jedem Fachbuch zum Thema betont.
Allerdings äußern sich Oesterreich/Weiss diesbezüglich sehr zurückhaltend. Sie widmen dem Thema "Werte" zwar ein ganzes Kapitel, "setzen diese Werte aber, gerade um erfolgreich Agilität einzführen, nicht voraus" (vgl. S. 21). Was sie genau damit meinen, bleibt ein wenig unklar. Selbstverständlich kann man "Timeboxing" und "featurebasiertes Vorgehen" auch unabhängig einer bestimmten Wertekultur oder gar von agiler Programmierung als unabhängige Bausteine in Kombination mit allen möglichen Projektmethoden praktizieren. Man macht dann halt eine eigene Methode daraus.
Offensichtlich wollen sie mit dieser Anmerkung im Gegensatz zu anderen Autoren das Thema Werte nicht allzu hoch hängen. Gleichwohl zählen sie interessante und wichtige Aspekte einer Werte-orientierten Projektorganisation auf, z.B. (vgl. ebenda, S. 21 ff.):
- Führung als Dienstleistung
- Eigenverantwortliches Arbeiten
- Zwischen Freiheit und Vorschrift
Die Auflistung dieser Kapitelüberschriften und deren Inhalt (auf den ich hier nicht näher eingehen möchte) kann man ähnlich zusammenfassen, wie es unser Bundespräsident gerne in seinen Reden formuliert:
"Verantwortung in Freiheit"
Mit dieser Forderung hätte man vor 15 Jahren auch die Konzepte für Team- und Gruppenarbeit in den 90er Jahren überschreiben können. In der Automobilindustrie und nicht nur dort wurde Gruppen- und Teamarbeit populär als eine Antwort auf die damals überraschende Wettbewerbsstärke der Japaner.
Damals reiste ein Team aus MIT-Experten nach Japan und schaute sich an, womit die Japaner ihre Exportweltstärke erreicht hatten. Das Ergebnis fassten sie zusammen in einer Studie mit dem Titel "Lean Production" (Womack, J.; Jones, D.; Roos, D.: The Machine that changed the World: The Story of Lean Production. Harper Collins, New York 1990).
Gruppen- und Teamarbeit war ein Element von "Lean Production" und zwar ein sehr wichtiges. Weitere Elemente wurden wurden unter den Stichworten "Continous Improvement" (Kaizen), "Qualitätszirkel", "Process Redesign", "Zero Defect" oder "Total Qualitity Management" verbreitet bzw. vermarket.
Offensichtlich erfahren einige dieser Ansätze im Zusammenhang mit der agilen Programmierung eine Renaissance, z.B. auch das Stichwort "Kontinuierliche Verbesserung".
Verantwortung in Freiheit
Was bedeutet nun "Verantwortung in Freiheit" ganz praktisch?
Es bedeutet, dass Mitarbeiter mehr Freiheit bei ihrer Aufgabenerfüllung bekommen, dafür aber auch mehr Verantwortung. Nicht mehr und nicht weniger.
Worin besteht dieses "Mehr" an Freiheit in einem Software-Entwickler-Team? Die Antwort lautet:
- Mehr Freiheit, wann man eine Aufgabe erledigt (innerhalb des Sprints).
- Mehr Freiheit, wie man eine Aufgabe erledigt.
- Mehr Freiheit, wer eine Aufgabe erledigt (im Team).
Die Verantwortung des Entwicklerteams ist es dann, zum Ende des Sprints eine vereinbarte Leistung in der erforderlichen Qualität pünktlich zu liefern.
Vergegenwärtigt man sich noch einmal, warum man überhaupt agile Programmierung praktiziert, so ist genau der letzte Punkt der entscheidende.
Nur, wenn in jedem Sprint von Anfang bis Ende des Projekts Termine und Qualität gehalten werden, erzielt man Vorteile.
Gibt es dagegen in jedem zweiten oder dritten Sprint einen Terminverzug, so gibt es Stau wie auf der Autobahn und sofort sind Büdgets, Meilensteine und geplanter Endtermin in Gefahr.
Bedeutung von Freiheitsgraden
Kommen wir zurück zu unserem Thema.
Was passiert mit der Freiheit des Entwicklerteams und der Termintreue, wenn ich bei halber Gruppengröße den Sprintzeitraum halbiere? Dazu zunächst ein Gedankenexperiment, welches dann später verallgemeinert wird.
Nehmen wir an, wir haben ein Entwicklerteam von 8 Leuten und die einzige Störung, die während eines 4-Wochen-Sprints auftritt, sind zwei Krankheitsfälle von jeweils 2 Wochen.
Dies bedeutet einen Ausfall von 12,5 %. Habe ich die Gruppe mit einem Workload von 80% belastet, bekomme ich keine Probleme mit dem Endtermin.
Was passiert, wenn ich jetzt die Gruppengröße halbiere, den Sprintzeitraum bei 4 Wochen belasse und immer noch einen Workload von 80% habe.
Bei 4 Gruppenmitgliedern halbiert sich die Wahrscheinlichkeit, dass zwei Mitglieder im Sprintzeitraum krank werden. Die Dauer des Ausfalls dagegen ist unabhängig von der Gruppengröße und dem Sprintzeitraum. Es fällt also im Mittel nur ein Mitglied für zwei Wochen aus. Der Gesamtausfall in diesem 4er-Teamarbeitssystem beträgt dann genauso wie in dem 8er 12,5%. Die Termine sind demnach nicht gefährdet.
Was passiert jetzt, wenn ich die Gruppengröße halbiere und den Sprintzeitraum ebenfalls?
Dann habe ich ein Problem! Es kann sein, dass ich in einem Sprintzeitraum einen Krankheitsfall habe, der genauso lange dauert, wie der Sprintzeitraum, nämlich 2 Wochen. Der Kapazitätsausfall beträgt dann 25%. Im nächsten Sprintzeitraum hätte ich dann einen Kapazitätsausfall von 0%. Wenn sich der Eintrittszeitpunkt des Krankheitsfalls nach hinten verschiebt, gibt es eine Reihe von Tagen, bei denen ich einen Kapazitätsausfall von mehr als 20% habe, entweder im ersten oder im zweiten Sprintzeitraum. Ein Statistiker könnte den Ausfall quantifizieren. Uns reicht hier der grundsätzliche Zusammenhang.
Das Problem ist, dass ich in diesen Fällen mit einer höheren Wahrscheinlichkeit einen Terminverzug in einem der beiden Sprintzeiträume habe, der nicht mehr durch den eingeplanten Puffer aufgefangen wird. Da nützt mir der nicht genutzte Puffer von bis zu 20% im anderen Sprint auch nichts, denn der ist ja für unabhängig auftretende Ausfälle dort vorgesehen, nicht dafür, Terminverzüge aus dem vorhergehenden Sprint aufzufangen. Auf der Autobahn werden Verzögerungen durch einen kurzzeitig langsamer fahrenden Autofahrer, der dann wieder Gas gibt an Stellen, wo er einen größeren Abstand vorfindet, auch nicht mehr im Mittel kompensiert.
Das deutet darauf hin, dass es nicht sinnvoll ist, bei halbierter Gruppengröße auch den Sprintzeitraum zu halbieren.
Es gibt noch weitere Nachteile einer Halbierung des Sprintzeitraums. Machen wir also eine Liste ohne Anspruch auf Vollständigkeit, nehmen aber den bisher diskutierten Punkt der Vollständigkeit halber mit auf:
- die Elastizität, auf Störungen zu reagieren, nimmt ab (siehe Gedankenexperiment),
- doppelte Anzahl von Sprintsitzungen und verbundenen Besprechungen (Ausnahme: Daily Meeting),
- extrem verringerte Auswahlmöglichkeiten des einzelnen Entwicklers aus dem Aufgabenpool.
Auf den letzten Punkt möchte ich noch kurz eingehen, um dann am Ende mögliche Einwände gegen die hier aufgestellte Behauptung zu diskutieren.
Bedeutung von Auswahlmöglichkeiten
Wozu sind Auswahlmöglichkeiten aus einem Aufgabenpool in einem Team gut?
Das mache man sich an einem Extrembeipiel deutlich. Man stelle sich vor, ein Entwickler bekommt seine Arbeitsaufgabe sagen wir - von einem Interaktionsdesigner - um 12 Uhr mittags mit der Vorgabe, die Aufgabe bis nächsten Tag 12 Uhr Mittags fertigzustellen. Der Sprintzeitraum beträgt dann einen Tag, die Teamgröße 1 Mitarbeiter (ohne den Interaktionsdesigner). Der Arbeitsaufwand wurde dabei mit 8 Stunden von einem Vorgesetzten veranschlagt.
Termineinhaltung ist bei so einem Arbeitsauftrag ziemlich unwahrscheinlich. Warum ist das so?
Problematik Aufwandsabschätzung
Fehlerhafte Aufwandsabschätzungen für Teilaufgaben sind bei Softwareentwicklung nicht vermeidbar.
Auch wenn die Führungskraft noch so viel Erfahrung besitzt, sie kennt nicht alle aktuellen Rahmenbedingungen der nächsten 8 Stunden (Zustand des Arbeitsplatzes, Einarbeitungsniveau, unbekannte Fehler im Softwareprodukt, usw.)
Man betrachte beispielsweise die Probleme der Cross-Browser-Entwicklung. Da funktioniert etwas auf dem einen Gerät, auf dem anderen nicht und es ist viel Recherche und Experiment erforderlich, um das Problem zu lösen. In den Blogs sehr erfahrener Software-Spezialisten liest man häufig: "Jetzt habe ich wieder drei Tage mit diesem Problem verschwendet ..." oder ähnliches.
Natürlich kann man versuchen, eine Olympia-Manschaft zu bilden. Oder einen Freelancer in das Team zu setzen, der sich mit Browser-Bugs so auskennt, dass er sie als Weichen verwenden kann und außerdem alle genialen Tricks beherrscht, um das letzte aus einem Layout herauszukitzeln und der dabei noch so schnell ist, dass er ein noch nicht ausgebildetes Team kompensieren kann, dabei die vom Management geforderten Meilensteine garantiert und die restlichen Teammitglieder gleichzeitig noch ausbilded. Das sind nicht ganz unübliche Vorstellungen diverser Unternehmen. Good luck!
Auch mit noch so erfahrenen Leuten, die an der Aufwandsschätzung beteiligt sind, lässt sich die genaue Dauer einer Softwareaufgabe nicht vorhersagen. Je enger der Zeitraum, der für die Erledigung angesetzt wird, umso wahrscheinlicher wird die Terminüberziehung. Und jeder Terminverzug erhöht in einem Projekt die Gefahr des Staus.
Auch psychologische Faktoren spielen eine wichtige Rolle für Fehleinschätzungen. Hierzug gehören Vorgesetzte, die vielleicht unbewußt subtilen psychologischen Druck erzeugen. Da reicht oft schon ein Stirnrunzeln eines Vorgesetzten und schon stimmt der motivierte Entwickler einem viel zu knapp kalkulierten Termin zu.
Einfluss der individuellen Disposition
Es gibt viele Aufgaben, die man lieber morgens erledigt. Stößt man dort auf ein kleines Problem, so gerät man leicht in den Nachmittag, wo die Konzentration nachlässt.
Sich mit der Aufgabe dann weiterzubeschäftigen, macht im Sinne eines guten Selbstmanagements oft keinen Sinn mehr. Stattdessen sollte man die Fertigstellung auf den nächsten Tag verschieben und in der restliche Arbeitszeit leichtere Aufgaben erledigen, vielleicht ein paar CSS-Formatierungen verbessern oder ein paar kleine Bugs beseitigen.
Gut, wenn man sich dann solche Aufgaben aus einem großen Pool aussuchen kann.
Einfluss Qualifikation
Ein großer Aufgabenpool ist von Vorteil, wenn es unterschiedliche Qualifzierungsniveaus in einem Team gibt, die sich idealerweise schnell angleichen.
Es hat keinen Sinn, einem Projektnovizen sofort die schwerste Aufgabe zu übertragen. Je kleiner der Auftragspool, umso schneller wird er aber mit Aufgaben konfrontiert, die er noch nicht lösen kann. Am Ende eines Sprints nimmt der Auftragspool naturgemäß ab. Bei einer kurzen Sprintdauer wird es dann schnell eng für ihn.
Es macht einen großen Unterschied, ob ein neues Teammitglied dann erst 8 Arbeitstage oder schon 3,5 Wochen eingearbeitet ist.
Vorteile großer Auftragspools
Große Aufgabenpools zusammen mit einem längeren Erledigungshorizont haben also folgende Vorteile:
- Sie gleichen falsche Vorgabezeiten aus, insbesondere bei stark streuenden Schätzungen, wie sie üblicherweise bei Software auftreten.
- Sie ermöglichen ein besseres Selbstmanagement, indem sie dem einzelnen Terminmitglied erlauben, seine variable Tages-Disposition zu berücksichtigen, etwa Zeiten hoher und schwacher Konzentrationsfähigkeit.
- Sie ermöglichen höhere Spielräume für die Angleichung unterschiedlicher Qualifikationsniveaus.
Was passiert aber mit dem Handlungsspielraum für das einzelne Teammitglied, aus verschiedenen Aufträgen aus einem Pool auszuwählen, wenn man den Sprintzeitraum halbiert?
Er verringert sich um mehr als die Hälfte!
Die Begründung dürfte einleuchtend sein. Die Halbierung eines 8er-Team führt zu einer Halbierung der Auswahlmöglichkeiten über den gesamten Sprintzeitraum. Zu jedem Zeitpunkt kann jedes Mitglied im 8ter-Team aus der doppelten Auftragszahl auswählen. Die zeitliche Halbierung reduziert den Zeitraum noch einmal, da wiederum die Auftragszahl, die eingesteuert werden kann, aus diesem Grunde halbiert werden muss.
Vor diesem Hintergrund müsste man den Sprintzeitraum bei einer Halbierung der Teamgröße sogar vergrößern, wenn man die Grundidee der agilen Programmierung sehr ernst nimmt.
Mögliche Einwändungen
Kommen wir nun zu den möglichen Einwändungen gegen die hier formulerite Behauptung bzw. Forderung, bei Teamgrößen von weniger als 8 Mitgliedern den Sprintzeitraum bei 4 Wochen zu belassen.
"Es handelt sich um eine abstrakte Argumentation, die zudem an einem Spezialfall von Störungen aufgehängt ist - Krankheit im Team - der zudem gegenüber den häufigeren anderen Störungen untypisch lang ist. Kürzere Störungen, etwa Stromausfall, lassen sich leichter ausgleichen."
Alles was in einem Entwicklerteam die Termintreue gefährdet, kann als Störung bezeichnet werden. Vielleicht sollte man besser von "Unvorhersehbarkeiten" sprechen. Dazu gehören:
- Krankheit,
- vor allem falsch geschätzte Zeitvorgaben,
- quer eingesteuerte Arbeitsaufgaben, z.B. die Einarbeitung eines neuen Mitarbeiters,
- Stromausfälle, Betriebsfeiern, nicht funktionierende Hilfsmittel, Tools oder Entwicklungssysteme, fehlende Rechte oder andere bürokratische Hindernisse, Abhängigkeiten von anderen Projektgruppen, etc.
Solche Unvorherbarkeiten sind dadurch charakterisiert, dass sie bezüglich Auftretenswahrscheinlichkeit und Dauer unabhängig von der Teamgröße und der Sprintdauer sind. Störungen addieren sich mit den geplanten Aufgaben zur Gesamtlast des Systems.
Man könnte so ein System auch mit einem Rohr vergleichen, durch das ein bestimmtes Volumen Tennisbälle hindurch geschickt wird. Sowohl Arbeitsaufgaben als auch Störungen sind Tennisbälle mit jeweils unterschiedlichen Durchmessern. Diese Tennisbälle besitzen eine gewisse Reibung sowohl gegenüber der Rohrwand als auch gegeneinander.
Ohne das mathematisch ausrechnen zu müssen dürfte klar sein, dass bei einem engeren Durchmesser, z.B. dem halben, die Wahrscheinlichkeit für eine Verstopfung zunimmt, auch wenn man die Durchflußmenge proportional anpasst.
Hätte man die Möglichkeit, auch die Durchmesser der Tennisbälle proportional zu verkleinern, bekäme man keine Probleme. Aber diese Möglichkeit gibt es nicht.
Demnach wirken sich Störungen in einem System mit kleinem Durchmesser stärker aus. Damit ist es egal, ob ich das Gedankenexperiment am Beispiel von Krankheitsfällen ausarbeite oder anhand anderer Störungen.
"Die indirekten Bereiche (Produktmanagement, Interaktionsdesigner, ...) haben bei 4er-Teams weniger zu tun und sind dann bei 4-Wochen-Sprints nicht ausgelastet."
Die wirkliche Argumentation muss sein, dass sich für diese Bereiche die Arbeit vergrößert. Der Rüstaufwand für die Planung steigt, weil man ja doppelt soviele Sitzungen bewältigen muss. Grundsätzlich gilt außerdem der gleiche Zusammenhang bezüglich der Folgen von Störungen, wie im Team. Es kann natürlich sein, dass die indirekten Bereiche von der Personalstärke so bemessen sind, dass sie bei einem 4er-Team nicht ausgelastet sind. Hier sollte man schauen, ob man diese Personen nicht einem zweiten Projekt zuordnet oder ob man die Personalstärke nicht auch halbieren kann, was natürlich schwierig ist, wenn man z.B. nur einen Interaktionsdesigner dem 4er-Team zugeordnet hat. Sollte dieser dann nicht ausgelastet sein, wird man ihm wohl andere Aufgaben zusätzlich übertragen müssen.
"Das hab ich ja noch nie gelesen. In jedem Fachbuch steht, dass man bei 4er-Teams gegenüber 8er-Teams den Sprintzeitraum verkürzen kann."
Man sollte niemals etwas übernehmen von anderen, das einem nicht selbst plausibel gemacht werden kann. Experten sind nicht dazu da, einem vorzuschreiben, wie man etwas zu tun hat, sondern einem das Verstehen eines Zusammenhangs zu ermöglichen. Und mir jedenfalls ist bisher nicht klar, warum man den Sprintzeitraum bei halber Gruppengröße reduzieren darf. Sorry, I am not convinced!
"Das fehlte noch, dass ich 4 Wochen ein 4er-Team laufen lassen muss und zwischendrin keine Erfolgskontrolle machen darf."
Ja, das ist wohl der tatsächliche Grund, warum sich dieser Vorschlag, den Sprintzeitraum zu halbieren, als Common Sense so leicht durchgesetzt hat. Jeder übernimmt gerne das, was seinem Grundinstinkt entgegenkommt. Und die Halbierung des Sprintzeitraums kommt dem Grundinstinkt entgegen, das Arbeiten des Teams stärker zu kontrollieren. Das Extrem ist die Übertragung einer einzigen Arbeitsaufgabe an eine einzige Person mit der Aufforderung: "Bitte in 8 Stunden erledigen"! Damit konterkariert man natürlich das angestrebte Grundprinzip der agilen Programmierung "Verantwortung in Freiheit". Das ist aber nicht nur so ein hehrer Wert, sondern eine - wenn man so will - organisatorische Erforderlichkeit zur Effizienzsteigerung. Dass damit gleichzeitig den Bedürfnissen der Team-Mitglieder Rechnung getragen wird - ein höherer Handlungsspielraum gilt nach arbeitswissenschaftlichen Kriterien als Persönlichkeitsförderlich -, ist dann zusätzlich zu begrüßen.
Es geht um Freiheitsgrade bei der Aufgabenbewältigung, die notwendig sind, das Flexiblitätspotential des Teams optimal zu nutzen. Es geht um eine organisatorische Erweiterung des Handlungsspielraums aufgrund der nicht vollständigen Vorausplanbarkeit von Entwicklungsaufgaben. Genau deshalb wurde agile Programmierung erfunden. Wer das nicht mit seinem Führungsstil in Einklang bringen kann, der sollte beim Wasserfall-Modell bleiben.
Zusammenfassung
Ich jedenfalls würde empfehlen, auch bei einer Verkleinerung der Teams bei einem Sprintzeitraum von einem Monat bzw. 4 Wochen zu bleiben. Es erhält weitgehend (nicht ganz, denn eigentlich müsste man den Zeitraum sogar etwas vergrößern) den Handlungsspielraum der Teammitglieder und fördert damit:
- die Flexibilität, auf Störungen zu reagieren,
- die Möglichkeiten des Selbstmanagements und
- die Angleichung unterschiedlicher Qualifikationsniveaus.
Es gibt zwei wichtige Parameter bei der agilen Programmierung: Workload und Rhythmus. Nur wenn es gelingt, nach spätestens drei Monaten diese beiden Parameter bis zum Ende des Projekts ziemlich konstant zu halten, kann man von gelungener agiler Programmierung sprechen.