Die Frage nach der richtigen Projektmanagement Methode nimmt häufig philosophische Züge an. Verwende ich die klassische Methode und mache mein Projekt so wie es schon immer gemacht wurde? Oder wende ich mich den agilen Methoden zu, und schaue wo diese mich hinführen.
Egal wie die Entscheidung auch ausfällt, sie sollte in jedem Fall gut begründet sein. So kann man auch anderen Projektbeteiligten plausibel erläutern, warum man sich für die eine oder andere Methode entschieden hat.
Ich möchte mit diesem Artikel einen Anstoß für die agilen Methoden geben. Es soll beschrieben werden, welche Gedanken ich mir zu der jeweils geeigneten Projektmethode gemacht habe und wie das Ergebnis meiner Überlegungen zustande kommt.
In den vergangenen Jahren habe ich in beiden Projektwelten etliche erfolgreiche Projekte geleitet und dabei sehr wertvolle Erkenntnisse/Erfahrungen gewonnen. Mal klassisch, mal agil und früher auch mal intuitiv bevor die Intuition in die agilen Methoden eingegangen ist.
Am Anfang steht der Plan!
Am Anfang eines jeden klassischen Projekts steht die Planungs- und Spezifikationsphase. In dieser Phase werden unter anderem Lastenheft und Pflichtenheft erstellt. Im Lastenheft beschreibt der Kunde seinen Standpunkt und Anforderungen an das Projekt. Das Pflichtenheft ist dann die Antwort auf das Lastenheft von denjenigen, die das Projekt umsetzen. Und hier geht das Elend dann schon los! Fachbereiche und IT sprechen in den seltensten Fällen die gleiche Sprache und in den allermeisten Fällen aneinander vorbei. Lassen wir dieses Thema erstmal dabei beruhen.
Weiterhin purzeln aus der Planungs- und Spezifikationsphase noch Zeitpläne, Projektstrukturpläne, Arbeitspakete, Ressourcenpläne, Kostenpläne und vieles mehr heraus. All das ist wichtig, um den Berg von Anforderungen irgendwie systematisch bewältigen zu können. Eine solche Planung ist aufwändig und bringt viele Unwägbarkeiten in Bezug auf Kosten, Umfang und Zeit mit sich.
Jetzt wird aber was getan!
In der Realisierungsphase werden die Punkte aus dem Pflichtenheft vom Entwicklungsteam abgearbeitet. Neben der reinen Entwicklung werden noch Tonnen an Papier und weiteren Plänen erstellt. Ich stelle das Ganze an dieser Stelle stark verkürzt und auch stark vereinfacht dar, weil ich auf etwas Bestimmtes hinauswill.
Denn nach der Realisierungsphase kommt der große Tag, an dem das „fertige“ Produkt dem Kunden vorgestellt wird. Sehr wahrscheinlich sind zu diesem Zeitpunkt schon die Pläne bzgl. Kosten und/oder Terminen von der Realität eingeholt worden.
Die Enttäuschung
Das vermeintlich fertige Produkt wird dem Kunden präsentiert. Die Entwickler sind aufgeregt und stolz, weil Sie wirklich tolle Dinge in die Applikation eingebaut haben.
Und der Kunde? Der ist meist entsetzt, weil er seine Anforderungen aus dem Lastenheft nicht wiedererkennt. Spätestens an dieser Stelle kommt es dann zu babylonischen Sprachverwirrungen, weil jeder seine eigene Interpretation der dokumentierten Anforderungen hat.
Um das Thema an dieser Stelle abzukürzen, alle sind enttäuscht von der jeweils anderen Seite. Fingerpointing und die Schuldzuweisungen sind im vollen Gange und die Eskalationsmaschinerie wird hochgefahren.
Letztendlich einigt man sich dann auf einen eher krummen Deal, die vorgesehen Testphase wird eingedampft und geplante Lasttests auf unbestimmte Zeit verschoben. Das alles, um mindestens noch halbwegs den Termin für die Produktivsetzung zu halten.
Aber genug vom Projekt Bashing.
Woran liegt es denn nun, dass klassische Projekte nur leider allzu oft diesen Weg nehmen? Mangelhafte Kommunikation, überzogene Vorstellungen an Zeit und Budget, unklare Anforderungen. Diese Liste ließe sich wahrscheinlich beliebig fortsetzen.
Mit der hier beschriebenen Problematik im Hinterkopf möchte ich im Folgenden gerne die klassische Projektmanagementmethode der agilen Methode anhand des „magischen Dreiecks“ gegenüberstellen.
Das magische Dreieck
Das magische Dreieck ist eines der etabliertesten Mittel im Projektmanagement, um bestimmte Größen und deren Abhängigkeiten gegeneinander darzustellen. Im Allgemeinen kommt das magische Dreieck im Stakeholder Management zum Einsatz und zeigt die Beziehung zwischen den Größen Zeit, Kosten und Umfang/Qualität in einem Projekt auf.
Die drei Größen stehen in einem Zusammenhang und beeinflussen sich gegenseitig.
Wird in einem Projekt die Zeit bis zum Fertigstellungstermin knapp, müssen mehr Ressourcen für die Fertigstellung aufgewendet werden, was die Kosten in die Höhe treibt. Sind die Kosten gedeckelt, muss ggf. der Umfang des Projektes verändert werden, um den geplanten Zeitpunkt einzuhalten.
Das wirklich praktische am magischen Dreieck ist seine Gültigkeit für klassische Projekte wie auch für agile Projekte.
Und unter diesem Aspekt wollen wir einen näheren Blick darauf werfen, wie uns das magische Dreieck bei der Entscheidung „klassisch“ oder „agil“ helfen kann.
In dem zu Beginn beschriebenen Szenario wird deutlich in welche Richtung ein klassisches Projekt im Bezug zum magischen Dreieck steuert. Oftmals ist der Zeitpunkt für den Go-Live fix. Die Marketingabteilung hat schon ganzseitige Anzeigen geschaltet und Fernsehspots für das neue Produkt sind schon für ein bestimmtes Datum geplant. Das geplante Budget ist schon aufgebraucht, weshalb nicht mehr Ressourcen in das Projekt gesteckt werden können. Da bleibt dann nur noch die Ecke mit dem Umfang aus dem magischen Dreieck übrig, an der man was ändern kann.
Und was macht agil anders?
Wie schon angemerkt, hat das magische Dreieck auch in agilen Projekten sein Dasein, wie in klassischen Projekten. Aber sind die Probleme mit Kosten, Zeit und Umfang des Projektes im agilen Projekt sehr ähnlich gelagert?
Die Antwort lautet: “ja”! Die Probleme sind im agilen Projekt genauso vorhanden, wie im klassischen Projekt. Was sich aber grundlegend unterscheidet, ist der Umgang mit den drei Größen. Der agile Weg stellt unser magisches Dreieck auf den Kopf.
Dabei ist es wichtig, das agile Mindset zu verstehen und die agile Denkweise verinnerlicht zu haben.
In einem agilen Projekt nach der Scrum-Methode gibt es einige festgelegte Randbedingungen, welche uns bei der Bewertung des magischen Dreiecks unterstützen.
Sprintlänge (Zeit):
Die Definition von Scrum spricht von einer Sprintlänge zwischen einer und vier Wochen. Innerhalb dieser Zeit werden die vorher definierten Stories aus dem Sprint-Backlog vom Sprint-Team bearbeitet. Dabei soll die Sprintdauer über die Zeit hinweg nicht geändert werden. Man möchte das Sprint Team damit in die Lage versetzen in einer festgelegten Geschwindigkeit (1 – 4 Wochen) an zu erledigenden Stories über einen längeren Zeitraum aufrecht zu erhalten, ohne dass es zu Ermüdungserscheinungen oder Arbeitsüberlastung kommt. Mit einer solchen Maßnahme ist der Teil des magischen Dreiecks, welcher sich mit der Zeit befasst „fix“, da die Sprintlänge über den gesamten Zeitraum aller Sprints konstant bleibt.
Teamzusammensetzung (Kosten):
Auch für die Größe von Scrum-Teams gibt es Empfehlungen. Ein Scrum-Team soll eine Größe zwischen 3 und 9 Personen haben. Alles darüber hinaus erfordert zu viel Koordination, alles darunter verringert die Chance am Ende eines Sprints ein lauffähiges Produktinkrement zu erstellen.
Die Größe eines Sprint Teams sollte nicht ohne zwingenden Grund geändert werden. Um eine gleichbleibende Geschwindigkeit des Teams zu gewährleisten, sollten Teamgröße und -zusammensetzung über den Gesamtzeitraum aller Sprints idealerweise identisch sein. Und schon haben wir die zweite Ecke unseres magischen Dreiecks fix. Mit einem gleichbleibenden Team und einer festen Sprintlänge können die Kosten für einen Sprint recht genau beziffert werden.
Produktinkrement (Umfang/Qualität):
Mit der dritten Ecke aus unserem magischen Dreieck kann nun der agile Weg seine volle Wirkung entfalten. Laut Definition von Scrum steht am Ende eines jeden Sprints ein funktionsfähiges und nutzbares Teilprodukt, welches als Produktinkrement bezeichnet wird. Dieses Produktinkrement entspricht in der Funktionalität den Stories aus dem Sprint-Backlog. Zusammen mit der Betonung auf „funktionsfähiges“ Teilprodukt, bekommen die Stakeholder ein Produkt geliefert, welches getestet und einsatzbereit ist. Durch diese frühe und beständige Lieferung von lauffähigen Produktinkrementen, können Stakeholder nah an der Produktentwicklung ein Gefühl für die zukünftige Applikation gewinnen und schon früh die Applikation in die gewünschte Richtung steuern
Fazit
Der Artikel könnte den Eindruck erwecken, das klassische Projekte altbacken, von gestern oder fehlerträchtiger wären. Agile Projekte seien dagegen hip, jeder würde sich wohl fühlen und Probleme gäbe es nicht. Dieses Schwarz-Weiß-Denken wäre jedoch viel zu kurz gegriffen und hat nicht viel mit der Realität zu tun. Nichtsdestotrotz können agile Projekte ihre volle Stärke ausspielen, wenn sich alle Beteiligten darauf einlassen. Die Stakeholder sehen sehr früh im Projekt wohin die Reise geht und können schon früh steuernd eingreifen. Anhand der definierten Stories im Sprint Backlog können alle Stakeholder sehen, was im nächsten Sprint umgesetzt wird und was nicht. Durch die Priorisierung von Stories können wichtige Funktionalitäten vorgezogen werden und dadurch früher zum Einsatz gelangen. Auch das Projektteam hat Vorteile, weil es früh Feedback von den Stakeholdern zu den einzelnen Teilprodukten bekommt und dadurch Erfahrungen sammelt, wie Stories besser zu interpretieren sind. Man könnte meinen es gibt nur Gewinner!
Ein solch agiles Projekt bedeutet aber auch für jeden Stakeholder und das Projektteam Verantwortung, Offenheit, Vertrauen und ein Einlassen auf etwas Neues. Fingerpointing oder Schuldzuweisungen sind in agilen Projekten nicht vorgesehen, weil kontraproduktiv.
Von daher wünsche ich Jedem ein erfolgreiches und inspirierendes Projekt, in dem alle die Möglichkeit haben jeden Tag etwas Neues zu lernen, egal welche Methode zum Einsatz kommt.