2. August 2017

Marketing- und Kommunikationsmanagement,

3 Stolpersteine der agilen Projektmanagement-Methode Scrum

Agiles Projektmanagement ist in aller Munde und scheint ein Allheilmittel zu sein, wenn altbewährte Methoden nicht zum gewünschten Erfolg führen, gefasste Ziele nicht erreicht werden oder gar komplette Projekte scheitern. Doch wie lässt sich eine agile Methode wie Scrum in einer Firma mit veränderungsresistenten Mitarbeitenden und in Teams mit starren Strukturen und festgefahrenen Prozessen einführen? Welche Stolpersteine bringt Scrum mit sich? Ein Erfahrungsbericht weshalb diese agile Projektmanagement-Methode in der Praxis scheitern kann.

*Quelle: http://ikm-hslu.ch/omm-blog, 30. April 2017.

Agile Projektmanagement-Methoden setzen auf Flexibilität und Adaption. Sie unterscheiden sich in zwei wesentlichen Punkten von klassischen Ansätzen wie beispielsweise dem Wasserfallmodell. Erstens ist das Vorgehen ein anderes. Am Anfang eines Projekts steht nicht wie bei klassischen Modellen eine umfangreiche und ausführliche Planung sondern die Planung verläuft agil mit kurzfristigen Absprachen im Team. Zweitens sind die definierten Rollen der Beteiligten und die Zusammensetzung des Teams ein wesentlicher Unterschied zur klassischen Projektplanung. Das Team ist nicht hierarchisch sondern interdisziplinär zusammengesetzt und organisiert sich weitgehend selbst.

Von der Vision zum Produkt: der Scrum-Prozess schematisch dargestellt.

Scrum kurz erklärt

Der Begriff Scrum (zu deutsch «Gedränge») stammt aus dem Rugby. Er beschreibt einen dichten Haufen von Spielern welche um den Ball kämpfen. Übertragen auf das Projektmanagement beschreibt Scrum worum es bei dieser agilen Projektmanagement-Methode hauptsächlich geht: Dynamik, Flexibilität und kurze, tägliche Meetings (Daily Scrums) in welchen sich die Teammitglieder abstimmen. Im Scrum-Modell werden Projekte nicht starr anhand eines langfristig angelegten Plans durchgeführt. Die Planung erfolgt anhand sogenannter Sprints (ein- bis vierwöchige Bearbeitungszyklen) in denen die vorab definierten Teilaufgaben bearbeitet, getestet und finalisiert werden. In einem Backlog werden die Tasks gesammelt, beschrieben und priorisiert. Das Backlog dient als Massnahmenplan für die einzelnen Sprints.

Das Team

Ein Team besteht aus zirka vier bis zehn Personen und wird fachübergreifend, beispielsweise aus Gestaltern, Entwicklern, Testern und Redakteuren zusammengestellt. Für das selbstständig agierende Team werden folgende drei Rollen definiert: Ein Product Owner, ein Scrum Master und das Projektteam.

Der Product Owner vertritt die Stakeholder des Projektes, hat die Budgetverantwortung und pflegt das Product Backlog. Er sortiert und priorisiert die Aufgaben im Product Backlog und stellt sicher, dass das Projektteam die Aufgaben versteht.

Der Scrum Master ist Unterstützer für das Projektteam. Er ist verantwortlich für den Scrum-Prozess und stellt sicher dass dieser korrekt abläuft und alle Beteiligten ihre Rollen einhalten. Weiter schützt er das Projektteam vor Eingriffen und sorgt dafür dass Hindernisse beseitigt werden. Er hat das komplette Projekt im Blick und moderiert er die Daily Scrums.

Das Projektteam verantwortet die Umsetzung und die Qualität des Produkts. Im Team gibt es keine Hierarchie. Jeder hat dieselben Rechte und Pflichten. Das Projektteam organisiert alle Aufgaben selbst und definiert welches Mitglied welche Aufgabe umsetzt.

Quelle: YouTube Video – mITSM GmbH.

Stolperstein 1 – Wenn Scrum top-down eingeführt wird

Eine agile Methode wie Scrum erfolgreich einzuführen bedeutet eine komplette Veränderung der Firmenkultur. Das Verlangen nach starren Strukturen und linearen Prozessen muss, in den Köpfen aller Beteiligten, aufgelöst werden. Wenn Scrum als Idee des Managements oder der Geschäftsführung eingeführt wird, sind Konflikte vorprogrammiert. Vor allem dann, wenn Scrum mit der Absicht «wir müssen mal eben agil werden und frischen Wind in die Firma bringen» oder ähnlichen Motiven initiiert wird, ist der Einsatz von Scrum zum Scheitern verurteilt. Die notwendige Kultur für Scrum muss zuerst aufwändig geschaffen werden. Wenn die Mitarbeitenden nicht rechtzeitig eingebunden werden, entwickeln sie eine Abwehrhaltung oder kommen schlichtweg nicht mit den Veränderungen klar. Es ist ratsam, Scrum begleitet von Schulungen einzuführen um alle Beteiligten langsam an die Methode zu gewöhnen.

Scrum ist nicht für jede Firma in jedem Fall ein Allheilmittel. Es ist ratsam, bei Problemen nach der Ursache zu forschen, bestehende Prozesse zu analysieren und rechtzeitig in den Dialog mit allen Beteiligten zu treten. Scrum als wunderwirkende Hauruck-Aktion einzuführen, empfiehlt sich nicht.

