Back

Agil oder nicht Agil? Wann ist es sinnvoll und wann nicht…

Agile, Scrum, Kanban und co. sind in aller Munde.
Doch sind agile Methoden ein Allheilmittel für jede Situation und jedes Projekt?

In diesem Artikel möchten wir einen kurzen Einblick in die Thematik „Agiles Projektmanagement“ geben und uns mit den Fragen beschäftigen:

  • Ist agil wirklich immer die beste Lösung oder nur ein Hype?
  • Was ist Agiles Projektmanagement und wo liegen die Unterschiede?
  • Welche Methodik ist in welcher Situation die bessere?

Am Anfang das Projekt

Die Frage nach einer geeigneten Methodik stellt sich in der Regel im Rahmen eines Projektes bzw. davor. Ein Projekt wird üblicherweise wie folgt definiert:

Ein Projekt ist ein zielgerichtetes, einmaliges Vorhaben, das aus einem Satz von abgestimmten, gesteuerten Tätigkeiten mit Anfangs- und Endtermin besteht und durchgeführt wird, um unter Berücksichtigung von Vorgaben bezüglich Zeit, Ressourcen und Qualität ein Ziel zu erreichen.

Wikipedia

Und hier kommt auch schon die Frage auf, wie man die drei wichtigen Eckpfeiler eines Projektes (Anforderungen, Ressourcen, Zeit) planen und überwachen kann um somit das Projekt zum Erfolg zu führt.

„Triple Constraint“ – Eines der Kernkonzepte im Projektmanagement

Im weit verbreiteten klassichen „Wasserfall“ Projekt, werden die drei Eckpfeiler vor Projektbeginn genau beleuchtet und entsprechend eingeplant. Über viele Jahre wurden (und werden) erfolgreich Projekte in dieser Art und Weise realisiert. Klar ist, das dies eine enorme Vorarbeit erfordert, denn Zeit und Aufwand kann erst ermittelt werden, wenn die Anforderungen eines Projektes in komplettem Umfang vorliegen.

Die Welt in der wir leben verändert sich allerdings immer rasanter und disruptiver. Rahmenbedingungen, Technologie, Kundenstrukturen und Verhalten ändern sich exponentiell schnell und Unternehmen sind gezwungen möglichst schnell zu handeln. Dies hat wiederum zur Folge, dass am Triple Constraint mächtig gerüttelt wird. Wenn es zu Änderungen an Anforderungen, Ressourcen oder Zeit kommt, hat dies meist auch Auswirkungen auf die jeweils andern Faktoren und somit auf den gesamten Projekterfolg.

Dass eine Planung nicht immer mit der tatsächlichen Realität zu tun hat, zeigen folgende Zahlen:

Aufwandsschätzungen die vor Projektbeginn erhoben wurden,
haben einen Unsicherheitsfaktor von 4

60% aller IT-Projekte scheitern.
Viele überschreiten ihr Budget um 400% bei 25% der Funktionalität

3% Änderung von Anforderungen pro Monat.
Ca. 50% Änderungen an Anforderungen bei Projekten über 1,5 Jahre


Es lässt sich also allgemein feststellen, dass vor Projektbeginn geplante Werte für Umfang, Zeit und Budget mehr und mehr unsicher werden, da sich das Umfeld und die Rahmenbedingungen immer rasanter verändern.

Genau hier setzen agile Projektmethoden an.
Sie bieten ein Framework, welches strukturiert und iterativ sich ändernde Rahmenbedingungen in den Projektprozess integriert.

Und hier liegt einer der wesentlichen Unterschiede zwischen klassischem und agilen Projektmanagement. Bleiben wir beim Beispiel des o.g. Triple Constraint. Die drei Eckpfeiler bzw. deren Inhalt und Werte entstehen im klassischen Projektmanagement auf Basis der Anforderungen. Wenn Anforderungen beschrieben werden, folgt eine Schätzung über Zeit und Ressourcen/Budget. Diese drei Werte sind dann üblicherweise Vertragsgegenstand und müssen am Ende des Projektes erfüllt sein.

Agile Methodik dreht dieses Konstrukt auf den Kopf. Es wird zuerst festgelegt welche Ressourcen / Budget zur Verfügung stehen und bis wann ein nutzbaren Ergebnis vorliegen muss. Erst danach folgt eine Definition des Umfangs bzw. der Anforderungen. Darüber hinaus ist dieser quasi nie final und kann im Laufe des gesamten Projektes angepasst werden. Alles um ein grundlegendes Ziel zu erreichen: Ein nutzbares Ergebnis zum festgelegten Termin, zum festgelegten Budget.

Waterfall vs. Agile

Hier möchten wir einen schnellen und einfachen Überblick über die grundlegenden Unterschiede zwischen klassischem und agilem Projektvorgehen zeigen:

WaterfallAgile
 Sequentieller EntwicklungsprozessIterativer Entwicklungsprozess
Anforderungen sind zu Projektbeginn bekanntAnforderungen sind zu Projektbeginn noch unscharf
Neue Anforderugnen im laufenden Projekt schwierig / teuerÄnderungen am Scope / Umfang sind normal
Anforderungsbeschreibung ist technischAnforderungsbeschreibung aus Usersicht (Userstorys)
Starres ProjektvorgehenFortlaufender Verbesserungsprozess
Kunde erhält EndergebnisKunde bewertet kontinuierlich Zwischenergebnisse
Klare HierarchieSelbstorganisierte Teams
Aufgaben werden von Projektleitung zugeteiltAufgaben werden selbstständig übernommen
Kommunikation via Meetings und StatusdokumentenInformelle Kommunikation in Daily Stand-Ups
Projektleiter / Experten schätzen AufwandTeam schätzt den Aufwand gemeinsam
Hohe RisikopotenzialGeringes Risikopotenzial

Agil oder nicht? Welche Methode macht Sinn?

Aktuell wird alles und jeder „agil“. Sämtliche Projekte, ob klein oder groß werden auf Sprintboards zelebriert. Doch ist das immer sinnvoll und wird dieses Vorgehen zukünftig alle anderen Methodiken verdrängen? Bedingt.

Um ein agiles Projekt korrekt aufzusetzen bedarf es einiger Arbeit, Know-How, Projektmitglieder und entsprechende Zeremonien (Review, Planung, Retrospektive).

Ob ein Projekt agil oder nicht gestartet werden sollte, lässt sich mit diesen zwei einfachen Fragen beantworten:

  • Wie gut kenne ich die Anforderungen an das Projekt?
  • Wie genau weiss ich diese Anforderungen umzusetzen?

Auf diesen beiden Achsen lässt sich sehr gut ermitteln wie viel Unsicherheitsfaktoren ein Projekt birgt oder eben ob alles perfekt zu überschauen ist. Sind Anforderungen und Lösungsweg völlig klar, bietet sich ein klassisches Projektvorgehen an. Sobald einer der beiden Achsen sich in Richtung unbekannt bewegt macht es sinn Agil und dadurch iterativ vorzugehen.

Fazit:

Agile Projektmethodik macht in der sich aktuell schnell verändernden Welt mehr und mehr Sinn. Ziele und Umfang von Projekten ändern sich schnell und es erfordert ein iteratives Vorgehen von interdisziplinären Teams, die transparent und schnell an einem nutzbaren Projektergebnis arbeiten.

Ist „Agil“ nun ein Hype? Ja – aus gutem Grund