Viele agile Transformationen versprechen nur eines:
mehr Prozess.
Ich sehe diese Entwicklung kritisch. Agile Transformationen haben wenig mit Prozessen zu tun, sondern vielmehr mit dem Management von Risiken, dem Fokus auf den Wert für den Nutzer und dem Verhalten von Menschen. Scrum Master sind deshalb auch nicht die Wächter des Prozesses. Das ist eine Aufgabe für die Scrum-Polizei.
Aber ich will ehrlich mit dir sein:
Dies war mir zu Beginn meiner Karriere als Scrum Master auch nicht bewusst. Ich dachte, Scrum sei ein Entwicklungsprozess. Über die Jahre wurde ich eines Besseren belehrt. Und irgendwann habe ich verstanden, welches Versprechen „Agilität“ eigentlich macht. Und davon möchte ich dir heute etwas mehr berichten. Bereit?
Dann lass uns mit dem ersten Versprechen beginnen:
Versprechen #1: Regelmäßig neue Software in weniger als zwei Wochen liefern
Meine ersten Positionen als Scrum Master waren bei einer großen Behörde und bei einem Konzern in der Energiebranche.
In beiden Situationen war ich mit dem gleichen Problem konfrontiert: Scrum, so wie es im Scrum Guide beschrieben war, funktionierte nicht. Die Teams waren nicht in der Lage, bis zum Ende des Sprints eine neue Version des Produkts herzustellen, die zum Kunden ausgeliefert werden konnte.
Und was ich dir jetzt sage, mag hart klingen:
Die Aufgabe eines Scrum Masters ist es, dieses Problem zu lösen. Du glaubst mir nicht? Dann lies bitte noch mal im Scrum Guide. Im ersten Satz wird der Scrum Master so beschrieben:
„Der Scrum Master ist ergebnisverantwortlich für die Einführung von Scrum, wie es im Scrum Guide definiert ist.“
Für mich war dies zu Beginn meiner Karriere auch eine harte Erkenntnis. Im Vorstellungsgespräch für eine der Positionen wurde mir das genau so gesagt:
„Simon, wenn du hier als Scrum Master arbeiten willst, dann bist du dafür verantwortlich, dass wir Software ausliefern.“
Die gute Nachricht: Jetzt wusste ich wenigstens, was von einem Scrum Master erwartet wird. Die schlechte Nachricht: Dass Scrum nicht funktioniert, kann viele Gründe haben, und ich hatte keine Ahnung, welche es sein könnten ...
Deshalb gilt es, diese zu entdecken:
Mir haben hierfür immer drei Werkzeuge gute Dienste geleistet:
- Definition of Done: Anhand der Definition of Done lässt sich der Entwicklungsprozess des Teams gut aufzeigen.
- Fähigkeiten-Matrix: Die Fähigkeiten im Team transparent zu machen hilft zu erkennen, welche Fähigkeiten noch fehlen, um eine fertige Version des Produkts zu entwickeln.
- Umfragen zur „Technischen Exzellenz“: Die Selbsteinschätzung über die Qualität der Entwicklung hilft, Potenziale zur Verbesserung sichtbar zu machen.
Hier ein Beispiel für eine Fähigkeiten-Matrix:
Und noch eine Bemerkung zur „Technischen Exzellenz“:
Scrum Master haben häufig nicht genug technisches Wissen, um Entwickler wirklich beratend zu unterstützen. Mir geht es ähnlich. Gleichwohl ist es unsere Aufgabe, auch Verbesserungen im Entwicklungsprozess zu unterstützen. Wie kann das klappen? Ich nutze hierfür Umfragen. Anhand einiger gängiger Kriterien für gute Software lasse ich das Team bewerten, wie qualitativ hochwertig bisher entwickelt wurde. In der Retrospektive nutze ich dann diese Selbsteinschätzung, um anhand dieser Verbesserungen anzustoßen.
Diese drei Werkzeuge haben mir bisher immer geholfen, Übergaben zu verringern, Fähigkeiten im Team aufzubauen, Abhängigkeiten aufzulösen und Prozessschritte zu automatisieren.
Im „Professional Scrum Master – Advanced“-Training erklären deshalb Marc und ich einige dieser Vorgehensweisen im Detail und geben dir auch noch andere Werkzeuge an die Hand, um deinem Team zu helfen, Software am Ende des Sprints auch zu liefern.
Ist dein Scrum Team in der Lage, alle zwei Wochen eine neue Version des Produkts zu liefern?
Falls nicht, dann gilt es, dieses Problem zu beheben. Das ist erstmal die wichtigste Aufgabe eines Scrum Masters. Aus meiner Erfahrung erhoffen sich das die meisten Unternehmen von einer agilen Transformation. Denn regelmäßig zu liefern bedeutet, dass die meisten Fehler und Probleme auf dem Weg dorthin eliminiert wurden. Zusagen zu Kunden sind damit verlässlicher. Das Risiko, Verträge nicht einzuhalten, reduziert sich.
Dieses Bild aus dem Zombie Scrum Survival Guide von Christiaan Verwijs und Barry Overeem veranschaulicht diesen Zusammenhang noch mal:
Versprechen #2: Den Wert für die Nutzer des Produkts maximieren
Zuverlässig zu liefern, sollte das erste Versprechen jeder agilen Transformation sein.
Gibt es noch weitere?
Vor einigen Jahren habe ich für ein Unternehmen aus der Versicherungsbranche gearbeitet. Im Scrum Team, in dem ich Teil war, war Liefern kein Problem. Es ging zu jeder Zeit. Quasi auf Knopfdruck, da der Prozess von Integrieren, Testen und Ausliefern vollständig automatisiert war. Eigentlich ein Traumjob für jeden Scrum Master. Meine Aufgabe ist doch schon erfüllt; ich kann mich entspannt zurücklehnen.
Diese Illusion wurde mir schnell genommen.
Als ich das erste Sprint-Review betrat, stellte ich verdutzt fest, dass fast keine Stakeholder aus dem Unternehmen anwesend waren, und von Kunden war weit und breit keine Spur. Als ich nachfragte, wer denn die Kunden und Nutzer dieser Softwarelösung seien, erhielt ich die Antwort: Wir arbeiten an einer Technologie-Plattform. Wir haben noch keine Kunden.
An diesem Tag realisierte ich, dass hier ein ganz anderes Problem auf mich als Scrum Master wartete. Es ging darum, Wert mit der Software zu schaffen. Darin besteht das zweite Versprechen einer agilen Transformation. Was meine ich damit?
Am liebsten erkläre ich den Unterschied zwischen Software und Wert am Logik-Modell:
Das Logik-Modell zeigt einen Entwicklungsprozess.
Aus Inputs wird mittels Aktivitäten neuer Output produziert. Für den Erfolg eines Produkts ist Output aber nicht genug. Die Nutzer müssen es auch nutzen wollen. Es muss ein Problem für sie lösen. Das ist mit Outcomes gemeint. Nur Ergebnisse erzeugen Wert für die Nutzer. Und diesen erzeugten Wert beim Kunden müssen wir dann wieder fürs Unternehmen einfangen. Etwa indem die Nutzer dafür bezahlen. Dies bedeutet dann einen Impact fürs Unternehmen.
Zurück zu meinem Beispiel. Software zu liefern, bildet die Voraussetzung für Wert. Was wertvoll ist oder nicht, entscheidet allein der Nutzer. Und damit das Scrum Team davon Wind bekommt, muss es erst etwas ausliefern und dann messen, ob es für den Nutzer wertstiftend ist. Etwa durch Messen der Dauer oder Häufigkeit der Nutzung oder direktes Feedback im Sprint-Review. Lass es mich nochmal zusammenfassen:
Wert kann nur entstehen, wenn Software geliefert wird.
Was bedeutet das für den Product-Owner? Die Antwort finden wir im Scrum Guide:
„Der Product-Owner ist ergebnisverantwortlich für die Maximierung des Wertes des Produkts, der sich aus der Arbeit des Scrum Teams ergibt.“
Der Product-Owner kann nur den Wert maximieren, wenn das Scrum Team regelmäßig ausliefert und er damit überprüfen kann, ob tatsächlich Wert geliefert wird. Basierend auf dieser Rückmeldung trifft er die Entscheidung, was das nächste Wichtigste sein wird. Und dass nicht nur zeitnah geliefert wird, sondern auch wirklich Wert damit entsteht, das stellt für mich das zweite Versprechen einer agilen Transformation dar.
Diese Versprechen verkörpern für mich den Unterschied zwischen Projekt und Produkt:
Und eine agile Transformation bedeutet eine Abkehr von Projekten hin zu Produkten. Unsere Aufgabe als Scrum Master ist es, den Product-Owner zu unterstützen. Indem wir ihm helfen zu lernen, wie Wert entdeckt und validiert wird.
Ich hatte damals Glück: Zuvor hatte ich bereits als Product-Owner gearbeitet und viel Unterstützung von meinen Scrum Mastern und anderen Product-Ownern erhalten, um herauszufinden, worauf es beim Produkt-Management ankommt.
Hattest du weniger Glück und hast selbst noch nicht als Product-Owner gearbeitet?
Dann empfehle ich dir den Besuch des „Professional Product Owner – Advanced“-Trainings. Dort geben dir Peter und ich eine Reihe von Werkzeugen mit, die dir helfen werden, die Transformation von Projekt zu Produkt voranzutreiben. Kleiner Vorgeschmack? Dann findest du in diesem Artikel „Warum die Entdeckung und Validierung von Features im Refinement unverzichtbar ist – und wie du in 4 Schritten wertvolle Features identifizierst“ eine Liste konkreter Methoden, die dir helfen, das Refinement zu verbessern.
Lieferfähigkeit war das erste Versprechen. Die Abkehr vom Projektmanagement hin zum Produktmanagement das zweite. Was uns zum letzten Versprechen von agilen Transformationen bringt:
Versprechen #3: Veränderung als Chance sehen und sie nutzen
Agilität ist mittlerweile ein Synonym für alles Mögliche:
Schneller lernen. New Work. Innovation, Anpassungsfähigkeit, usw.
Aber wozu machen wir das Ganze eigentlich? Ich glaube, im Kern geht es darum, Veränderung als Chance zu sehen und sie zu nutzen. Nicht mehr und nicht weniger. Das macht erfolgreiche Unternehmen doch im Kern aus. Und wenn ich ehrlich bin, habe ich das in meiner Karriere als Scrum Master noch nicht so häufig selbst miterlebt. Und wenn ich es erlebt habe, wurde es mir erst Jahre später bewusst, dass das jetzt „agil“ war.
Hier ein Beispiel aus meiner Anfangszeit als Scrum Trainer bei Scrum.org.
Ich bin seit Ende 2019 Scrum Trainer bei Scrum.org.
Mein erstes öffentliches Training plante ich in München. Obwohl ich voll ausgebucht war, musste ich in einer Nacht-und-Nebel-Aktion das Training Anfang März absagen und alle Teilnahmegebühren wieder zurückzahlen. Ich muss dir nicht sagen, was im März 2020 passiert ist.
Für mich bedeutete es erstmal das Ende meiner Selbstständigkeit.
Die Zeit danach war schwierig.
Wegen des Lockdowns konnte ich keine Schulungen mehr anbieten. Gleichzeitig schrieben die Regeln von Scrum.org vor, dass Schulungen ausschließlich in Präsenz stattfinden dürfen. Diese Regel sollte sicherstellen, dass den Teilnehmern eine gute Erfahrung zuteilwird und sie persönlichen Kontakt zu einem Scrum Trainer erhalten. Diese Situation stellte nicht nur mich vor ein Problem, sondern auch Scrum.org, da die Gebühren aus Trainings ausblieben.
Für Scrum.org stellten sich nun zwei Möglichkeiten: entweder abwarten, bis die Lockdowns aufgehoben werden, und weiterhin am Geschäftsmodell von Trainings in Präsenz festhalten. Oder: Die Veränderung als Chance erkennen und irgendwie versuchen, sie zu nutzen.
Scrum.org entschied sich für Letzteres.
Sie hob die Regel auf und suchte nach Möglichkeiten, Trainings auch online stattfinden zu lassen, welche die gleiche Erfahrung für die Teilnehmer boten wie eine Schulung in Präsenz. Ich will nicht lügen, aber die Umstellung war für mich als Trainer nicht leicht. Und ich musste viel lernen und ausprobieren, um Onlineschulungen genauso interaktiv zu gestalten wie Präsenzschulungen. Aber ich denke, der regelrechte Scrum Boom in den Jahren 2021 und 2022 zeigt, dass das geklappt hat.
Scrum.org konnte damals die Chance, die sich bot, erkennen und nutzen.
Was war für diese Agilität nötig?
Ich denke, es kam auf zwei Dinge an: Scrum.org ist sehr von der Mission getrieben „Menschen und Teams zu helfen, komplexe Probleme zu lösen“. Wie diese Mission erreicht wird, bleibt flexibel. Selbst starre Regeln, die der Qualitätssicherung dienen, werden hinterfragt und geändert, wenn es der Mission hilft. Erst kommt die Mission, dann die Produkte und dann der Prozess. Beherzter Veränderungswillen. Die Entscheidung, das Geschäftsmodell anzupassen, wurde von jemandem getroffen, der das Mandat hatte, Dinge auch zu verändern.
Was können wir daraus für die Arbeit von Scrum Mastern lernen?
Ich denke, Scrum Master, die ihrem Unternehmen helfen wollen, Veränderung als Chance zu sehen und sie zu nutzen – also wirkliche Agilität zu ermöglichen –, sollten langfristig den Karrierepfad einer disziplinarischen Führungskraft einschlagen. Ich will damit nicht sagen, dass externe Agile Coaches nicht auch Veränderung ermöglichen können. Aber in schwierigen Situationen – wie Pandemien – muss schnell und beherzt entschieden werden.
Und dafür sind doch am Ende im Unternehmen Führungskräfte zuständig – und nicht Coaches.
Willst du als Scrum Master langfristig Karriere machen? Und mehr darüber erfahren, was Scrum Master von Führungskräften unterscheidet? Dann lies hier weiter: „Vom Scrum Master zur Führungskraft: Diese Fähigkeit ist unerlässlich“