Die Welt der Softwareentwicklung ist einfach und perfekt. Änderungen im Umfeld und in den Anforderungen von Projekten sind zu vernachlässigen – in der Regel läuft alles absolut nach Plan.
Das klingt nicht nach eurem Projektalltag? Willkommen auf dem Boden der Tatsachen! Die Realität sieht tatsächlich anders aus: Statt in einer einfachen leben wir in einer hochkomplexen Welt.
Trotzdem werden bei klassischen Methoden der Softwareentwicklung fundamentale Aktivitäten der Entwicklung als separate Phasen in einer klar definierten Reihenfolge ausgeführt. Die Planungsphase findet dabei ganz zu Anfang und sehr ausführlich statt und reicht weit in die Zukunft. Mögliche Änderungen im Ablauf und an den Anforderungen werden nicht berücksichtigt. Stattdessen werden die Aktivitäten und Ergebnisse jeder Projektphase detailliert dokumentiert. Diese Dokumentation dient dann wiederum als Input für die darauffolgende Phase.
Obwohl diese klassischen Methoden sich selten an den realistischen Gegebenheiten in Softwareentwicklungsprojekten orientieren, werden agile Methoden häufig mit totaler Planlosigkeit gleichgesetzt. Aber woher stammt dieser Mythos? Hauptgrund ist eins der Axiome des agilen Manifests:
„Reagieren auf Veränderungen mehr als das Befolgen eines Plans.“
In Wikipedia ist der Projektplan folgendermaßen definiert: „Projektplan ist ein Begriff aus dem Projektmanagement und hält das Resultat sämtlicher Planungsaktivitäten in einem konsistenten Dokument oder mehreren kohärenten Dokumenten fest. DIN 69905 bezeichnet den Projektplan allgemein als "Gesamtheit aller im Projekt vorhandenen Pläne".“
Dieser Definition kann man entnehmen, dass der Plan über die gesamte Dauer (klassischer) Projekte sehr starr ist und kaum Veränderungen zulässt. Mit Agilität hat das wenig zu tun und dementsprechend kann man schnell auf den Gedanken kommen, dass ausgerechnet eine der Kernaussagen des agilen Manifestes zum Nicht-Befolgen des Projektplans, also zur Planlosigkeit aufruft.
Dabei spielt Planung natürlich auch in der agilen Softwareentwicklung eine große Rolle. Den Zusammenhang zwischen „Planung“ und „Agilität“ veranschaulichen wir im Folgenden anhand von Scrum, der bekanntesten agilen Softwareentwicklungsmethode.
Scrum dient der kontinuierlichen Verbesserung von Produktivität und Prozessen und folgt Demings PDCA-Zyklus.
Abb. 1: PDCA-Zyklus nach Demings
Dieser Zyklus ist ein Problemlösungsansatz bestehend aus den vier Phasen Plan – Do – Check – Act. Dabei wird der Lösungsansatz für ein Problem grob geplant, in kleinen Schritten zunächst umgesetzt und dann einem Realitätsabgleich unterzogen und optimiert. Schließlich wird dieser verbesserte Lösungsansatz in der Act-Phase angewendet, woraufhin der Prozess erneut in eine Planungs-Phase eintritt.
Abbildung 2: Scrum-Prozess und PDCA-Zyklus
Am Anfang eines Scrum-Projektes steht der Product Owner (PO). Er repräsentiert die Kundenbedürfnisse und erstellt zu Beginn eine Liste – das Product Backlog – mit Anforderungen und Kundenwünschen, die von der Produktvision abgeleitet werden und beschreiben, wie das Produkt am Ende sein soll. Er legt durch Priorisierung fest, in welcher Reihenfolge die Anforderungen zu bearbeiten sind. Damit beginnt auch ein Scrum-Projekt mit der Planungs-Phase.
Im Sprint-Planning-Meeting entscheidet das Team zudem über den Inhalt des nächsten Sprints und definiert einen Umsetzungsplan sowie das jeweilige Sprint-Ziel, das im Sprint-Backlog festgehalten wird. Die im Backlog festgelegte Planung darf während des jeweiligen Sprints nicht verändert werden. Nachdem der ein- bis vierwöchige Sprint gestartet ist, findet täglich ein kurzes Planungsmeeting – das sogenannte Daily – statt, um im Team abzustimmen, was an dem Tag zu tun ist.
Agile Maßnahmen sind daher bereits auf den ersten Blick alles andere als planlos. Sie setzen die Planungsphasen nur anders und insbesondere flexibler ein, als in klassischen Projekten und können so dem Anspruch, zu reagieren statt nur zu agieren gerecht werden.
Agile Softwareentwicklung geht sogar nicht weiter und bezieht die Planung nicht nur am Anfang, sondern während des Verlaufs des Projektes immer wieder mit ein.
Laut des agilen Manifest ist die höchste Priorität des Teams:
„den Kunden durch frühe und kontinuierliche Auslieferung wertvoller Software zufrieden zu stellen“.
Vergleicht man klassische mit agiler Auslieferung (Abbildung 3), steigt das Risiko für Misserfolge im Zeitverlauf des klassischen Projekts exponentiell an. Nach agiler Auslieferung wird der Wert der Software dagegen kontinuierlich im Projekt geschöpft und gesteigert. Das Risiko für Misserfolge hat zu Beginn des Projektes den höchsten Wert, nimmt jedoch durch die kontinuierliche Wertschöpfung im Projektverlauf stark ab.
Abb.3: Klassische vs. agile Softwareentwicklung
Das agile Manifest empfiehlt zudem, dass die funktionierende Software innerhalb weniger Wochen oder Monate geliefert werden soll, um schnelles Feedback über die Fortschritte und Probleme der Software im Projekt zu ermöglichen und so kosten einzusparen. Denn laut dem IBM Sciences Systems Institut sind die Kosten höher, je später ein Fehler in der Softwareentwicklung entdeckt und eine Veränderung vorgenommen wird (Abbildung 4). Beispielsweise ist der Aufwand, einen Fehler zu beheben, in der Testphase ungefähr dreimal so groß wie in der Entwicklungsphase – und die Kosten entsprechend auch.
Abb.4: Kosten in der Projektphase
Neben Daily und Sprint Planning gibt es im Scrum zwei weitere regelmäßige Meetings: das Review-Meeting und die Retrospektive.
Im Review stellt das Team die Ergebnisse – das auslieferbare Product Increment – dem Product Owner vor. Der Product Owner überprüft, inwieweit die Anforderungen umgesetzt und erfüllt wurden (CHECK) und nimmt ggf. entsprechende Änderungen am Product Backlog vor (ACT). Diese Check- und Act-Phase, die zur Verbesserung des Produktes dienen, werden im folgenden Schaubild dargestellt:
Abb.5: Check & Act zur Produktverbesserung
In der Retrospektive reflektiert das Team seine Zusammenarbeit sowie den Ablauf im Sprint und leitet daraus Maßnahmen für die Prozessoptimierung ab. Diese Verbesserungsmaßnahmen werden im nächsten Sprint implementiert und beobachtet. Es empfiehlt sich, max. 2-3 Maßnahmen nach jeder Retrospektive zu implementieren, um die Wirkungen jeder einzelnen Maßnahme möglichst genau erfassen zu können. Am Ende des neuen Sprints bewertet das Team den Erfolg der einzelnen Maßnahmen und behält, optimiert oder eliminiert sie gegebenenfalls.
Der Deming-Zyklus ist das „A und O“ der agilen Softwareentwicklung. Wie zuvor beschrieben, wird durch ihn bei der agilen Softwareentwicklung kurzfristig aber dafür häufiger geplant, um eine kontinuierliche Verbesserung anzustreben und das Risiko zu minimieren.
Seid ihr also immer noch der Meinung, dass agile Softwareentwicklung planlos durchgeführt wird? Aus meiner Sicht ist es vielmehr so, dass Agilität im Gegensatz zur klassischen Softwareentwciklung Planung mit Flexibilität vereint und so die Möglichkeit schafft, auf Veränderungen im Projekt – die mit Sicherheit eintreten werden – frühzeitig zu reagieren. So wird nicht nur Zeit sondern letzten Endes auch Kosten gespart.