Was ist agiles Projekt-management?

sicher habt Ihr Euch schon einmal gefragt, was genau der Unterschied zwischen klassischem und agilem Projektmanagement ist. In diesem Blogeintrag bekommt ihr einen Einblick in die wunderbare Welt des agilen Projektmanagements.
Eine zentrale Rolle beim agilen Projektmanagement spielt die direkte und offene Kommunikation innerhalb des Projektteams, sowie gegenüber dem Auftraggeber. Flache Hierarchien werden implementiert und Umsetzungszyklen erlauben kurzfristige Änderungen. Beim agilen Projektmanagement werden klassische Ansätze, wie Abläufe, Aufgaben und Rollen hinterfragt. Im Gegensatz zum klassischen Projektmanagement ist das agile Projektmanagement flexibler und zukunftsorientierter als das klassische Projektmanagement. Das klassische Projektmanagement eignet sich besonders für Projekte mit wenig Umfang, oder kurzer Dauer. Vorhaben in der Produktion, die vorrangig sequenzielle ablaufende Vorgänge beinhalten und wiederkehrende Projekte sind ebenfalls geeignet. Das agile Projektmanagement ist für große, komplexe Projekte geeignet, deren Anforderungen wenig vorhersehbar sind. Diese Projekte müssen oft hohe Risiken berücksichtigen. Das agile Projektmanagement hat seinen Ursprung in der Softwareentwicklung. Frameworks bzw. Methoden, die in diesem Zusammenhang verwendet werden, sind Scrum und Kanban. Ein Beispiel für eine klassische Projektmanagementmethode ist die Wasserfall-Methode.

Ich möchte Euch am Beispiel aus der Softwareentwicklung verdeutlichen, wie klassische Projekte und agile Projekte im Vergleich ablaufen.
Bei klassischen Projekten kalkuliert der Auftragnehmer auf Grundlage der Kundenwünsche Budget und Zeit. Wenn wir nun die Entwicklung einer Applikation als Beispiel nehmen - In der ersten Phase werden detaillierte Pläne für die Applikation ausgearbeitet. Der Auftraggeber stimmt den Plänen zu und die Entwicklung beginnt. Nach Fertigstellung wird die Applikation vom Auftraggeber gesichtet. Bei einem Änderungswunsch muss der Auftraggeber evaluieren, ob er Mehrkosten in Kauf nehmen kann bzw. will.
Bei agilem Projektmanagement legt der Auftraggeber zu Beginn des Projektes Budget und Zeit fest, mit dem Ziel, das Projekt in diesem Rahmen bestmöglich zu realisieren. Nach Fertigstellung des Prototyps, treffen sich Auftraggeber und Auftragnehmer zu einem gemeinsamen Rückblick (Scrum = Review). Es wird gemeinsam geschaut, wie viel Budget übrig ist. Änderungswünsche des Auftraggebers können geäußert und im nächsten Abschnitt (Scrum = Sprint) umgesetzt werden. Nach jedem Abschnitt gibt es einen Review und der Auftraggeber gibt den nächsten Sprint frei.

Wir verwenden im Rahmen der Entwicklung verschiedener Applikationen die Methode Scrum. Um Euch einen kurzen Einblick zu geben, habe ich nachfolgend die verschiedenen Rollen und Ereignisse aufgeführt:

Der Product Owner ist in erster Linie Ansprechpartner für das Entwicklungsteam, Kunden und Stakeholder. Er priorisiert die Anforderungen und nimmt am Ende jedes Sprints die Verwirklichung der Anforderungen ab. Zu den Aufgaben des Product Owners zählen Aufgabenzuweisung, sowie deren Priorisierung, Kontrolle und Pflege des Product Backlogs.

Der Scrum Master stellt sicher, dass das Team operativ und produktiv arbeiten kann. Er achtet darauf, dass alle Scrum-Regeln reibungslos für das Scrum Team funktionieren. Er beseitigt Hindernisse und sorgt für eine lückenlose Kommunikation zwischen dem Product Owner und dem Scrum Team.

Das Entwicklungsteam organisiert sich selbst und kümmert sich um die Erreichung der Sprintziele unter Einhaltung des vereinbarten Qualitätsstandards.

Im Sprint Planning wird geplant, was im kommenden Sprint entwickelt werden kann und wie die Aufgaben im kommenden Sprint organisiert werden. Gemeinsam werden sogenannte Tickets aus dem Product Backlog in den Sprint Backlog gezogen.

Das Daily Meeting ist ein kurzer Statusbericht des Teams. Das Team kommt zu einer festgelegten Zeit für maximal 15 Minuten zusammen, um einen aktuellen Überblick über die laufenden Aufgaben zu geben.

Das Sprint Review steht am Ende des Sprints. Das Entwicklungsteam präsentiert die Ergebnisse und gemeinsam wird kontrolliert, ob das angestrebte Ziel erreicht wurde. Alle Teilnehmer der Sprint Review können offen Feedback und Verbesserungsvorschläge mitteilen. Der Product Owner legt auf dieser Grundlage das weitere Vorgehen fest.

In der Sprint Retrospektive wird gemeinsam mit dem Scrum Master erörtert, wie die Arbeitsweise des abgeschlossenen Sprints effektiver und effizienter gestaltet werden kann. Um Rückschlüsse für den nächsten Sprint ziehen zu können, werden gemeinsam positive und negative Aspekte aufgeführt.

Beim Product Backlog handelt es sich um eine Liste von Anforderungen mit Schätzwerten, die den Umfang der Aufgaben widerspiegeln.

Im Sprint Backlog stehen die Forderungen, die innerhalb eines Sprints anfallen. Diese Liste wird täglich von allen Projektbeteiligten gepflegt und somit während des laufenden Sprints immer weiter aktualisiert. Es werden Arbeitsfortschritte und aktuelle Bearbeitungsstände aufgeführt.

Das vorzeigbare Ergebnis des Sprints wird als Product Increment bezeichnet und wird in der Review von den Bearbeitern präsentiert.
Besonders wichtig bei Scrum ist die Priorisierung der vielfältigen Ansprüche des Kunden durch den Product Owner, denn auch hier gilt: Wenn alles Priorität hat, hat nichts Priorität.