instagram-like twitter-favourite twitter-reply twitter-retweet weather-cloudy weather-night weather-rain weather-snow weather-sunny

12.05.2020 • Berlin Von klassischem zu agilem Projektmanagement

Mann zeigt auf Haftnotizen

Wie die Transformation gelingt

 

Die agile Denk- und Arbeitsweise hat sich in Unternehmen und Agenturen immer stärker durchgesetzt. Manche sehen die agilen Prinzipien gar als Master-Antwort auf die schnelllebige Produktwelt und Lebensweise des Nutzers. Eine agile Transformation bringt jedoch einige Herausforderungen mit sich. Bisherige Unternehmens- oder projektspezifische Rollen und Aufgaben finden sich in agilen Frameworks oft nicht wieder. Einen Fahrplan, wie diese in eine agile Arbeitsweise zu überführen sind, gibt es meist nicht. Interdisziplinäre Teams aus Kreativen und Entwicklern werden neu aufgestellt, aber wie können sie wirklich zusammenarbeiten? Und was passiert mit den klassischen Aufgaben des Projektmanagements im agilen Projektgeschäft? 

 

Vorweg: Rollen-Begriffe

Zum besseren Verständnis werden die agilen Rollen nach Scrum verwendet: Product Owner (PO), Scrum Master (SM) und Team. Diese Benennungen haben sich im Zusammenhang mit agilem Arbeiten weitestgehend durchgesetzt. Zudem ist es möglich, dass im Projekt Experten notwendig sind, die nicht permanent zum Team gehören. 

Neue Rollen und Aufgaben: Klarheit schaffen und Ziele definieren

Entwickelt man das klassische Projektmanagement hin zu einer agilen Arbeitsweise, gibt es verschiedene Möglichkeiten der Aufgabenverteilung. Eine ist, dem bisherigen Projektmanager die Rolle des Product Owners zu übergeben. Die Position des PO könnte andererseits aber auch jemand mit umfassender Erfahrung in anderen Bereichen, zum Beispiel im Produktdesign, repräsentieren – solange die eher klassischen Management-Aufgaben ebenfalls abgedeckt werden. Beispielsweise, indem der PO in diesem Fall durch ein Projektmanagement Office (PMO) unterstützt wird. Der PO behält dabei jedoch die Verantwortung für das Produkt sowie für Budget und Timings. 

Egal wie, durch die Veränderung von Verantwortlichkeiten und die neue Aufgabenverteilung können Unsicherheiten entstehen. Das notwendige Hinterfragen und Anpassen etablierter Prozesse und Zuständigkeiten kann dies noch verstärken. Diese Unsicherheit kann dazu führen, dass der PO eine Blockadehaltung einnimmt oder versucht, abgegebene Kontrolle zurückzuerlangen, anstatt Maßnahmen für einen Erfolg des agilen Vergehens zu etablieren und Vertrauen in das Team aufzubauen. 

Deshalb gilt es, in jedem Schritt der Transformation sicherzustellen, dass Rollen und Aufgaben jedem völlig klar sind. Es empfiehlt sich, die Transformation mit einer IST-Analyse der Alltagsaufgaben und -prozesse zu starten. Anhand dessen wird festgelegt, was überhaupt in eine agile Arbeitsweise überführt werden soll. Der Zielzustand muss detailliert definiert sein. Das gilt sowohl für Tätigkeiten innerhalb der Organisation als auch in den Projektabläufen. Wichtig dabei: die Personen beteiligen, die mit den Aufgaben betraut sind und deren Anforderungen genau kennen.

Projektmanagement-Aufgaben transformieren 

