Agiles Projektmanagement

Ins Leben gerufen von der Softwareentwicklung infiziert der agile Mindset heute bereits branchenübergreifend Projektleiter aus aller Welt. Projekte sollen alle möglichst „agil“ sein, denn agile – das weiß jeder – ist angeblich DER Schlüssel für die Entwicklung kunden- und geschäftswertorientierter Produkte. Aber was verbirgt sich hinter dem Wort „agil“? Welche Philosophie steckt dahinter? Handelt es sich um einen neuen Hype, oder doch um eine mehrwertstiftende Alternative zu klassischen Projektmanagement Methoden? Welche agilen Verfahren gibt es? Und wieso sollten gerade Sie in agiles Projektmanagement investieren, auch wenn Sie kein ITler sind? Diese und weitere spannende Fragestellungen sind das Thema unseres heutigen Blogbeitrages.

Was ist agiles Projektmanagement
In der Literatur existiert derzeit noch keine einheitliche Definition von „agilem Projektmanagement“. Im Bereich der Softwareentwicklung wird agile oft als Oberbegriff für eine neuartige Denkweise hinsichtlich der klassischen Projektmanagementansätze verwendet. Das Adjektiv „agil“ unterstreicht dabei, dass die neuen Herangehensweisen deutlich dynamischer und flexibler sind, wodurch schneller und besser auf sich verändernde Rahmenbedingungen und Anforderungen reagiert werden kann. Charakteristisch für agile Prozesse sind eine iterative, gering bürokratische und transparente Vorgehensweise. Sie sollen die Fehlerquote innerhalb des Entwicklungszeitraumes minimieren und die Transparenz während des gesamten Prozesses erhöhen.

Die Geschichte des agilen Projektmanagements
Die agile Denkweise stammt ursprünglich aus der Software-Entwicklung. In den 90er Jahren stand die IT-Branche und somit auch die Softwareentwicklung vor sich verändernden Rahmenbedingungen: Denn aufgrund der hohen Innovationsgeschwindigkeit verkürzten sich die Produktlebenszyklen drastisch, die Wettbewerbsintensität stieg an und die Anforderungen an die Produkte wechselten beständig. Zusätzlich veränderte sich auch die Denkweise innerhalb der Software-Entwicklung: Die Softwareerstellung wurde nunmehr als kreativer Prozess aufgefasst, der nicht durch bürokratische Regulierungen, wie z.B. bezüglich der Dauer und des Aufwands, limitiert werden durfte. Die Veränderungen zwangen die Software-Entwicklung zum Umdenken. Es musste ein neuerer, flexiblerer, agiler Ansatz geschaffen werden. Während der Mindset bereits seit den 90er Jahren besteht, wurde das Wort „agile“ erst 2001 mit dem Verfassen des „agilen Manifests“ ins Leben gerufen. Dieses umfasst Leitregeln zur Durchführung erfolgreicher, agiler Projekte und veranschaulicht so die agile Philosophie. Die Bezeichnung „agiles Projektmanagement“ entstand erst im Laufe der Jahre, als die agilen Ansätze auf Projekte aller Art angewandt wurden.

Das Agiles Manifest
Das „agile Manifest“ ist eine Niederschrift aller Werte und Prinzipien, die bei jedem agilen Projekt angewendet werden sollten.
Das agile Manifest umfasst folgende Werte: 

Wir erschließen bessere Wege, Software zu entwickeln, indem wir es selbst tun und anderen dabei helfen. Durch diese Tätigkeit haben wir diese Werte zu schätzen gelernt:

1. Individuen und Interaktionen mehr als Prozesse und Werkzeuge
Bei agilen Projekten steht klar der Mensch im Fokus. Für ein erfolgreiches Arbeiten ist eine ständige, aktive Kommunikation essenziell. Weiterhin soll jeder Projektbeteiligte in seinem Handeln nicht durch streng definierte Prozesse eingeschränkt werden.

2. Funktionierende Software mehr als umfassende Dokumentation
Vor allem in der Software-Entwicklung ist es für die Stakeholder wichtiger einen funktionierenden Prototyp in den Händen zu halten, als eine umfassende Dokumentation.

3. Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung
Anstelle von zeitintensiven Vertragsverhandlungen, soll bei agilen Projekten schnellst möglich mit der Arbeit begonnen werden. Ändern sich die Anforderungen des Kunden, werden diese kontinuierlich während des Projektverlaufes integriert.

