Diese Website verwendet Cookies, um Ihnen bestmöglichen Service zu bieten. Wenn Sie auf der Seite weiter surfen, stimmen Sie der Cookie-Nutzung zu.

Ich stimme zu [x]

Agiles Projektmanagement nach SCRUM

Das wesentliche Hindernis im Klassischen Projektmanagement stellt der Aufwand dar, mit dem Projektveränderungen einhergehen. Das führt dazu, dass man mindestens eine gewisse Scheu hinsichtlich Projektveränderungen entwickelt. Damit kommt der initialen Zielerklärung eine wesentliche Bedeutung zu. Hier müssten im Grunde alle wesentlichen Anforderungen dokumentiert und geplant werden.

Ein klassisches Dilemma, denn oft verfügt man am Anfang nicht über ausreichende Informationen für wichtige Entscheidungen. Es empfiehlt sich daher zu recherchieren. Nicht selten ist der Recherche-Aufwand ähnlich hoch, wie die eigentliche Umsetzung. Zudem können sich bei sehr komplexen Projekten die Rahmenbedingungen ändern. Ansonsten wären die Entscheidungen überholt und die zeitintensiven Recherchen umsonst.

Eine Möglichkeit wäre, nicht alles bis ins kleinste Detail zu beschreiben, sondern sich schrittweise einer Umsetzung zu nähern. Damit das funktioniert, sind einige Regeln zu beachten. Ähnlich wie im klassischen Projektmanagement bietet auch das agile Projektmanagement nicht nur ein Regelwerk. Hier lässt sich die Scrum- und Kanban-Methodik beleuchten.

Ein Beispiel für die Scrum-Methodik: Jemand plant die Anlage eines Swimmingpools. Im klassischen Projektmanagement hätte man hierfür exakte Zeichnungen von dem Pool und dem Gelände erstellen müssen. Ebenso wären genaue Angaben über die Technik, die Umrandung, etwaige Zusatzbauten, die Begrünung, etc. notwendig gewesen.

Damit hätte man den Endtermin und die Gesamtkosten ermittelt und bei der anschließenden Umsetzung die Planung regelmäßig den Gegebenheiten angepasst. Vielleicht wäre in diesem Fall auch ein Verabschiedung von einigen Scope-Bestandteilen angezeigt hätten diese nicht in den Zeit- oder Kostenrahmen hineingepasst.

Bei der agilen Umsetzung gibt es zwar auch ein Projektziel, dieses ist aber nicht exakt beschrieben, sondern nur umrissen. Das macht man mit sogenannten EPIC’s – also relativ groben Anforderungsbeschreibungen.

So könnte man für den Pool, ein Epic für die Landschaftsgestalung und ein Epic für zusätzliche Bauten erstellen, indem die eigenen Vorstellungen fetsgehalten sind.

Im weiteren Verlauf beginnt man nun die Epic’s zu verfeinern. Die Elemente, die wiederum ein Epic beschreiben nennen sich UserStories - also Anwendungsberichte. Hier wird es schon wesentlich konkreter. Diese Anwenderberichte können letztlich wiederum in die Story-Items heruntergebrochen werden. Man kann sich das so ähnlich wie beim Projektstrukturplan vorstellen.

Der wesentliche Unterschied ist allerdings, dass dies nicht für alle Anwenderberichte getan wird, sondern nur für die, die als nächstes umgesetzt werden.

Alle UserStories landen im ProductBacklog – quasi einem Zwischenlager für alle noch nicht in der Umsetzung befindlichen Anforderungen. Dieses Backlog wird regelmäßig u.a. vom Productowner - also dem Produktinhaber - neu geordnet und priorisiert.

Bei der Steuerung kommt ein weiterer wichtiger Aspekt des agilen Projektmanagements zum Tragen. Man einigt sich im Team auf einen Zeitraum, in dem die UserStories umgesetzt werden. In diesem will man beispielsweise alle 2 Wochen die Ergebnisse übergeben; dieser Zeitraum nennt sich Sprint. Hierzu befüllt man am Anfang der zwei Wochen das Projekt aus dem ProductBacklog. Zur Erinnerung: Das ist ein Zwischenlager für alle bereits beschriebenen UserStories. Hier können Kunde und ProductOwner die Reihenfolge der Elemente beliebig ändern. Nicht allerdings im Spint. Das Team bedient sich nun also selbstständig und verteilt die Aufgaben untereinander. Der Scrum-Master moderiert diesen Prozess und die laufende Kommunikation.