Die Aufgaben des Projektmanagements betreffen sowohl die Arbeit mit dem Team, die übergreifende Arbeit innerhalb des Unternehmens als auch die Zusammenarbeit mit Stakeholdern. Zu den klassischen Aufgaben des Projektmanagements gehören beispielsweise: Angebotserstellung, Anforderungsdefinition, Erstellung einer Produkt-Roadmap und Projektplanung sowie Überwachung von Budget und Timings. Zum großen Teil überschneiden sich diese Aufgaben mit denen eines PO. Dies gilt besonders für die Projektphasen vor der eigentlichen Durchführung: Projektanbahnung und -setup (Initiierungsphase).

 

1. Meilensteine festlegen

Im klassischen wie im agilen Vorgehen ist es wichtig, Meilensteine zeitlich festzulegen – auch wenn aufgrund des agilen Vorgehens das genaue Produktergebnis nicht bekannt ist. Alle Produkte müssen im späteren Projektverlauf kontinuierlich überprüft und ggf. angepasst werden. Der PO ist dabei in der Verantwortung. Der Scrum Master, aber auch das Team und zusätzliche Experten sollten den PO dabei unterstützen und mögliche Laufzeiten von Arbeitspaketen oder Themen verifizieren. Dadurch wird zudem eine gemeinsame Erwartungshaltung an das Projekt und den Projektverlauf entwickelt. 

2. Prozesse und Routinen etablieren

Im Rahmen des Projektsetups müssen Prozesse und Meeting-Strukturen definiert werden: mit Stakeholdern, innerhalb des Teams oder mit weiteren externen Teams. Im agilen Projekt ist neben dem PO vor allem der Scrum Master (SM) gefordert, für die Ausgestaltung zu sorgen: Wie wollen die Beteiligten zusammenarbeiten? Welche Meeting-Routinen gibt es? Wer nimmt teil und wie sind die Arbeitsabläufe im Team? Der SM tritt dabei nicht als Entscheider auf, sondern unterstützt alle Beteiligten dabei, Lösungen zu finden und die Vereinbarungen später einzuhalten. Wichtig ist, das Team und alle Beteiligten zu involvieren, sodass Feedback berücksichtigt wird und ein Konsens entstehen kann. Ein „Diktat von außen“ wird im agilen Vorgehen auf Widerstand treffen. Aber es darf auch nicht vergessen werden, dass das Team mit neuen, agilen Arbeitsweisen und gesteigerter Verantwortung erst zurechtkommen muss.  

In die Meeting-Routinen, Arbeitsweisen und Vorgaben fallen auch spezielle Produkte aus z.B. Scrum, wie der „Definition of Ready“ und „Definition of Done“, oder auch andere Vorgaben, wie ISO-Standards in der Arbeitsweise einer Profession. Dies widerspricht keineswegs der agilen Arbeitsweise, solange die Prinzipien dennoch eingehalten werden können.

3. Planung und Controlling sicherstellen

Der PO gibt die Produktrichtung vor und muss den ROI (return on investment) sicherstellen. Somit ist er auch für die Releaseplanung und das Management verantwortlich; das heißt die Lieferzeitpunkte, den Funktionsumfang und die Kosten, die für das Release entstehen. Im größeren Projektkontext kann die Aufgabe zwar auch an einen speziellen Releasemanager delegiert werden, die Hauptverantwortung bleibt aber nach wie vor beim PO. Releaseplanung sowie Projektplanung können gerade bei kleinen Projekten den gleichen Output haben, somit als Synonym verstanden werden. Bei größeren Projekten sind jedoch neben dem eigentlichen Release so viele zusätzliche Tätigkeiten und Termine wahrscheinlich, dass neben der Releaseplanung aus funktionaler Sicht eine Projektplanung Sinn macht.

Da der ROI in der Verantwortung des POs liegt, ist auch das Projektcontrolling in seiner Hand. Ein Projekt-Management-Office kann Auswertungen zuarbeiten, notwendige Entscheidungen muss jedoch der PO treffen. Die Sprintplanung wiederum erfolgt durch das Team, unterstützt vom Scrum Master. Das Team bestimmt, wie viel im Sprint geschafft werden kann und ist für die Einhaltung des Ziels verantwortlich. Gleiches gilt für die täglichen Aufgaben innerhalb des Sprints.

 