4. Reagieren auf Veränderung mehr als das Befolgen eines Plans
Vor allem bei Software Projekten verändern sich gerne die Anforderungen und Wünsche der Stakeholder. Deshalb möchte man bei agilen Projekten flexibel und schnell auf sich verändernde Rahmenbedingungen eingehen können. Deshalb wird das Projektergebnis fortlaufend hinterfragt und mit dem Kunden abgestimmt.
Das heißt, obwohl wir die Werte auf der rechten Seite (Prozesse, Werkzeuge, Dokumentation, Vertragsverhandlung, Befolgen eines Plans) wichtig finden, schätzen wir die Werte auf der linken Seite höher ein (Individuen, funktionierende Software, Zusammenarbeit mit den Kunden, Reagieren auf Veränderungen).

agile Prinzipien
Die agilen Werte werden durch die 12 agilen Prinzipien näher konkretisiert:

• Zufriedenstellung des Kunden durch frühe und kontinuierliche Auslieferung wertvoller Software
• Agile Prozesse nutzen Veränderungen (selbst spät in der Entwicklung) zum Wettbewerbsvorteil des Kunden
• Lieferung von funktionierender Software in regelmäßigen, bevorzugt kurzen Zeitspannen (wenige Wochen oder Monate)
• Nahezu tägliche Zusammenarbeit von Fachexperten und Entwicklern während des Projektes (Bsp.: Gemeinsamer Code-Besitz (Collective Code Ownership))
• Bereitstellung des Umfeldes und der Unterstützung, welche von motivierten Individuen für die Aufgabenerfüllung benötigt wird
• Informationsübertragung nach Möglichkeit im Gespräch von Angesicht zu Angesicht
• Als wichtigstes Fortschrittsmaß gilt die Funktionsfähigkeit der Software
• Einhalten eines gleichmäßigen Arbeitstempos von Auftraggebern, Entwicklern und Benutzern für eine nachhaltige Entwicklung
• Ständiges Augenmerk auf technische Exzellenz und gutes Design
• Einfachheit ist essenziell (KISS-Prinzip)
• Selbstorganisation der Teams bei Planung und Umsetzung
  
• Selbstreflexion der Teams über das eigene Verhalten zur Anpassung im Hinblick auf Effizienzsteigerung

Scrum und Kanban – die zwei bekanntesten agilen Methoden
Zu den bekanntesten Methoden des agilen Projektmanagements zählen Kanban und Scrum. Bei beiden Verfahren wird ein Backlog erstellt, einer Liste an Produktanforderungen, wie z.B. eine Aufzählung aller Funktionen, die eine Software haben später haben soll. Charakteristisch für Kanban und Scrum ist weiterhin das Pull-Prinzip: Jeder Mitarbeiter darf seine Aufgabe selbst auswählen. Das soll das Commitment der Mitarbeiter für das Projekt stärken und die Mitarbeiter motivieren. Beide Ansätze finden nicht nur in der Software-Entwicklung Anwendung.

Scrum 
Innerhalb des Frame Works werden bei Scrum drei Rollen definiert: Der Product Owner, der Scrum Master und das Entwicklungsteam:
Der Product Owner bildet die Schnittstelle zwischen dem Management und den Stakeholdern. Er ist verantwortlich für die Arbeit des Entwicklungsteams und für das Endprodukt, welches kundenseitig einen möglichst großen Nutzen stiften soll. Product Owner managen dafür das Backlog, dh. sie priorisieren, sortieren, hinterfragen und löschen ggf. die jeweiligen definierten Anforderungen. Weiterhin organisiert der Product Owner das Sprint Review, ein Meeting zur Fortschrittskontrolle. Beim Sprint Review teilt der Product Owner dem Entwicklungsteam mit, welche Backlog-Einträge erledigt sind, welche noch angegangen werden müssen und welche Sprintziele nicht mehr von relevant sind. Der Product Owner bestimmt auch über den Release von Prototypen. Für all seine Entscheidungen trägt der Product Owner stets die Rechenschaft.