Stolperstein 2 – Wenn Agilität falsch interpretiert wird

Agiles Projektmanagement bedeutet nicht, dass dauernd spontane Einfälle eingeflochten werden. Gerade innerhalb eines Sprints gilt es die Regeln zu beachten. Die pro Sprint definierten Anforderungen sollen nicht verändert, ergänzt, gelöscht oder in ihrer Priorität verändert werden. Es besteht die Gefahr, dass spontane Einfälle mit Bemerkungen wie «deshalb arbeiten wir doch agil» berechtigt werden und in laufende Sprints eingegriffen wird. Wenn neue Anforderungen vom Management kommen, ist es für den Product Owner besonders schwierig sich ans Backlog und die Tasks im aktuellen Sprint zu halten.

Vertrauensvolle Zusammenarbeit auf Augenhöhe ist im Scrum zentral. Das gilt auch fürs Management. Diese Kultur muss jedoch, wie im ersten Stolperstein beschrieben, vorab erfolgreich geschaffen werden. Wenn die Regeln innerhalb eines Sprints nicht befolgt werden besteht die Gefahr, dass das Team nie zu einem zufriedenstellenden Resultat kommt. Das Backlog soll durch neue, kreative Ideen anwachsen. Diese müssen aber stets priorisiert werden. Nur eine vorab definierte Anzahl der Tasks wird pro Sprint bearbeitet. Übertriebene Agilität führt schlussendlich bei allen Beteiligten zur Frustration.

Stolperstein 3 – Wenn die Rollen nicht umgesetzt werden

Das Modell Scrum sieht drei spezielle Rollen vor: der Product Owner, der Scrum Master und das Projektteam. Die Rolle des Chefs oder des klassischen Projektleiters ist nicht dabei, obwohl zwei Rollen auf den ersten Blick ähnlich zu sein scheinen. Erstens hat der Product Owner wohl die Budgetverantwortung und treibt das Projekt im Sinne der Stakeholder voran, ist aber nicht der Chef eines Teams. Zweitens verantwortet der Scrum Master zwar den Scrum-Prozess und agiert als Dienstleister für das Projektteam, übernimmt aber nicht die Rolle eines Projektleiters. Die komplette Projektkommunikation ist direkt und transparent. Allen im Team ist die Gesamtheit eines Projekts jederzeit bekannt.

In hierarchisch geführten Teams können die Rollenverteilung sowie die offene Kommunikation, bei der Einführung von Scrum, zu Verunsicherungen führen. Denn weder der Product Owner noch der Scrum Master definieren, welches Projektteammitglied welche Aufgabe wie zu erledigen hat noch verlangen sie einen Rapport. Es ist im Scrum wichtig, dass das Team sich selbst organisiert, alle ihre Aufgaben selbstständig planen und direkt miteinander absprechen. Allerdings gilt es zu bedenken, dass nicht jeder Mitarbeitende bereit oder fähig dazu ist, diese Rolle ohne weitere Unterstützung, zeitnah einzunehmen.

Fazit

Für Scrum muss in erster Linie die Denkweise der kompletten Firma verändert werden und das geschieht nicht über Nacht. Um den agilen Wasserfall, die Vermischung einer traditionellen Projektmanagement-Methode mit einer agilen Methode zu verhindern, muss genügend Zeit in die Einführung investiert werden. Scrum funktioniert weder als Befehl vom Management noch kann die Methode nebenbei eingeführt werden. Sinn und Zweck von Scrum müssen allen Beteiligten klar sein. Überschnelle Veränderungen führen zu Unsicherheiten und Frustrationen bei den Mitarbeitenden.

Agiles Projektmanagement bedeutet nicht, dass unüberlegt vorgegangen wird. Die Pflege und Abarbeitung des Backlogs ist eine Schlüsselaufgabe im Scrum. Ans Backlog und die Laufzeit der Sprints müssen sich alle Beteiligten halten, auch das Management. Grenzenlose Agilität führt einerseits dazu dass ein Projekt nie abgeschlossen werden kann, andererseits zum Verlust der Motivation im Team.

Die drei speziellen Rollen (Product Owner, Scrum Master, Projektteam) müssen verstanden und umgesetzt werden, nur so kann Scrum Freude bereiten. Die agile Methode bedingt eine nicht hierarchische, vertrauensvolle Zusammenarbeit aller Beteiligten. Von oben braucht es dafür kontinuierlich Unterstützung sowie Ermutigung und von unten Selbstverantwortung und -motivation.

Und ihr?

Habt ihr Erfahrung mit agilen Projektmanagement-Methoden? Wenn ja, wie habt ihr diese implementiert so dass sich alle im Team in ihrer neuen Rolle wohl fühlen und die Projekte erfolgreich abgewickelt werden können?

Weiterführende Informationen:

Buchempfehlung:

Agiles Publishing: Fokus auf den Nutzer, das Silo-Denken beenden: Neue Wege des Publizierens für Print, Web und Apps.
Autoren: Hagemann, Detlev; Obermayr, Georg; Günther, Matthias. Verlag: Kastner. Erscheinnungsjahr: 2013.
Zu kaufen bei Buchhaus.ch für CHF 55.90.