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.

Download EPUB

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.

Für jeden Bedarf die passende Mitgliedschaft

 

Das projektmagazin - unverzichtbares Nachschlagewerk und Inspirationsquelle für alle,
die in Projekten arbeiten. Ihre Vorteile auf einen Blick

Image
Wissensplattform

Zugriff auf die größte deutschsprachige Wissensplattform
für Projektmanagement  (>1.800 Artikeln und Tipps)

Image
Praxisbezogene Beiträge

Praxisbezogene Beiträge
Fachautoren schreiben aus der Praxis für die Praxis.

Image
Tools

Werkzeuge (Tools)
z.B. Checklisten und Vorlagen, Methoden mit Schritt-für-Schritt-Anleitung.

Image
Glossar

Umfangreiches Projektmanagement-Glossar
über 1.000 Fachbegriffen (deutsch/englisch)

Image
Blogbeiträge

Blogbeiträge, Themenspecials, Bücher, Stellenangebote etc.
rund um das Thema Projektmanagement

Alle Kommentare (3)

Hallo Frau Niklas, danke für den Hinweis auf den Artikel! Ich glaube wir sind da auf der selben Wellenlänge. Ich verweise insb. auf den "Agile Adoption And Transformation Survival Guide" von Sahota, der das Thema auch gut beschreibt! Die große Gefahr für die agile Bewegung sehe ich in klassischen Managern, die "Agile" nur als eine weitere Methode erachten ohne die zugrundeliegende Werte und die damit verbundene Kulturänderung zu beachten. Das angesprochene Scrum-But ist oftmals ein "Not-Scrum". Kann ja unter Umständen auch ein sinnvoller Ansatz sein, aber man sollte nicht glauben, dass man damit die Vorteile von Scrum mitnehmen kann! viele Grüße Otmar Seckinger

 

Guest

Hallo Frau Niklas, „Scrum but“ – mag aus Sicht des zitierten Manifests inkonsequent wirken. Auf der anderen Seite darf man nicht übersehen, dass Projekte nicht auf der grünen Wiese gemacht werden. In aller Regel gibt es Stakeholder und gewachsene IT-Umgebungen mit jeweils sehr konkreten Interessen und Anforderungen. Klar bedeutet die Verwässerung von Prinzipien des Manifests den Verzicht auf kurzfristige Vorteile. Aber ebenso müssen Vor- und Nachteile auf der klassischen Seite der Unternehmen betrachtet werden. Forderungen nach Dokumentation usw. haben schließlich sehr konkrete Hintergründe – speziell in mittelfristigen Betrachtungen. Die weitere Verbreitung agiler Methoden wird dies nicht aufhalten. Zwei Studien hierzu wurden auf der Tagung der Fachgruppen Projektmanagement und Vorgehensmodelle der Gesellschaft für Informatik im Oktober vorgestellt. Der Vergleich zwischen 2006 und 2013 zeigt eine deutliche Zunahme der agilen Methoden. Ein weiteres Ergebnis aus Vorträgen und Diskussionen während der Tagung war die pragmatische Handhabung von hybriden Methoden. Wichtig ist letztlich der nachhaltige Projekterfolg. Die jeweils geeignetste Methode kann klassisch, agil oder hybrid sein. Link zu einer Infoseite der Tagung: http://openpm.info/pages/viewpage.action?pageId=32800907 Viele Grüße Klaus Schopka

 

Guest

Nun ist das Verbinden von agilen und klassischen Elementen im Projektmanagement ja nichts Ungewöhnliches. Wir haben es früher - vor dem Manifest - halt Iteratives PM genannt, und es hat dem Projektmanager mehr als nur einmal Planen und dann stures Abarbeiten abverlangt. Aber das darf man von einem guten Projektmanager ja auch erwarten, ohne dass er dabei über alle Termine und Budgets hinausschießt. Leider ist es genau das, was viele unter "agil" verstehen, wie auch z.B. ein PM lehrender Fachhochschul-Professor mir neulich mal erzählen wollte, man gebe mit agilem Vorgehen dem Projektplan "Luft zum Atmen". Nach meiner Erfahrung ist agiles Vorgehen viel disziplinierter als manche Anwendung klassischer Methoden und führt, wenn man's richtig miteinander verbindet, meist zu gleichen Projektlaufzeiten und oft zu geringeren Kosten bei besserer Produktqualität. Das mag auch daran liegen, wie der Projektmanager das Manifest umsetzt und in seine klassische Planung und Umsetzung einbaut: 1. Menschen und Interaktion vor Prozessen und Werkzeugen: nichts ist wichtiger in jedem Projekt als Kommunikation und gut getaktete Abstimmung, und Prozesse und Werkzeuge sind immer nur Hilfsmittel, um die Komplexität zu beherrschen. 2. funktionierende Software vor Dokumentation ist Produktqualität pur und wird umso besser, je öfter man das Produkt zwischendurch bewerten kann - aber es heißt ja nicht, dass man auf Dokumentation verzichen soll. 3. mit Kunden entwickeln vor festem Lastenheft ist doch sowieso normaler Projektalltag, denn welcher Scope bleibt denn im Projektverlauf tatsächlich fix - da kann man das flexible Eingehen auf bessere Erkenntnisse doch gleich als willkommen antizipieren - natürlich mit einem Change Control Prozess, der das Verselbständigen des Scopes wirksam einfängt. 4. und dann wird auch das Eingehen auf Kundenwünsche nicht zu einer ungewollten "Abweichung" vom Plan, sondern zur abgestimmten Ergänzung, die von beiden Seiten gewollt ist. Also was hindert uns, klassische und agile Vorgehensweisen im Projekt sinnvoll miteinander zu verbinden. Eigentlich nur Dogmatismus - oder Projektmanager, die zwar davon reden, aber es nicht können...