Agiles Projektmanagement -Die drei Gründe, warum wir damit so gerne arbeiten.
Vor einiger Zeit war ich als Business-Analyst in einem Projekt zur Lastenhefterstellung für die Individualentwicklung eines Abrechnungssystems im Logistikbereich. Das Lastenheft sollte als Basis für den Ausschreibungsprozess genutzt werden. Ob die spätere Umsetzung nach dem Wasserfallmodell oder agilen Vorgehen stattfinden sollte, war zu dem Zeitpunkt noch unklar.
Wir haben also damit begonnen die Anforderungen im Lastenheft festzuhalten. Bei der Zusammenarbeit mit dem Fachbereich stellte sich dann ziemlich schnell heraus, dass diese am liebsten das alte System 1:1 beschrieben haben wollten – eine eher technische Spezifikation also. Es wurde damit zunehmend schwieriger, sich darauf zu konzentrieren, was der Fachbereich mit seinen Anforderungen erreichen wollte und damit den Nutzen der Anwendung ins Zentrum zu stellen. Zudem nimmt eine so technisch orientierte Anforderung den umsetzenden Teams jegliche Möglichkeit neue, hoffentlich verbesserte, Lösungswege zu identifizieren.
Nachdem das Lastenheft dann fertiggestellt war, hatte im Rahmen des Ausschreibungsprozesses ein Anbieter den Zuschlag erhalten, der agile Methoden einsetzte, um das neue Abrechnungssystem zu entwickeln. Die Anforderungen mussten also in User-Stories konvertiert werden, was auch für den Fachbereich ein lehrreicher Prozess war.
1. Was sind User Stories?
User Stories werden im agilen Projektmanagement in der folgenden Form angelegt:
Als [bestimmter Benutzertyp] möchte ich [ein bestimmtes Ziel erreichen], damit ich [einen bestimmten Nutzen erzielen] kann.
Hiermit wird im agilen Projektmanagement sichergestellt, dass der Nutzen der Entwicklung/Anwendung im Zentrum der Diskussion steht. Zudem gibt dieses Vorgehen den Entwicklern den notwendigen Freiraum, um die technisch beste Lösung zu ermitteln, ohne durch die Beschreibung schon vorweg eingeschränkt zu werden.
Was passierte dann in meinem Projekt? Zusammen mit dem Fachbereich habe ich die User-Stories erstellt, welche dann in den Sprint – Plannings überarbeitet worden sind. Das hat ein wenig gebraucht, bis wir uns da alle „eingegroovt“ und ein gemeinsames Verständnis über den Detailgrad gefunden hatten. Dies führte aber wiederum dazu, dass wir das typische „Das haben wir aber immer schon so gemacht“ komplett hinter uns ließen, uns von der Technik lösen konnten und uns wirklich auf notwendig fachliche Anforderungen konzentrierten. Das sorgte dann auch in der Umsetzung für einige angenehme Überraschungen, als dann auch einmal ganz andere Lösungsansätze gezeigt wurden (siehe iteratives Vorgehen), mit denen niemand gerechnet hatte.
Das führt uns zu meinem zweiten Favoriten aus dem SCRUM-Vorgehen – die iterative Umsetzung. Was bedeutet das?
2. Iteratives Vorgehen
Das iterative Vorgehen: Ein Kernelement des agilen Projektmanagement ist die iterative Vorgehensweise. Sei es, wie vorher beschrieben in den User Stories, die jeweils zur Umsetzung einer Teilanforderung führen, oder das Konzept der Auslieferung eines sogenannten MVP (Minimal Viable Product, also eines „minimal lauffähigen Produktes“) zieht sich das Konzept der Iteration durch. So wird sichergestellt, dass (Denk-)Fehler früh im Prozess auffallen und nicht erst, wenn das Produkt fertig und auf dem Markt ist oder alle Mitarbeiter im Unternehmen die Software schon nutzen und der Aufwand für Änderungen dann sehr umfangreich wird.
Wir Einkäufer kennen das Prinzip von Ausschreibungen und predigen dies immer wieder unseren Anforderern: Wenn wir erst das „finale“ Angebot auf dem Tisch liegen haben, ist der Verhandlungsspielraum meist minimal. Je früher wir aber eingebunden sind und beeinflussen/ändern können, desto größer wird die Wahrscheinlichkeit das beste Preis-Leistungsverhältnis zu erzielen.
In meinem Projekt bedeutete das, dass wir uns zuerst mit der Umsetzung der User Stories für die Login-Maske und Stammdatenpflege beschäftigten. Diese waren wenig komplex und daher ein guter Start. Hier hat sich dann auch der größte Vorteil des iterativen Ansatzes gezeigt. Der Fachbereich hatte frühzeitig sichtbare Ergebnisse zur Abnahme und fühlte sich von Beginn an involviert. Das führte auch dazu, dass man sich gleich zu Anfang um grundsätzliche Design-Fragen gekümmert hat, die mit den ersten Eingabemasken sichtbar wurden und die Auswirkungen auf die gesamte Applikation hatten. Zum Beispiel wurde die Frage geklärt, wie Massendaten angezeigt, darin gesucht und sortiert werden sollte, das Design von DropDown-Listboxen und vieles mehr. Hier konnten gleich in einer frühen Phase des Projektes Entscheidungen getroffen werden, die ansonsten im Wasserfallmodell einen großen Mehraufwand bei einer späteren Anpassung bedeutet hätten.
3. Sprint Planning/SCRUM Board = Transparenz
Das Sprint Planning und das SCRUM bzw. Kanban Board sind transparente und sichtbare Planungs- und Steuerungstools, in denen mitgearbeitet wird, anstatt, dass ein Projektmanager sich ständig durch die vielen Zeilen eines MS Projekt Projektplanes kämpfen muss.
Und jetzt kommt noch ein wenig Theorie, wo eigentlich die Unterschiede vom klassischen zum agilen Projektmanagement liegen und wie wir uns für das eine oder das andere entscheiden (Ja, nicht immer ist agiles Projektmanagement das Beste).
Unterschied „klassisches“ zum agilen Projektmanagement
2001 wurde das agile Manifest im Rahmen der Softwareentwicklung aufgestellt, welches das Endergebnis der Entwicklung und den Wert für den Kunden im Gegensatz zu strikten Prozessen und Dokumentationsbergen in den Vordergrund stellt. (http://agilemanifesto.org/)
Das klassische Projektmanagement, auch unter dem Namen „Wasserfallmodell“ bekannt, bewegt sich innerhalb vordefinierter, relativ fixer Grenzen. Der Projekterfolg ergibt sich aus dem Erreichen des anfänglich definierten Ergebnisses (Scope) am Ende des Projektes, gemessen an dem definierten Budget und der vorgegebenen Zeit mit den entsprechenden Ressourcen. Allgemein werden die folgenden Phasen in einem Projekt durchlaufen:
Analyse, Design, Herstellung/Umsetzung, Test, Lieferung
Im klassischen Projekt werden diese Phasen jeweils einmal durchlaufen. Hierin liegt der wesentliche Unterschied zum agilen Projektmanagement.
Agiles Projektmanagement ist schneller und wertorientierter angelegt als das klassische Model. Die genannten Phasen werden häufiger durchlaufen (Iterationen) um Rückkopplungen und Verbesserungen möglich zu machen und das maximale Ergebnis, bzw. den maximalen Wert für den Kunden, zu erreichen. Es werden viele kleine Testpakete (sogenannte Features) statt eines großen Endpaketes erstellt und ausgeliefert bevor die nächste Schleife gefahren wird.
Beide Systeme haben jedoch ihre Berechtigung:
Klassisches Projektmanagement
- Ergebnisse sind genau spezifizierbar und weniger komplex
- Es werden wenige Änderungen im Projektverlauf erwartet und die Schritte müssen aufeinander aufbauen (Beispiel Hausbau)
- Sie haben Erfahrungen mit ähnlichen Projekten
- Feedback im Laufe des Projektes kommt keine große Bedeutung zu.
Agiles Projektmanagement
- inhaltliches Neuland, welches schlecht planbar ist.
- Ergebnisse sind nicht klar spezifizierbar.
- Zwischenergebnisse sind hilfreich.
- Anpassungen am Weg sind möglich.
Zur weiteren Bewertung, welches Modell das richtige ist, möchten wir Euch gerne auch auf die Stacey Matrix hinweisen. Diese Matrix wurde entwickelt von dem im Bereich des Managements und der Organisationstheorie forschenden Professor Ralph Douglas Stacey
SCRUM - ein Rahmen für agiles Projektmanagement
SCRUM ist eine Methodik innerhalb des agilen Projektmanagements. Weitere sind z.B. SaFe, Design Thinking, KANBAN, Lean Startup, Business Model Canvas
Die Rollen in einem SCRUM Projekt sind die Folgenden:
- Entwickler und Entwicklerinnen – Diese setzen die einzelnen Anforderungen im Projekt um.
- Der SCRUM Master – Dieser ist im SCRUM Rahmenwerk ausgebildet und hat die koordinierende Funktion eines Projektleiters.
- Der Product Owner ist für die Wertsteigerung des Produkts im Entwicklungsprozess zuständig und verantwortet das Product Backlog und Product Goal.
Diese Teammitglieder definieren zusammen einen Product Backlog, also eine Liste an Aufgaben, oder Entwicklungsschritten, welche abgearbeitet werden müssen.
Hieraus entwickelt sich der Sprint Backlog, also die Aufgaben die in einem Sprint, einer Zeitspanne zwischen einer Woche und einem Monat, abgearbeitet werden müssen.
Im sogenannten Daily Scrum, ein in der Regel viertelstündiges Meeting, schauen wir uns den Sprint Backlog regelmäßig an. Jedes Teammitglied gibt eine Information, wie weit er oder sie mit seinen Aufgaben ist.
In sogenannten Retrospektiven wird überdacht, was bisher gut war und was nicht. Durch diesen gesteuerten Rückblick ermitteln wir Verbesserungspotentiale, welche direkt in das laufende Projekt zurückgegeben werden und somit unmittelbar den Prozess verbessern und nicht erst, wenn alles schon fertig und gelaufen ist.
In dem Scrum Review werden die Ergebnisse des jeweiligen Sprints abgenommen.
So wird, angefangen vom Minimal Viable Product (MVP), peu a peu das Projekt abgearbeitet und wir arbeiten uns an das “Endprodukt” heran mit dem Vorteil, dass die Ergebnisse der Lernkurve direkt in die einzelnen Zwischenergebnisse einfließen. Somit stellen wir nicht erst am Ende, sondern schon zu einem wesentlich früheren Zeitpunkt fest, dass vielleicht am Anfang in dem sonst riesigen Lastenheft ja gar nicht an alles gedacht wurde.
Aus der Praxis gesprochen: Das Sprint-basierte Vorgehen führt dazu, dass das Scrum-Team versucht alle User-Stories umzusetzen – ansonsten wird ja das Sprint-Review irgendwie unangenehm. In meinem Projekt hat das Scrum-Team daher mit Argus-Augen die Vollständigkeit der User-Stories geprüft, um potenzielle Überraschungen während des Sprints zu vermeiden. Ebenso war man bei der Schätzung der Aufwände/Story Points nicht zu optimistisch, weil sich das natürlich auch im Sprint-Review gerächt hätte. So war für alle Beteiligten sofort transparent, was im Rahmen des Sprints realistisch zu erwarten war
Wenn ihr mehr zu SCRUM wissen wollt, kommt gerne einfach auf uns zu.
Ansonsten würde uns interessieren:
Was habt ihr für Erfahrungen mit agilem Projektmanagement?
Wie nutzt ihr dieses im Einkauf (wenn noch nicht, haben wir da bald einen spannenden Ansatz für Euch 😉)?
2 Antworten