Nachdem sich jeder eine Aufgabe genommen hat, sollte man mit der Umsetzung beginnen. Damit keine Abstimmungsfehler entstehen, wird nun jeden Tag mit einem kleinen Meeting (DailyScrum) begonnen. Hier berichten alle am Projekt beteiligten Personen über Fortschritte und etwaige Probleme. Dann geht es wieder zur Umsetzung.

Am Ende der zwei Wochen sollten die vom Team ausgewählten Aufgaben abgeschlossen sein, sodass das Team die nächsten Aufgaben aus dem Backlog entnehmen kann.

Hierbei gilt: Wird eine UserStory nicht vom ProductOwner oder Kunde akzeptiert, geht diese zurück in das ProductBacklog und muss ggf. neu beschrieben werden, sodass diese dann wieder im nächsten Umsetzungsdurchlauf verbessert werden kann.

Durch diese dynamische Planung und Steuerung können ProductOwner und Kunde theoretisch alle 2 Wochen den Plan und damit die Umsetzung beeinflussen. So lassen sich neu gewonnene Erkenntnisse aus dem vorangegangenen Sprint jederzeit einbringen.

Das Beispiel mit dem "Pool" aus dem letzten Teil wird hier wieder aufgegriffen.

Manchmal erkennt man nach dem Ausheben eines Loches, dass der Untergrund im mittleren Bereich des Pools sehr felsig ist. Unser Epic „Pool“ wird nun um eine UserStory mit dem Titel „kleine felsige Insel“ ergänzt. Die dafür notwendigen Schritte werden wiederum von den Experten skizziert und in der Folgeperiode umgesetzt, sofern in der Prioritätenliste nicht bereits andere Aufgaben stehen.

Aufgaben, die man sich für eine Periode vorgenommen hatte, werden in der Folgeperiode beendet und damit etwas weniger neue Aufgaben in das Projekt aufgenommen. Allerdings sollte eine  solche Situation nach Möglichkeit vermieden werden. Besser ist es, die UserStories klein zu halten und diese in der verfügbaren Zeit umzusetzen.

Damit wird eine kontinuierliche Projektgeschwindigkeit gewährleistet, die dennoch rollierend Änderungen als Standardvorgehen kennt. Der Productowner und der Kunde können damit schrittweise das „Werk“ entstehen sehen und nehmen darüber hinaus fortlaufend Einfluss. Dass Team kann davon unberührt schrittweise die Themen umsetzen.

So werden lange Diskussionen über noch weit in der Zukunft liegende Anforderungen vermieden, zumal sich diese Erkenntnisse auch noch oft ändern.

Da es hierbei keinen fest vereinbarten Endtermin bzw. Projektumfang gibt, muss das Projektende bilateral zwischen den Parteien festgelegt werden. Zum Beispiel: „Soweit wie wir bis zum Wintereinbruch kommen!“

Niemand kann am Anfang sagen, was genau zu dem Zeitpunkt fertiggestellt sein wird. Auch sind nicht alle Anforderungen zu diesem Zeitpunkt bekannt, was bei der klassischen Planung immer wieder zu Fehleinschätzungen und Planänderungen führt.

Das A und O bei der agilen Umsetzung spielt die stetige Kommunikation im Team und zwischen Team und Productowner und Kunde. Das Team übernimmt eine größere Verantwortung für die Planung und Steuerung. Unterstützt wird dies durch den ScrumMaster.

Ein ScrumTeam sollte möglichst ungestört von anderen Projekten arbeiten können. Ein agiles Projekt benötigt ein stabiles Ressourcenumfeld. Nur so lässt sich die intensive Kommunikation und die kurzfristigen Umsetzungsziele bewerkstelligen.

Sie möchten Ihre Projekte clever managen?

Mehr zum Thema  Entdecke Blue Ant

Vertrieb

Holger Eckert
+49 (0)30 293 63 99 - 13
vertrieb@proventis.net

Marketing

Simone Wesche
+49 (0)30 293 63 99 - 10
marketing@proventis.net

proventis GmbH

+49 (0)30 293 63 99 - 0
Alte Jakobstr. 83/84
10179 Berlin