Der Scrum Master agiert als Schnittstelle zwischen dem Product Owner und dem Entwicklungsteam. Ein Scrum Master hat stets eine lenkende, vermittelnde und unterstützende, aber keines Falls eine führende Funktion. Er trägt die Verantwortung für den Scrum-Prozess, weshalb er das Product- und Sprint Backlog sowie die Burndown Charts stetig beobachtet und den Projektprozess bei Rückständen optimiert. Er moderiert außerdem sogenannte Scrum-Meetings und sorgt so für den Informationsfluss zwischen dem Entwicklungsteam und dem Product Owner.

Das Entwicklungsteam besteht meist aus einer kleinen Gruppe von 5-10 Software-Entwicklern.

Die Durchführung eines Scrum Projekts erfolgt inkrementell, in sogenannten Sprints. Diese dauern i.d.R. immer zwei bis drei Wochen. Dabei soll das Team einen Increment of Potentially Shippable Functionality, also einen noch funktionsfähigeren Prototypen, als beim vorherigen Sprint, entwickeln. Jeder Sprint beginnt mit einem Kick-Off Meeting, dem sogenannten Sprint Planning. In dieser meist ganztägigen Besprechung stellt der Product Owner die am höchsten priorisierten Requirements des Product Backlogs vor. Gemeinsam einigen das Entwicklungsteam und der Scrum Master sich dann auf ein sogenanntes Sprint Goal und definieren, welche Items des Product Backlogs das Team im nächsten Sprint bewältigen wird.

Die Entscheidungsmacht des Entwicklerteams soll ihr Commitment für die Erreichung des Sprint Goals stärken. Nach dem die Requirements dem Sprint zugeordnet wurden, bricht das Team autonom alle Requirements nochmals in Tasks herunter. Das Entwicklungsteam arbeitet alle Sprints stets nach den Priorisierungen des Product Owners ab. Innerhalb eines Sprints dürfen dabei die vorab definierten Aufgaben nicht verändert werden.
Das Entwicklungsteam organisiert täglich einen Daily Scrum. Dabei handelt es sich um ein ca. 15 min. Stand-Up-Meeting, bei dem alle Team Mitglieder was sie seit dem letzten Daily Scrum geschafft haben, was sie bis zum nächsten schaffen wollen und was sie in ihrer Arbeit behindert hat. Meist nehmen an dem Metting auch der Scrum Master und der Product Owner teil.

Nach einem oder mehreren erfolgreichen Sprints erfolgt ein Release. Oftmals geschiet dies innerhalb eines Sprint Reviews. Bei einem Sprint Review stellt das Team dem Product Owner sowie allen Stakeholdern das funktionierende System vor, das sie während des Sprints entwickelt haben. Das Feedback der Stakeholder und des Product Owners fließt wiederum in die Ausgestaltung der noch folgenden Sprints mit ein.
Im Anschluss an das „Sprint Review“ erfolgt das Sprint Retrospective Meeting. Bei diesem meist 3-stündigen Termin diskutiert der Scrum Master mit dem Entwicklungsteam über den vollendeten Sprint. Es werden Verbesserungsvorschläge erarbeitet, oder Maßnahmen zur Mitarbeiterentlastung.

Kanban 
Ähnlich wie bei Scrum wird bei Kanban zunächst auch ein Backlog angelegt. Die im Backlog aufgeführten Funktionen bzw. Anforderungen werden jeweils auf eine Kanban-Karte notiert und in ein sogenanntes Kanban Board einsortiert. Ein Kanban Board ist wie eine Tafel, die mehrere Zustände umfasst, z.B.: „nicht begonnen“, „in Arbeit“ und „Fertig“. Die Anforderungen wandern dann von Zustand zu Zustand entlang des Kanban Boards. In den jeweiligen Zuständen dürfen jedoch nur so viele Anforderungen parallel bearbeitet werden, wie die vorab definierte Obergrenze festlegt. Sind die Mitarbeiter mit der Bearbeitung einer Anforderung fertig, wählen aus dem Backlog selbstständig ihre neue Tätigkeit aus (Pull-Prinzip). Eine Vorgabe, wie viele Aufgaben innerhalb einer definierten zeitlichen Periode erledigt werden müssen (analog der Scrum Sprints), existiert bei Kanban nicht.

Weitere agile Projektmanagementansätze:
– Extreme Programming (XP)
– Test-Driven Developtment (TDD)
– The Spotify Model