Scrum-Techniken im Projekt – darf's ein bisschen mehr sein?
Seit ein paar Monaten habe ich die Gelegenheit, in einem komplexen IT-Projekt das Verzahnen von nicht-agilen Projektmanagement-Prozessen mit einzelnen Scrum-Techniken wie Sprint-Planung, Sprint-Backlog, Review, Retrospektive und Burn-Down-Chart zu verfolgen – ohne dass in der Organisation Scrum als Standard im Projektmanagement eingeführt wurde oder werden soll. Das Herantasten der Projektbeteiligten an die (neue) Agilität – also an eine neue Eigenverantwortung, wenn auch in engem Rahmen –, ist sehr spannend zu beobachten. Wie auch die Stolpersteine, die dabei zu beobachten sind.
Scrum-Techniken im Projekt – darf's ein bisschen mehr sein?
Seit ein paar Monaten habe ich die Gelegenheit, in einem komplexen IT-Projekt das Verzahnen von nicht-agilen Projektmanagement-Prozessen mit einzelnen Scrum-Techniken wie Sprint-Planung, Sprint-Backlog, Review, Retrospektive und Burn-Down-Chart zu verfolgen – ohne dass in der Organisation Scrum als Standard im Projektmanagement eingeführt wurde oder werden soll. Das Herantasten der Projektbeteiligten an die (neue) Agilität – also an eine neue Eigenverantwortung, wenn auch in engem Rahmen –, ist sehr spannend zu beobachten. Wie auch die Stolpersteine, die dabei zu beobachten sind.
Seit ein paar Monaten habe ich die Gelegenheit, in einem komplexen IT-Projekt das Verzahnen von nicht-agilen Projektmanagement-Prozessen mit einzelnen Scrum-Techniken wie Sprint-Planung, Sprint-Backlog, Review, Retrospektive und Burn-Down-Chart zu verfolgen – ohne dass in der Organisation Scrum als Standard im Projektmanagement eingeführt wurde oder werden soll. Das Herantasten der Projektbeteiligten an die (neue) Agilität – also an eine neue Eigenverantwortung, wenn auch in engem Rahmen –, ist sehr spannend zu beobachten. Wie auch die Stolpersteine, die dabei zu beobachten sind.
Und doch: Erste brauchbare Ergebnisse (Quick Wins) wurden vom Team schnell vermeldet, von Erhöhung der Transparenz und dem frühzeitigem Erkennen von Risiken wurde berichtet. Es funktioniert bisher auch gut, das jeweilige Sprint Backlog aus dem Product Backlog zu definieren. Schwierigkeiten zeigten sich eher in der Aufwandsplanung für die einzelnen Sprints: Teammitglieder wie auch externe Berater schätzten den Aufwand für die Aktivitäten des Sprints zu niedrig oder ihre verfügbare Kapazität dafür zu hoch ein.
Ein bisschen "Scrum-Aroma"
Bisher ist die Bewertung der Vorgehensweise im Rahmen der Retrospektiven positiv, der Lernprozess ist erkennbar – aber die Erfahrungen bei weitem noch nicht ausgereift. Was bedeutet nun dieser kleine Mosaikstein, der hier getestet wird? Ein wenig "Scrum-Aroma" in der üblichen Suppe?
Dass anhand dieser ersten "Gehversuche" bei der Anwendung von Scrum-Techniken bei weitem noch nicht von Agilität gesprochen werden kann, zeigt schon ein kurzer Blick auf die Agilen Werte (2001):
Agiles Manifest von 2001
"Wir zeigen bessere Wege auf, Software zu entwickeln, indem wir es selbst tun und anderen dabei helfen, es zu tun. Durch unsere Arbeit sind wir zu folgender Erkenntnis gekommen:
1. Menschen und Interaktionen sind wichtiger als Prozesse und Werkzeuge.
2. Funktionierende Software ist wichtiger als umfassende Dokumentation.
3. Zusammenarbeit mit dem Kunden ist wichtiger als die ursprünglich formulierten Leistungsbeschreibungen.
4. Eingehen auf Veränderungen ist wichtiger als Festhalten an einem Plan.
Das heißt: obwohl die Punkte auf der rechten Seite durchaus wichtig sind, halten wir die Punkte links für wichtiger."
Quelle: Wikipedia
"Scrum, but" und andere agile Ansätze
Für mich stellte sich nun die Frage: Wie sinnvoll ist der isolierte Einzug derartiger agiler Elemente in klassischen Projektmanagement-Standards? Ist dabei mehr als die erwähnten "Quick Wins" zu erwarten? Passend zu meinen Überlegungen fand im September in Frankfurt ein Fachtagung "Agiles Projektmanagement 2014" vom PM-Institut statt. Hier wurden in den verschiedenen Fachvorträgen meine Fragen aus unterschiedlichen Perspektiven heraus beantwortet – teils sah ich mich bestärkt in meiner Auffassung, teils wurden mir auch die Grenzen dieser Vorgehensweise deutlich.
Besonders interessant fand ich den Vortrag über die "Agilität 2. Ordnung", in dem Dr. Drechsler (Universität Duisburg-Essen) die Zuhörer ermutigte, das Projektmanagement unter dem Einsatz agiler Methoden fortwährend weiter zu entwickeln. Er berichtete z.B. von PiK-AS: Projektmanagement in Kooperation – Agil und Systemisch (s. Tobias Trepper: Agil-systemisches Softwareprojekt-management). Dabei handelt es sich um eine Erweiterung von Scrum – und zwar erweitert mit den Prinzipien des systemischen Managements. Ein vielversprechender Weg, der hier aufgezeigt wird. Doch abgesehen von der Forschung – wie weit ist die Praxis in der Zwischenzeit?
Gute und schlechte Erfahrungen – kein "Schema F"
Nicht weniger als vier Vorträge handelten von Erfahrungen, zeigten Erfolge und Misserfolge beim Einsatz Agiler Methoden auf. Die Bandbreite der gebotenen Praxisberichte war sehr groß. So lautete etwa die Botschaft einer Referentin: "Scrum mit Erdbeergeschmack" (also angepasst an die eigenen Bedürfnisse) kann sehr gut funktionieren, wenn man es richtig macht!
Gegenpol hierzu war die Aussage eines Referenten mit mehr als zehn Jahren Erfahrung in der Software-Entwicklung mit "Wenn Scrum, dann richtig". Sehr interessant fand ich, dass in der Produktion physischer Produkte bereits erste Erfahrungen mit Sprintplanungen gemacht werden, wobei hier mit den Zuhörern intensiv diskutiert wurde, inwieweit die Ergebnisse der Sprints klar definiert werden können.
Gemeinsam war den Erfahrungsberichten die Aussage, dass die Einführung von Scrum bei zu hohem Tempo oder zu wenig vorhandener Erfahrung die beteiligten Mitarbeiter überfordern oder sogar "überrollen" kann. Ebenso wurde mehrfach betont, dass eine offene und menschenzentrierte Unternehmenskultur eine wichtige Grundlage für die Umstellung auf ein Agiles Projektmanagement bildet – fehlende Reife in Management und Führung scheint dabei ein kaum überwindbares Hindernis darzustellen. Klar wurde anhand der Vorträge, dass es kein "Schema F" für die Einführung Agiler Methoden zu geben scheint, sondern die individuelle Anpassung je nach eigenen Bedürfnissen favorisiert wurde.
Sind Sie "reif" für Agiles Projektmanagement?
Bevor Sie sich nun jedoch hochmotiviert dem Agilen Projektmanagement zuwenden, sollten vorab folgende Fragen zwingend beantwortet werden:
- Ist die Unternehmenskultur "reif" für Agilität?
- Existieren wichtige Grundlagen wie eine offene Gesprächskultur, Vertrauen, Eigenverantwortung der Mitarbeiter?
- Sind bereits Erfahrungen im Projektmanagement vorhanden?
- Wie flexibel können sich die Organisation und Projektmitarbeiter auf veränderte Arbeitsbedingungen einstellen?
Diese Fragen wurden im Rahmen der Vorträge aufgeworfen und zeigten, dass ohne eine gewisse Reife in der Unternehmensführung und -kultur kaum eine Chance für eine wirklich ernst gemeinte Auseinandersetzung mit Agilität im Projektmanagement besteht.
Otmar.Seckinger
03.12.2014
Klaus Schopka
06.01.2015
Henning Zeumer
19.04.2015