Geduld für die Umstellung mitbringen

Startet man ein agiles Projekt mit einem neuen Team, geht man üblicherweise davon aus, dass es etwa drei Sprints mit einer Dauer von je zwei oder drei Wochen benötigt, bis sich das Team zusammengefunden und an die Prozesse gewöhnt hat. Bei der Einführung einer agilen Projektarbeitsweise mit einem weitgehend unerfahrenen Team kann es länger dauern, bis die agilen Ansätze durchdrungen sind. Das gilt auch für das Projektmanagement, dem man Zeit und Geduld geben muss, sich auf die neuen Prozesse und Zuständigkeiten umzustellen und Lösungen für das agile Projektgeschäft zu finden. Die Herausforderung beginnt bereits in der Projektinitiierung: Der PO muss hier berücksichtigen, wie die zukünftige Arbeitsweise aussehen wird. Zusätzlich muss entschieden werden, für welche Themen der Scrum Master und das Team in der Projektinitiierung zuständig sind. PO, die gerade ihre die Rolle gerade erst übernommen haben, sollten durch erfahrene Scrum Master oder PO-Kollegen unterstützt werden. 

Agile Frameworks um individuelle Lösungen ergänzen

Eine agile Transformation ist wie bei vielen grundlegenden Veränderungen ein längerer Prozess: Es braucht Zeit, bis sich die Projektteams mit den neuen Gegebenheiten arrangiert haben. Da Frameworks wie Scrum, Kanban und Co. nicht alle Besonderheiten der verschiedenen Projekttypen, Disziplinen und Rahmenbedingungen abdecken können, wird man zwangsläufig einen eigenen Weg ausarbeiten müssen. Das gilt auch für die Anpassung der Projektmanagement-Aufgaben. Der PO sollte im Laufe der Projekte seine Tätigkeiten und Ergebnisse einer regelmäßigen Prüfung auf Optimierungspotentiale unterziehen, ähnlich der Retrospektive im Team. Der Scrum Master und das Team können hier wertvolle Ansatzpunkte liefern. 

Auch wenn die Einführung einer agilen Arbeitsweise komplex wirken mag, lohnt sich der Aufwand. Beherzigt man in der Durchführung Prinzipien wie transparente Kommunikation, die konsequente Beteiligung von Mitarbeitern und Experten und die Einführung einer kontinuierlichen, transparenten Priorisierung aller Aufgaben, lassen sich Unklarheiten vermeiden. Zudem gilt: agile Frameworks bleiben Frameworks. Man sollte keine Hemmungen haben, sie um eigene Lösungen zu ergänzen.

 

Autor: Sebastian Knebel

Sebastian Knebel ist Associate Director Project Leads bei Aperto. Als Teamleiter ist er verantwortlich für die fachliche Weiterentwicklung des Projektmanagements innerhalb von Aperto und berät Kunden, Teams und Projekte in der Projektvorbereitung, -durchführung und der Auswahl der richtigen Methoden und Projektvorgehen. Sebastian Knebel arbeitet zudem als Projektleiter und Product Owner insbesondere im Bereich der Softwareentwicklung.

 

Was können wir für Sie tun?

WIR FREUEN UNS AUF IHRE ANFRAGE

Hier finden Sie alle Neuigkeiten zu unserer Agenturgruppe. Zudem können Sie sich in unseren Presseverteiler aufnehmen lassen. Das lohnt sich. Denn wir haben regelmäßig etwas mitzuteilen – zu neuen Projekten, spannenden Entwicklungen und künftigen Veranstaltungen.

Kontakt

Nicole Ruhl, Marketing & PR
Aperto – An IBM Company
Chausseestr. 5
10115 Berlin
Deutschland
+49 30 283921­-268
presse@aperto.com