Von klassisch zu agil

Wie starte ich mit Scrum?

Teams, die von klassischer Projektarbeit auf Scrum umstellen, müssen nicht nur Rollen, Artefakte und Meetings einführen. Der Wechsel vom klassischen zum agilen Projektmanagement geht auch mit großen Veränderungen in der Zusammenarbeit einher. Wie Sie den Wechsel trotzdem erfolgreich meistern, erklärt Stefan Willuda. Er schlägt einen Fahrplan vor, mit dem der Umstieg in einfachen Schritten gelingt.
Von klassisch zu agil

Wie starte ich mit Scrum?

Teams, die von klassischer Projektarbeit auf Scrum umstellen, müssen nicht nur Rollen, Artefakte und Meetings einführen. Der Wechsel vom klassischen zum agilen Projektmanagement geht auch mit großen Veränderungen in der Zusammenarbeit einher. Wie Sie den Wechsel trotzdem erfolgreich meistern, erklärt Stefan Willuda. Er schlägt einen Fahrplan vor, mit dem der Umstieg in einfachen Schritten gelingt.

Immer wieder werde ich gefragt, wie Teams, die aktuell "klassisch" in Projekten zusammenarbeiten, den Übergang auf Scrum angehen können. Agile Zusammenarbeit mit Scrum funktioniert anders als klassische und der Umstieg auf diese andere Form der Zusammenarbeit gelingt in der Hektik des Projektalltags nicht immer reibungslos. Haben Abteilungs- oder Projektleiter die Entscheidung getroffen, zukünftig nach den Prinzipien von Scrum zu arbeiten, versuchen sie in der Hoffnung auf schnelle Erfolge nicht selten, Scrum mit all seinen Facetten in einer großen Initiative "auszurollen". Auch wenn dieser Ansatz erfolgreich sein kann, so erlebe ich in der Praxis auch das Gegenteil. In diesem Beitrag möchte ich Ihnen einen alternativen Weg aufzeigen. Sie erhalten hier einen Fahrplan, mit dem Ihnen der Umstieg auf Scrum in kleinen Schritten gelingen kann. Der beschriebene Fahrplan hilft Ihnen am besten, falls Sie ein laufendes Projekt in einfachen Schritten agilisieren wollen. Es kann aber auch nützlich sein, wenn Sie in einem neuen Projekt agile Zusammenarbeit in Etappen organisieren möchten. Das hier beschriebene Vorgehen kann in beiden Fällen eingesetzt werden. Lediglich die Dauer bis zur Abarbeitung aller Punkte auf der untenstehenden Checkliste kann in einem bestehenden Projekt länger sein.

1. Wollen Sie das wirklich?

Bevor Sie mit Scrum beginnen, geben Sie sich zunächst selbst eine Antwort auf die Frage, was Sie dazu bewogen hat, mit Scrum arbeiten zu wollen. Oder anders gefragt: Welches Problem möchten Sie mit Scrum lösen, das Sie bisher nicht lösen konnten?

Bild 1: Stacey-Matrix – Dimensionen der Sicherheit und der Übereinstimmung.


Scrum und andere agile Rahmenwerke sind für Projektsituationen sinnvoll, deren Umfeld ein hohes Maß an Unsicherheit birgt. In solchen Kontexten sind langfristige Pläne wenig zuverlässig. Sehen wir uns Bild 1 an: Geringe Zuverlässigkeit kann sich zum Beispiel ergeben, wenn sowohl die Anforderungen als auch die eingesetzten Technologien unsicher sind (komplexes Projektumfeld). Projekte hingegen, bei denen die Anforderungen und die technologischen Rahmenbedingungen vollständig bekannt sind, lassen sich in der Regel mit hoher Zuverlässigkeit langfristig planen (simples oder kompliziertes Projektumfeld). Solche Projekte können "klassisch" erfolgreich abgewickelt werden.

