Wenn ein Unternehmen ein neues Software-Entwicklungsprojekt plant, stellt sich schnell die Frage, nach welchem Vorgehensmodell das Projekt organisiert werden soll: klassisch, mit der Planung des gesamten Projektverlaufs inklusive aller Meilensteine im Vorfeld, oder agil, indem die gewünschten Arbeiten in mehreren Iterationen durchgeführt werden? Die Sicherheit im Hinblick auf die technischen und fachlichen Anforderungen ist für diese Entscheidung ein bedeutender Faktor, der in diesem Artikel genauer beleuchtet werden soll.
Umgang mit Unsicherheit in klassischen und in agilen Vorgehensmodellen
Klassische Vorgehensmodelle erfordern zu Beginn des Projekts eine umfangreiche Vorausplanung und einen hohen Detaillierungsgrad in den Spezifikationen. Wenn sehr klar beschrieben werden kann, wie die gewünschte Leistung auszusehen hat, und wenn auch während des Projektverlaufs nicht mit Änderungen zu rechnen ist, kann ein klassisches Vorgehensmodell mit seinen klar abgegrenzten und nacheinander ablaufenden Phasen die richtige Wahl sein. Diese Form der Projektorganisation erfordert in der Regel, dass das Projektteam bereits ähnliche Projekte durchgeführt hat und z.B. auch keine technischen Unsicherheiten bestehen, die den ganzen Projektplan schnell kippen können.
Abb. 1: Vorgehen nach dem Wasserfallmodell
Besteht hingegen keine Sicherheit über die konkreten Anforderungen oder gibt es technische Unwägbarkeiten, sind Änderungen im Projektverlauf wahrscheinlich. In diesem Fall kann ein agiles Vorgehensmodell seine Stärken ausspielen.
Dabei setzen agile Teams in erster Linie auf den zunehmenden Erkenntnis- und Erfahrungsgewinn im Verlauf des Projekts und gehen die mit den größten Unsicherheiten verbundenen Aspekte des Projekts zuerst an. So wird die Projektplanung von Iteration zu Iteration verlässlicher. Mit der regelmäßigen Durchführung von Retrospektiven lassen sich Verbesserungspotenziale fortlaufend aufspüren und umsetzen.
Abb. 2: Vorgehen nach Scrum
Lange Vorausplanung in einem dynamischen Umfeld führt häufig zu Frust
Bei der Anwendung eines klassischen Vorgehensmodells auf ein sehr dynamisches Projektumfeld entsteht häufig ein zentrales Problem: Obwohl Unsicherheit darüber besteht, wie das Ergebnis der Arbeit am Ende konkret aussehen soll (fachlich und/oder technisch), wird ein hoher Detaillierungsgrad der Spezifikationen gefordert, damit die nachfolgende Produktionsstufe mit den Vorgaben arbeiten kann. Auch Schätzungen können sich als vollkommen unzureichend herausstellen. Einarbeitungszeiten in neue Technologien, Zusatzaufwände durch Fehlentscheidungen ... die gefühlte Sicherheit der Vorausplanung ist oft eine trügerische.
Im Projektalltag müssen Teams dann feststellen, dass Anpassungen am Anforderungskatalog notwendig sind, weil man neue Anforderungen identifiziert hat, weil sich Inhalte oder Prioritäten von Anforderungen verändert haben oder auch, weil Anforderungen hinfällig geworden sind.
82 Prozent aller Projekte, die nach der sog. Wasserfallmethode realisiert werden, haben deshalb mit massiven Problemen im Hinblick auf mindestens einen der Erfolgsfaktoren Qualität, Kosten und Zeit zu kämpfen oder scheitern gar, und zwar insbesondere durch die umfangreiche Anforderungsdefinition im Vorfeld. (vgl. Thomas, M.: IT Projects Sink or Swim. British Computer Society Review, 2001)
(Siehe hierzu auch unseren Artikel Agile Software-Entwicklung vs. Wasserfall-Modell: Was die Forschung sagt.)
Solche Änderungen lassen sich im Vorfeld schwer planen und stehen im Widerspruch zum – in klassischen Vorgehensmodellen sehr bedeutenden – Konzept des Projektplans. Zudem ist es schwieriger, Erkenntnisse, die man erst im Projektverlauf gewinnt, in die weitere Entwicklung einzubeziehen.
Bei diesen Erkenntnissen kann es sich insbesondere um Feedback von den Nutzern, um wichtige Entscheidungen des Managements und/oder um technologische Entwicklungen handeln. Ein frustrierendes Change-Request-Management und Fragen wie “Hätten wir das nicht vorhersehen können?” sind die Folgen.
Arbeitet ein Unternehmen erfolgreich mit dem Wasserfallmodell, besteht kein Handlungsdruck. Agile Vorgehensmodelle sollten nicht einfach deshalb eingeführt werden, weil sie zeitgemäß und “state-of-the-art” sind:
"If it ain't broke, don't fix it. If your organization is applying a waterfall-oriented or any other process it has high success rates with a good productivity, don't change. Adopting an iterative or agile method should be motivated by a challenge, not method du jour fads." - Craig Larman
Wenn Sie hingegen aufgrund Ihres dynamischen Umfelds die oben beschriebenen Probleme und Herausforderungen erleben und Zeitpläne reißen oder/und Budgets explodieren, ist es Zeit, sich über agile und iterative Methoden Gedanken zu machen.
Denn genau in solchen Fällen kann die agile Software-Entwicklung ihre Stärken ausspielen und zu erfolgreicheren Projekten verhelfen. Unsere Erfahrung und der Austausch mit unseren Kunden zeigen, dass im schnell wandelnden Umfeld, in dem sich die meisten (IT-)Unternehmen heute bewegen, die Vorausplanung immer schwieriger wird. Deshalb fällt die Entscheidung in zunehmendem Maße pro "Agile".
Haben Sie Fragen zu agilen Entwicklungsmethoden? Planen Sie ein Software-Projekt oder benötigen Sie Unterstützung bei einem laufenden Vorhaben? Wir sind Experten für iterative Entwicklung und verfügen über jahrelange Erfahrung mit agilen Modellen und Methoden. Bitte sprechen Sie uns an. Ausführliche Informationen zum Thema finden Sie auch in unserem öffentlichen Wiki: Einstieg in die Software-Entwicklung mit //SEIBERT/MEDIA.
Weiterführende Informationen
Scrum: Agile Software-Entwicklung bei //SEIBERT/MEDIA
JIRA: Aufgabenmanagement, Scrum und agiles Projektmanagement für Entwickler und Manager
Welche Vorteile bietet mir als Kunde ein Scrum-Projekt?
Anatomie einer Iteration
Mehr über die Creative-Commons-Lizenz erfahren
