Agil oder klassich?

Welche Vorgehensweise für welches Projekt? Ein kleiner Überblick über Vor­gehens­weisen im Projekt­mana­ge­ment

Alle reden von Projekten, aber – was ist das eigentlich, ein Projekt?
Ein Projekt lässt sich im Wesentlichen durch die Ein­malig­keit der Bedingungen in ihrer Gesamt­heit beschreiben: es ist komplex, einzig­artig und inter­disziplinär, es hat eine begrenzte Dauer und verfügt nur über begrenzte Ressourcen. Seine Ziele sind vorab definiert (was nicht aus­schließt, dass sie sich im Verlauf des Projekts durchaus verändern können), die Verant­wortung für das Projekt­ergebnis ist klar zugeordnet.
Projekteigenschaften
Im Zuge der Projekt­realisierung bewegen wir uns in dem Spannungs­feld aus Zeit, Aufwand (Kosten) und Ergebnis (Leistung).
Magisches Dreieck
Dieses "magische Dreieck" dominiert die Projekt­planung und –steuerung, die Mess­latte für den Projekt­erfolg sind Kunden­zufrieden­heit und ein qualitativ hoch­wertiges Projekt­ergebnis.

Nach DIN 69901 durchläuft ein Projekt die Phasen Initialisierung, Definition, Planung, Steuerung und Abschluss.
Projektphasen nach DIN

In der Praxis gibt es unterschiedlichste Herangehens­weisen an die Um­setzung von Projekten. Im IT-Umfeld lassen sich die Gegen­pole identifizieren in Gestalt des so­genannten "Wasser­fall­modells" auf der einen und agilen Vorgehens­weisen wie Scrum auf der anderen Seite. Bevor ich auf die Frage eingehe, welche Vorgehens­weise für welche Projekte geeignet ist, möchte ich diese beiden Vor­gehens­modelle kurz vor­stellen.

Das Wasser­fall­modell zeichnet sich dadurch aus, dass jede Projekt­phase nur einmal durch­laufen wird. Der Abschluss einer Phase ist die Voraus­setzung für den Beginn der darauf­folgenden Phase. Die wesentliche Bedingung für erfolg­reiches Vor­gehen nach dem Wasser­fall­modell ist also, dass bereits zu Projekt­beginn alle Anforderungen an das Projekt bekannt sind und über den gesamten Projekt­verlauf stabil bleiben. Planung und Design des Projekt­inhalts erfolgen zum Auftakt des Projekts mit sehr hohem De­taillierungs­grad für das gesamte Projekt.
Wasserfallmodell
Daraus folgt, dass beispiels­weise Miss­ver­ständnisse zwischen dem Auftrag­geber und dem Auftrag­nehmer oder fehlerhafte Konzeptionen erst sehr spät erkannt werden (können), da der Kunde erst zum Projekt­ende wieder intensiv in das Projekt eingebunden wird. Spät erkannte Fehler aber sind teure Fehler, da sie zumeist zu umfang­reichen Nach­arbeiten führen.

Agile Vorgehensweisen hingegen lassen sich als iterativ und inkrementell beschreiben. Sie ver­zichten in der Anfangs­phase auf eine tiefe Detail­planung wie wir sie im Wasser­fall­modell finden und nehmen statt dessen eine Grob­planung vor, in der eine Ab­folge von Iterationen oder Releases festgelegt wird. Die Phasen Analyse, Entwurf, Realisierung und Test werden für jede dieser Iterationen durchlaufen. Am Ende einer solchen Iteration ("Sprint" bei Scrum) steht stets ein potentiell nutzbares Produkt, das dem Kunden präsentiert und von ihm ab­ge­nommen werden kann. Iterationen sind "time-boxed", d.h., sie haben eine feste Länge. Zum Abschluss einer Iteration oder eines Sprints gehört ein Review, also die Analyse dessen, was gut und was schlecht gelaufen ist. Not­wendige Ver­änderungen der Arbeits­weise werden (soweit möglich) sofort umgesetzt.
Die ursprüngliche Planung wird kontinuierlich überprüft; ver­feinert wird sie auf der Basis des aktuell Erreichten für die jeweils ein bis zwei folgenden Iterationen. Planung und Um­setzung erfolgen also stufenweise.
Agile Vorgehensweisen kennen die klassische Rolle des Projekt­leiters nicht: in Scrum bspw. gibt es den Product Owner, der den Kontakt zum Kunden hält und letztlich dessen Re­präsentant im Projekt ist, den ScrumMaster, der auf die Ein­haltung der Scrum-Regeln achtet und Hinder­nisse, die sich dem Team im Laufe seiner Arbeit ent­gegen­stellen, be­seitigt und das Team. Das Team arbeitet selbst­verantwortlich.
Agile Vorgehensweisen setzen auf auf dem externer Link "Agilen Manifest", das im Februar 2001 entstand. Wesent­lich sind hier aus meiner Sicht neben den Grund­prinzipien agilen Vorgehens vor allem die agilen Werte, die die gemeinsame Arbeit bestimmen: Trans­parenz, Offen­heit, Respekt, Selbst­ver­pflichtung …

Kehren wir gedanklich noch einmal zu dem oben dar­ge­stellten Phasen­modell für den Projekt­ablauf zurück, so lässt sich fest­stellen, dass agile Vor­gehens­weisen nicht den gesamten Projekt­ablauf, sondern vorrangig die Phasen Planung und Steuerung betreffen. Agiles Vorgehen stellt sich im Kern so dar:
Agiler Kernprozess
Dieser Kern lässt sich in das oben beschriebene Phasen­modell der­gestalt ein­betten, dass er im wesentlichen Teile der Phasen Planung und Steuerung ersetzt, die übrigen Phasen aber weitest­gehend unberührt lässt.
Ein zentraler Vorteil agiler Vorgehens­weisen liegt auf der Hand: die sehr enge Einbindung des Kunden in das Projekt hilft, falsch ver­standene An­forderungen oder Lösungs­ansätze früh­zeitig zu erkennen und die ent­sprechenden Korrekturen vorzunehmen. So steigt die Qualität des Produkts und die Kunden­zufriedenheit.
Zudem zeigen Erfahrungen aus dem Einsatz agiler Methoden, dass die Motivation und Zu­friedenheit bei selbst­verantwortlich agierenden Teams deutlich steigen.

Natürlich darf auch nicht ver­schwiegen werden, dass die Einführung einer agilen Vor­gehens­weise wie Scrum weit­reichende Aus­wirkungen auf das gesamte Unter­nehmen bzw. die Organi­sation hat. Die Ver­teilung der Auf­gaben des klassischen Projekt­managers auf die Scrum-Rollen Product Owner, ScrumMaster und Team führt ebenso wie die enge Ein­bindung des Kunden in das Projekt potentiell zu weit­reichenden Änderungen in der Projekt­abwicklung und in unter­nehmens­internen Prozessen und Abläufen.
Zwischen den beiden hier kurz skizzierten Vorgehens­modellen (Wasserfall und Scrum) gibt es zahl­reiche Ab­stufungen. Als Beispiele seien hier stell­vertretend für viele andere Kanban (s. bspw. externer Link Kanban (Soft­ware­ent­wicklung) ) oder externer Link APM genannt.
Die Frage, welche Vorgehens­weise sich für welches Projekt eignet, lässt sich nicht pauschal beantworten, sie muss grund­sätzlich unter Berück­sichtigung des Projekt­umfelds und der Projekt­bedingungen selbst geklärt werden - dabei unterstütze ich Sie gerne! Details dazu finden Sie auf dieser Website unter Leistungen.
Nach oben

  Home