Gehen Sie die Schritte in diesem Artikel bitte nur dann, wenn Sie davon überzeugt sind, dass Sie Scrum einsetzen wollen und wenn Sie für sich beantworten konnten, welches Problem Sie mit Scrum lösen wollen. Diese Klarheit ist ein wichtiger Faktor für den Erfolg Ihrer Scrum-Einführung. Seien Sie sich darüber im Klaren, dass die Einführung von Scrum mit Veränderungen in Ihrem Team und Ihrer Zusammenarbeit einhergehen werden. Diese Veränderungen können Widerstände aufkommen lassen. Ihr klares "Warum" für die Scrum-Einführung wird Ihnen helfen, den Kurs zu halten und positiv mit den Veränderungen umzugehen.

2. An erster Stelle: der Anwender

Die nächste Frage auf dem Weg zur Scrum Einführung lautet: Wer ist der tatsächliche Anwender Ihres Produkts oder Ihrer Lieferung? Diese Frage wirkt zunächst trivial, stellt in der Praxis aber viele Teams vor eine große Herausforderung. In Scrum wird die Anwenderperspektive in alle Produktentscheidungen einbezogen. Üblicherweise werden dafür ein oder mehrere prototypische Anwender identifiziert, analysiert und beschrieben. Diese Beschreibung – ähnlich einem Steckbrief eines realen Menschen (siehe Bild 2) – wird in Scrum als Persona bezeichnet.

Beschreiben Sie Ihre Persona: Stellen Sie sich vor, in welcher Situation dieser Anwender Ihr Produkt verwendet. Welche Features und Funktionalitäten machen ihn bei der Nutzung des Produkts zufrieden, was könnte ihn frustrieren? Auch wenn ich an dieser Stelle explizit von der Nutzung eines Produkts schreibe, funktioniert diese Betrachtungsweise in der Praxis problemlos auch für einzelne Funktionen, Produktteile, Dienstleistungen und sogar ganze Change-Initiativen.

Bild 2: Musterinhalte für die Beschreibung der Persona.

3. Die Möglichkeit zur kontinuierlichen Verbesserung schaffen

Das Rahmenwerk Scrum sieht kurze Feedback-Zyklen und die kontinuierliche Verbesserung vor. Diese kontinuierliche Verbesserung betrachtet dabei sowohl den Prozess der Produkt- und Lösungsentwicklung als auch die Zusammenarbeit innerhalb des Teams. Ziel dieser fest und wiederkehrend eingeplanten Momente der Rückschau ist es, die Effektivität des Teams zu steigern. In Scrum findet das Bemühen um die kontinuierliche Verbesserung in der Retrospektive seinen Platz.


Führen Sie also mit Ihren Kollegen regelmäßig Retrospektiven durch und stellen Sie die aktuelle Arbeitssituation immer wieder auf den Prüfstand. Diese "Nabelschau" ist für einige Teams zu Beginn ungewohnt und es braucht oft etwas Übung, bis diese Verbesserungsmeetings effektiv gestaltet werden. Doch der Effekt ist den Aufwand wert. Wahrscheinlich wird es Ihnen nach einer Retrospektive leichter fallen, den nächsten Schritt der Scrum Einführung festzulegen. Fingerpointing und stumpfes Suchen nach Fehlern hat in der Retrospektive keinen Platz. Retrospektiven sollten lösungs- und aktionsorientiert gestaltet werden: Was machen wir als Team morgen besser als heute?

Ein kleiner Tipp aus der Praxis: Suchen und geben Sie oft Feedback. "Kein Meeting ohne Kurz-Retrospektive" ist eine gute Daumenregel, um schnell viel Übung zu erlangen. Wichtig ist, dass abgeleitete Maßnahmen zur Verbesserung auch wirklich umgesetzt werden, weil sich Feedback-Zyklen abnutzen, wenn aus ihnen keine Veränderung erwächst. Priorisieren Sie daher die Optimierungsmaßnahmen und fokussieren Sie sich auf die höchsten ein bis drei Prioritäten. In Scrum arbeitet der…

Bewertungen und Kommentare

(nur angemeldete Benutzer)

Diese Funktion steht nur eingeloggten Nutzern zur Verfügung. Jetzt einloggen
Gesamt
Bewertungen 4
Kommentare 5

