Wer kennt es nicht, ein neues Projekt steht in den Startlöchern, Team & Kunde können es kaum erwarten, dass es losgeht & freuen sich jetzt schon auf das Endergebnis. Oftmals ist der Ablauf von Projekten in der Theorie jedoch einfacher als in der Praxis. Krankheitsbedingte Ausfälle, ständig drängen sich andere Projekte oder kleine Aufgaben dazwischen oder ähnliches sind oft der Grund, weshalb Projekte stocken und das Endergebnis auf sich warten lässt.
Um dem entgegenzuwirken, arbeiten immer mehr Teams nach dem agilen Prinzip und das aus gutem Grund. Was agiles Projektmanagement für Vorteile bringen kann - das klassische Projektmanagement, aber deshalb nicht grundsätzlich schlecht ist, erfährst Du in diesem Blog-Beitrag.
Woher kommt das agile Projektmanagement?
Zuallererst muss man den Begriff „agil, bzw. Agilität" definieren. Agil bedeutet soviel, wie „wendig und flexibel". In den 1990er-Jahren wurden genau diese Aspekte im Projektmanagement in der Software Branche immer wichtiger. Man entwickelte agile Projektmanagement Methoden wie Scrum (hierzu gehen wir in diesem Artikel noch näher ein) & Kanban, um flexibel & reaktionsschnell auf Veränderungen & unvorhergesehene Ereignisse zu reagieren.
Das agile Projektmanagement wird seitdem ständig optimiert & verbessert.
Was unterscheidet agiles vom klassischen Projektmanagement?
Um zu verstehen, was das Ziel von agilem Projektmanagement ist, sollte man sich am besten das „agile Manifest" ansehen, welches die Basis für das agile Arbeiten stellt.
Die Leitsprüche des agilen Manifestes und was sie konkret bedeuten:
1. Individuen & Interaktionen sind wichtiger als Prozesse & Werkzeuge.
Das Team und die Menschen stehen im Fokus. Der direkte & ständige Austausch ist wichtiger als Formalien, denn kein noch so gut dokumentierter Prozess ist besser als das direkte Gespräch.
2. Ein funktionierendes Produkt ist wichtiger als eine umfassende Dokumentation
Hier wird die Wert- und Ergebnis-Fokussierung im agilen Projektmanagement klar. Es ist wichtiger, die tatsächliche Aufgabe zu erledigen und somit das Projekt voranzutreiben als dies zu dokumentieren oder bei Präsentationen in Schönheit zu sterben.
Gerade großen Unternehmen wird das oft zum Verhängnis, da überspitzt gesagt meistens mehr Aufwand in die PowerPoint für den Vorstand investiert wird als in das erfolgreiche Abschließen der Aufgabe.
3. Die Zusammenarbeit mit dem Kunden ist wichtiger als die Vertragsverhandlung.
Im agilen Projektmanagement ist der Kunde Teil des Teams. Es ist wichtiger, mit ihm im persönlichen, ständigen Austausch über Zwischenergebnisse und das weitere Vorgehen zu stehen, als einen formal perfekten & wasserdichten Vertrag zu erstellen & den Kunden danach bis zum Projektabschluss zu verabschieden.
4. Das Reagieren auf Veränderungen ist wichtiger als das strikte Festhalten an einem Plan.
Zu guter Letzt sollen agile Teams, flexibel & anpassungsfähig sein. Agile Teams verfolgen übrigens, dennoch einen klaren Projektplan, jedoch weichen sie gerne ab, wenn es für das Projekt & alle Beteiligten sinnvoll ist.
Schnell wird klar, worauf das agile Manifest hinaus will. Weg von den strikten & langwierigen Prozessen, Dokumentationen & Verhandlungen, hin zu flexiblen Teams, die deren Potenzial entfalten, sich an verschiedene Situationen anpassen und reagieren können. Außerdem steht ein zielorientiertes Endergebnis, welches einen klaren Nutzen mit sich bringt und bestehen kann, im Zentrum des agilen Projektmanagements.
Darüber hinaus enthält das agile Manifest noch 12 weitere Prinzipien, die Du Dir gerne im PDF ansehen kannst.
Wie funktioniert agiles Projektmanagement denn nun?
Jetzt kennen wir den Ursprung und die Grundlage von agilem Projektmanagement, aber wie sieht es denn konkret in der Praxis aus? Das erklären wir Dir anhand der beliebtesten Methode: SCRUM.
Begriffsklärungen
Im agilen Projektmanagement fallen hin und wieder Begriffe, die Dir vielleicht neu sein könnten, da diese Begriffe eben öfter benutzt werden, wenn man agiles Projektmanagement betreibt. Diese Begriffe erklären Dir wir vorab kurz und prägnant.
Product Backlog
Das Product Backlog ist eine Art Topf, in dem sich alle Anforderungen der Stakeholder an das Produkt / Projekt befinden. Hier wird also festgehalten, welche Ziele überhaupt erreicht werden sollen & was besonders zu beachten ist. Diese Anforderungen könnte man mit Karteikarten vergleichen, die dann in den Topf hinein geworfen werden. Das Product Backlog wird über das ganze Projekt hin gepflegt und aktuell gehalten.
Sprint Backlog
Das Sprint Backlog erfüllt eine ähnliche Funktion wie das Product Backlog. Auch hier kann man sich das Sprint Backlog wie eine Art Topf vorstellen, in dem Anforderungen der Stakeholder als Karten vertreten sind und erfüllt werden müssen. Jedoch mit einem entscheidenden Unterschied. Anders als das Product Backlog gilt das Sprint Backlog immer nur für den vorausgehenden Sprint (Erklärung siehe unten). Alle Anforderungen, die im Sprint-Backlog liegen, sollen in den kommenden zwei Wochen erfolgreich abgeschlossen werden und verschwinden danach.
Danach wird das Sprint Backlog wieder mit neuen Anforderungen aus dem Product Backlog für den nächsten Sprint gefüllt.
Pull Prinzip
Das „Pull Prinzip" ist ein wichtiger Bestandteil des agilen Arbeitens. Anders als im klassischen Projektmanagement werden den einzelnen Teammitgliedern nicht bestimme Aufgaben verteilt. Nachdem das Sprint-Backlog gefüllt ist, ziehen (englisch = pull) sich die Entwickler die Aufgaben aus dem Topf so wie sie es brauchen und für richtig halten.
Wichtig: Natürlich gehen die Teammitglieder beim Pull Prinzip sinnvoll und zielorientiert an die Sache. Ein Texter wird sich beispielsweise keine Programmieraufgabe ziehen (hoffentlich), jedoch ist das Team ansonsten sehr frei in der Gestaltung ihrer Arbeitsfolge & -abwicklung.
Product Backlog - Sprint Backlog - Pull Prinzip. Der Workflow:
Das Team
Ein Scrum-Team sollte möglichst klein sein und bis zu höchstens 10 Teammitglieder haben. Dadurch will man die ständige Kommunikation innerhalb des Teams nicht verkomplizieren. Für die Kommunikation sollte das Team sich im besten Fall räumlich nah stehen, um die Kommunikationswege möglichst einfach zu gestalten. Heutzutage kann man diese Voraussetzung durch Online-Meetings teilweise ersetzen, jedoch ist es am besten, wenn das Team tatsächlich vor Ort ist, um ständig in Kontakt zu sein, & nicht nur zu bestimmten Anlässen.
In einem Scrum-Team gibt es klar definierte Rollen.
Product Owner
Der Product Owner ist verantwortlich für das Endergebnis des Projektes und dessen Zwischenergebnisse. Dabei legt er die Eigenschaften des Projektes / Produktes fest & priorisiert die Anforderungen der Stakeholder, mit denen er im ständigen Austausch steht. Außerdem führt & pflegt der Product Owner das soeben genannte Product Backlog.
Scrum Master
Der Scrum Master ist dafür verantwortlich, dass alle Scrum-Prinzipien korrekt umgesetzt werden, indem er das Team coacht und unterstützt diese zu erfüllen. Dabei achtet der Scrum Master auch darauf, dass alle Ressourcen, die für den agilen Prozess nötig sind, vorhanden und greifbar sind. Gerade bei einer Neueinführung von Scrum ist seine Rolle besonders wichtig.
Projektentwickler
Die Projektentwickler arbeiten an der konkreten Umsetzung des Projektes und dessen Endergebnis und entscheiden dabei selbstständig und frei, wie sie die Anforderungen des Product Owner erfüllen. Innerhalb des Entwicklungsteams gibt es keine Hierarchien, jedoch verschiedene Fachbereiche (Design, Programmierung, Texter, etc.).
Stakeholder
Wie vorhin schon erwähnt, sind die Stakeholder (Kunde, Management, Anwender des Produktes) ebenfalls ein indirekter Teil des Teams. Sie werden regelmäßig in die Produktentwicklung mit einbezogen und nehmen an einigen Meetings teil.
Der Sprint
Der Sprint beschreibt den konkreten Arbeitsablauf eines Scrum Projektes, wobei ein Sprint im Normalfall 2 Wochen andauert. In diesem Zeitraum arbeitet das Team konzentriert & fokussiert an einem Teilziel des Projektes.
Sprint Planning
Das Sprint Planning ist der Start eines Sprints. Hier bestimmen Product Owner & das Entwicklerteam, welche Anforderungen im kommenden Sprint umgesetzt werden sollen, damit das Produkt zielorientiert vorangebracht wird.
Nach dem Sprint Planning, überlegt das Entwicklerteam, welche konkreten Arbeitsschritte notwendig sind und wer diese übernimmt, um die festgelegten Anforderungen zu erfüllen. Die Arbeitsschritte werden dann im Sprint Backlog festgelegt (Workflow: Anforderungen aus dem Product Backlog -> wandern in das Sprint Backlog & werden durch konkrete Arbeitsschritte ergänzt).
Ein Sprint Planning sollte nicht länger als 2 Stunden gehen und findet wöchentlich statt, um auf vorher nicht einsehbare Ereignisse reagieren zu können. In einem zweiwöchigen Sprint würde es also 2 Sprint Plannings geben.
Daily Scrum
Während eines Sprints, hält das Team ein tägliches Daily Scrum ab, wobei es um einen kurzen Austausch der Teammitglieder und den Aufgaben des Tages geht. Dabei sollte jeder aus dem Team berichten, wie er oder sie mit den Aufgaben am Tag zuvor zurechtkam & was seine oder ihre Aufgaben für den heutigen Tag sind.
Außerdem wird besprochen, ob es etwas gibt, dass das Scrum-Team daran hindert bestimmte Ziele zu erreichen, bzw. die Aufgaben erfolgreich abzuschließen.
Dabei darf ein Daily höchstens 15 Minuten dauern.
Sprint-Review
Am Ende jedes Sprints treffen sich Product Owner, Entwickler & Stakeholder, um die Ergebnisse des Sprints zu präsentieren & zu diskutieren, welche Anforderungen erfüllt wurden. Nach dem Feedback der Stakeholder legt der Product Owner die nächsten Anforderungen fest und passt sie im Product Backlog an.
Ein Sprint-Review sollte hierbei nicht länger als 90 Minuten dauern.
Sprint-Retrospektive
Zu guter Letzt trifft sich das Scrum-Team ohne die Stakeholder, um den vorangegangenen Sprint zu reflektieren. Es wird besprochen, was gut und was eher weniger gut lief und, zum Beispiel in Bezug auf die Kommunikation oder Scrum-Prozesse.
Danach legt man fest, ob und wenn ja was, man bei dem nächsten Sprint anders bzw. besser machen will. So schafft man es, den Scrum Prozess und die Zusammenarbeit stets zu optimieren.
Nach dem Sprint ist vor dem Sprint
Nachdem ein zweiwöchiger Sprint von Anfang bis Ende erfolgreich durchlaufen wurde, ist das Projekt noch lange nicht beendet. Es folgt nun Sprint nach Sprint, bis ein zufrieden stellendes Endergebnis zur Verfügung steht.
Visualisiert sieht ein vollständiger Sprint dann so aus:
Agiles Projektmanagement, die Lösung für alle Probleme?
Nun haben wir Dir ganz viele, tolle Dinge über agiles Projektmanagement und dessen Vorteile erzählt. Sollte es dann nicht jedes Unternehmen so machen und ist das klassische Projektmanagement damit überholt?
Definitiv Nein. Agiles Projektmanagement ist eine effektive Methode, die sich bei einigen Unternehmen und in vielen Situationen anbietet. Damit ist es nicht aber die „non-plus-ultra Variante", denn es bringt auch eine Menge Voraussetzungen mit sich.
Die Teammitglieder müssen beispielsweise erfahren und gewillt sein, um eine solche Methodik erfolgreich einzuführen. Ist das nicht der Fall, kann es sehr gut dazu kommen, dass man aufgrund der schnelllebigen Natur mit dieser Art und Weise Projekte zu entwickeln eher vom Weg abkommt und von dem Ziel weit abdriftet.
Außerdem gibt es auch Projekte, die agiles Projektmanagement aufgrund bestimmter Vorgaben und gewissen Umständen einfach nicht zulassen könnten. Klassisches Projektmanagement ist also nicht überholt worden, es hat aber klar herausgestellt, dass man in vielen Projekten & Teams mit der agilen Arbeitsweise erfolgreicher ans Ziel kommt. Gerade im Marketing bietet sich das agile Projektmanagement mehr als an, um der schnelllebigen Natur der Umstände gerecht zu werden und auf sie reagieren zu können.
Es gilt also: Agilität bringt viele Vorteile mit sich & kann die Ergebnisse und die Zusammenarbeit in vielen Unternehmen deutlich verbessern. Dennoch ist es nicht die Lösung für alles und sollte gezielt eingesetzt werden, um nachhaltigen Erfolg zu erzielen.
Hybrides Projektmanagement - ein Ausblick
Wer sich mit agilem Projektmanagement auseinandersetzt, wird definitiv auch auf den Begriff „hybrides Projektmanagement" treffen. Wie der Name vermutet, handelt es sich um eine hybride Variante, welche eine Mischform vom klassischen & agilen Projektmanagement ist & ihr Vorteile vereint.
Oftmals ist hybrides Projektmanagement der beste Mittelweg für Unternehmen, um die Vorteile des agilen Projektmanagements zu nutzen und dabei trotzdem nicht komplett an Struktur & dem gewohnten Habitat zu verlieren. Mehr zum hybriden Projektmanagement erfahrt ihr in einen der kommenden Blog-Beiträgen.
Wir freuen uns auf Dich!
Commentaires