Wann sollte man eigentlich Agile verwenden? Die Frage wird immer mal wieder gestellt wenn es darum geht zu entscheiden welche Methode denn die richtige ist um eine Aufgabe zu lösen. Die Frage ist auch gut am Anfang zu stellen, denn wenn das Projekt einmal läuft und aufgesetzt ist einen Wechsel zu vollziehen ist nicht nur hinderlich, eher kommt es einem Neustart gleich.

Das wichtigste Kriterium ist das Thema Changes – also Änderungen die an dem Vorhaben auftreten (oder auftreten können). Hier über die Möglichkeit des auftretens zu sprechen, bedeutet Agile als Risk Mitigation einzusetzen. Ein weiteres wichtiges Kriterium ist, können Teile des Projektes alleinstehend als ein Paket abgearbeitet werden und sind die Pakete adaptiv? Das bedeutet der Einsatz eines Agile Frameworks zur Umsetzung eines Vorhabens ist dann zu betrachten, wenn der Weg und insbesondere das Ziel gar nicht so klar ist.

Warum auch der Weg? Projekte die nach der Wasserfallmethode abgearbeitet werden können ihr Ziel klar beschreiben, haben jedoch aufgrund verschiedener Bedingungen einen unterschiedlichen Weg zum Ziel. Projekte nach der traditionellen Wasserfallmethode sind vorhersehbar, Agile Projekte sind adaptiv. Adaptiv bedeutet Features oder Deliverables aus einem Release können in einem folgenden Release genutzt werden. Die zu implementierenden Features werden Priorisiert und dann einem Release zugewiesen.

Auf diesem Weg sind häufig klassiche Entwicklungstätigkeiten zu absolvieren die im vorraus nicht oder nur schwer einzuschätzen sind. Diese Entwicklungstätigkeiten sind notwendig um den Weg zu durchlaufen um zum Ziel zu gelangen. Die zu implemntierenden Features werden durch eine Priorisierung (beispielsweise nach MoSCoW) einer Iteration zugewisen.
Bei dem Thema Entwicklungsmöglichkeiten (Development process) gilt es ein generellen Ablauf einzuhalten. Unabhängig von der Methode ist dieser ist immer:

  • Specification
  • Design
  • Build
  • Integrate
  • Test
  • Implement

Das ist egal ob es sich dabei um den klassichen Fall einer Softwareentwicklung oder einer Migration handelt. Specification und Design sind Paperwork. Build, Integrate, Test, Implement werden immer am Code oder and der Hardware/ Software durchgeführt. Das Ergebnis ist dann ein Stück „working software“ oder aber ein „working package„.

Es bietet sich nun an diesen Entwicklungsschritt in einem Sprint zu organisieren. Zurück zur Frage wann ist Agile sinnvoll, wann sollte man es einsetzen? Mit dem Weg und dem Ziel hat man 2 Kriterien die helfen eine Auswahl zu treffen, jedoch wird es nicht funktionieren, wenn nicht weitere Kriterien passen.

Unter anderem muss das Team auch Agile konform aufgesetzt sein. Scrum beispielsweise kennt keine Hierachien. Der Dienstleister und Kunde müssen personelle Strukturen besitzen, welche auf Agile abgestimmt sind. Der Kunde muss sich intensiver in das Projekt einbringen, wenn notwendig auch ad hoc Entscheidungen treffen.

Agile ist time boxed. Das bedeutet in einer festgelegten Zeit werden Features gebaut die dann ein Stück „working package“ darstellen. In unüberschaubaren (oder komplexen) Projekten mit diversen Unbekannten ist für die Wasserfallmethode basierend auf zeitlichen Vorgaben und Annahmen zu Vorraussetzungen und Zielen viel Spekulation notwendig. Die Ziele werden nicht erreicht weil genau diese Annahmen und zeitlichen Spekulationen falsch sind. (Das weiß man leider meist erst hinterher) Das Ergebnis ist ein hoher Frustrationslevel beim Senior Management und immer wieder die Frage „Wann haltet Ihr die Ziele ein, wann bekommen wir einen gültigen Plan, ….“. Endet diese Situation oftmals in Mikromanagement, täglichem tracking und der Management attention die niemand im Projekt wirklich benötigt und auch nicht immer hilft.

Agile hilft, in dem der Entwicklungsprozess um ein Stück „gemeinsamen Erfolg von Dienstleister und Kunde“, also ein „working package“ auf dem sich ein weiteres Paket aufbauen lässt zu fixieren. Das ist üblicherweise die Sprint Zeit von 2-4 Wochen. Wenn man so will, ist es der Weg der kleinen Schritte. Der Einsatz des Frameworks und die Nutzung der Artefakte aus dem Agile Framework sorgen dann für ein fortkommen auf dem Weg zum Ziel. Das ist keinesfalls identisch mit Meilensteine in kürzeren Zeitenräumen abzustecken.

Garantien für den Erfolg gibt es leider nicht aber die Transparenz zum aktuellen Stand des Projektes und der notwendigen Schritte eines „working packages“ sind um ein vielfaches höher als im Vergleich zur Wasserfallmethode.

Vergleicht man nun beide Ansätze miteinander und geht von dem normalen Fall aus, in dem verschiedene Änderungen das Projekt begleiten, so hat man mit dem Agile Ansatz eine detailiertere Möglichkeit auf den Gesamterfolg einzuwirken. Nach jedem Sprint liegt ein „working package“ vor und durch ein Review lässt sich die Situation kontrollieren, steuern, managen. Der time boxed approach gibt die Möglichkeit konkret mit einem „working package“ zu hantieren und Ideen einfließen zu lassen. Stichwort Changes, unbekannte Faktoren, Annahmen.

Im worst case – ist das Projekt beendet und man hat die Erkenntnis bevor die träge Maschine eines Wasserfallprojektes lange Zeit in die falsche Richtung gelaufen ist.