Alle Kommentare

Ayelt
Komus
Prof. Dr.
Vielen Dank für den interessanten Überblick. Wir haben inzwischen viele Unternehmen interviewt und begleitet bei der Einführung agiler Methoden. Dabei erheben wir strukturiert die Herausforderungen auf dem Weg zur erfolgreichen Nutzung agiler Methoden. Wenn es darum geht, agile Methoden in bisher klassisch arbeitenden Organisationen einzuführen, so stehen eigentlich immer zwei Bereich als besondere Herausforderung im Vordergrund: 1. Die Sicherung eines "geschützten Raumes" für das Team, damit es auch nach den definierten "Spielregeln" arbeiten kann. Dies ist meist durchaus möglich - darf aber nicht unterschätzt werden. 2. Die Unterstützung ("Enabling") des Product Owners. Während das Team sich meist recht gut und schnell in das neue Verfahren einfindet, muss die neue Denkweise des Arbeitens mit Inkremten und Product Backlog erst einmal verstanden und eingeübt werden. Es zeigt sich, dass dabei ein gewisses inhaltliches Verständnis durch einen Coach ein nicht zu unterschätzender Vorteil ist. Wenn diese zwei Bereiche gut funktionieren, können Teams nach unserer Erfahrung meist schnell und sicher sehr gute Leistungen erbringen und bisherige Grenzen überwinden.
Daniela
Zbinden
Grundsätzlich finde ich es ein guter Überblick. Allerdings fehlt eine konkrete Empfehlung wie es nun eingeführt werden soll. Methoden über alle Projekte oder gesamthaft Scrum über einzelne Projekte? Einzelne Projekte mit Abhängigkeiten zu Umsystemen, die in ihren üblichen Releasezyklen arbeiten, sind unmöglich agil zu führen. Nicht alles auf einmal, kann ich nachvollziehen. Aber wieviel auf's einmal? In grösseren Unternehmen mit vielen Schnittstellen zwischen den Applikationen müssten mindestens bestimmte Domänen agil arbeiten (auch wenn diese wiederum Schnittstellen haben werden zu solchen, die noch nicht agil unterwegs sind). Für diese Problematik sehe ich nachwievor keine richtige Einführungslösung. Zudem frage ich mich, ob nicht zuerst die technischen Voraussetzungen geschaffen werden müssen. Continuous Integration und automated Testing. Sind es effektiv Voraussetzungen oder kann es erst im Rahmen des Einsatz von Scrum geschaffen werden? 90% sind Weiterentwicklungen. D.h. bestehende Anwendungen zuerst in ebendiesen zwei Disziplinen müssten fit gemacht werden. Oder sehe ich das falsch?
Lieber Agile-begeisterter Newbie, ich danke Ihnen für das Feedback und die sich anschließenden Fragen. Grundsätzlich verbindet sich mit Agilität im Allgemeinen und mit Scrum im Speziellen ein Mindset, das agiles Arbeiten jenseits von Methoden oder starren Prozessen ermöglicht. Das ist der Ursprung agilen Arbeitens. Wir haben es in den heutigen Scrum Einführungen jedoch in den seltensten Fällen noch mit Organisationen zu tun, die aus Scrum Enthusiasten bestehen. Die echte Enthusiasten agilen Arbeitens sind schon lange agil. Die, die jetzt umstellen, stellen in der Regel aus einem Wettbewerbs- oder Kundendruck um. In diesen Organisationen gelingt kein großer Change, der an der Spitze der Organisation durch erleuchtete Top-Führungskräfte initiiert wird. Der Change, der hier stattfindet, ist kleinteiliger und deutlich iterativer. Das bedeutet konkret zu Ihrer Frage, dass es oft ein sinnvoller Ansatzpunkt ist, wenn einzelne Teams sich innerhalb des Rahmenwerkes entlang eben doch die einzelnen Methoden Schritt für Schritt aneignen. Dann erlernen diese einzelnen Teams agiles Arbeiten und beginnen die dahinter liegenden Werte zu verinnerlichen. Getreu dem Motto: "First you pretend Agile, then you do Agile. At some stage you may be agile. If you're lucky, eventually the word becomes irrelevant." Also, beginnen Sie mit den Methoden in einem Team, in einem Projekt. Sie finden in einem Unternehmen, das klassisch geführt wird, kein Projekt, dass nicht mit anderen Projekten verwoben ist. Teams teilen sich immer Ressourcen. Es ist damit ein hoffnungsloses Unterfangen mit Ihrer Scrum Einführung zu warten, bis Sie das Projekt gefunden haben, dass Sie ohne Reibung zu anderen Projekten agilisieren können. Versuchen Sie stattdessen lieber behutsam die Reibungen an Nahtstellen, die bei der Einführung von Scrum entstehen, transparent und lösbar zu machen. Dann können Sie das Umsystem immer weiter in die Scrum Einführung aufnehmen. Verstehen Sie diesen Ansatz nicht als Roll-Out sondern mehr als einen Roll-In. Es ist vollkommen eindeutig, dass Sie bei der Einführung von Scrum über die Grenzen eines Teams hinaus, ein Management benötigen, dass die Vorteile von Agilität erkennt und diese Veränderungsarbeit über die Grenzen ihres eigenen "Wirkungsbereiches" hinaus leistet (z.B. als Management Team). Sie können auch in einem Scrum Team auf einen "klassischen" Releasezyklus liefern. Das habe ich schon oft erlebt. Dazu definieren Sie Integrationszeiträume, in denen die Zusammenführung der Lieferungen erfolgt. Das muss Sie nicht daran hindern auch davor schon Feedback einzuholen. Bei der Einführung von Scrum im moderneren Verständnis gibt es die Regel, dass Sie sich nichts wünschen dürfen, dass unrealistisch ist ("no wishful thinking"). Sie können nicht darauf warten, dass eine ganze Domäne oder ein Bereich mit einem Schlag anfängt agil zu arbeiten. Das wird nicht passieren. Es sind die vielen Einzelbewegungen, die im Laufe der Zeit zu einer großen agilen Transformation zusammenlaufen. Glauben Sie mir, agile Transformationen gelingen auch "von unten". Das Umfeld, in dem Sie Scrum einführen, bestimmt das Tempo, mit dem Sie voran gehen können. Wenn Sie noch Zeit haben, weil der Markt oder der Kunde Sie nicht drängt, so geht es langsamer als wenn Sie einen erheblichen "Sense of Urgency" spüren. Es gibt daher keine pauschale Antwort "wie viel" agiles Arbeiten auf einmal möglich ist. Bei den technischen Voraussetzungen gilt aus meiner Sicht die gleiche Antwort, wie bei den organisatorischen Voraussetzungen. Erarbeiten Sie die technische Infrastruktur im Rahmen eines agilen Vorgehens. Sie können nicht darauf warten, dass irgendwann die technische Infrastruktur für agiles Arbeiten perfekt ist. Schon gar nicht können Sie die Infrastruktur für agiles Arbeiten im klassischen Projektvorgehen realisieren. Sie müssen irgendwo beginnen. Und dieses "Irgendwo" ist meiner Erfahrung nach oft das Impediment, das Sie als nächstes an der kontinuierlichen Lieferung hindert. Sie haben absolut recht. Die bestehenden Infrastrukturen müssen, wie die Organisationen auch, für die Agilität fit gemacht werden. Damit werden Sie jedoch nicht so schnell fertig. Also nutzen Sie konsequent das Rahmenwerk von Scrum, um diese Bedingungen zu schaffen, die Sie für die Arbeit mit Scrum brauchen.
Daniela
Zbinden
Vielen Dank für die ausführliche Antwort. Das mit Warten nichts passiert ist auch mir klar ;-) Aber ich habe Ihre Grundidee verstanden. Der letzte Satz ist eigentlich fast der Entscheidendste: "Also nutzen Sie konsequent das Rahmenwerk von Scrum, um diese Bedingungen zu schaffen, die Sie für die Arbeit mit Scrum brauchen."
Helene
Valadon
Hilfe zum Start!
Alle anzeigen