Risikomanagement in Scrum – Warum jedes Unternehmen einen Scrum Master braucht

„Niemand hat dich gebeten, zu kommen!“

Jeder erfahrene Scrum Master wurde wohl schon einmal mit einer solchen Aussage konfrontiert.

Betrachten wir ein beliebiges Produkt. Dann sehen wir: Entwickler entwickeln das Produkt. Designer stellen sicher, dass es eine gute Nutzererfahrung bietet und toll aussieht. Der Product Owner vertritt die Probleme und Wünsche der Kunden. Marketer kümmern sich darum, dass die Menschen vom Produkt erfahren. Der Vertrieb hilft potenziellen Kunden, ihre Kreditkarte zu zücken und das Produkt zu kaufen. Und der Kundensupport sorgt dafür, dass bei Kunden über die Jahre kein Frust entsteht.

Was sonst braucht man in der Produktentwicklung?

Wie passt ein Scrum Master hier ins Bild?

Diese einfache Frage verstört. Sie zeigt aber auch die Möglichkeiten auf, die sich Scrum Mastern bieten können.

Wenn du gerade mit dem Gedanken spielst, Scrum Master zu werden, dann schreckt dich diese Frage vielleicht jetzt ab. Und wenn du bereits seit vielen Jahren als Scrum Master arbeitest, spürst du den Drang, dich zu rechtfertigen. Das solltest du aber nicht!

Sicher, ohne einen Scrum Master wird jede Produktorganisation weiterhin recht gut funktionieren – bis zu einem gewissen Grad.

Ich bin davon überzeugt, dass mit einem Scrum Master jede Produktorganisation noch erfolgreicher wird. Denn ich bin sicher, dass der Wert eines Scrum Masters darin liegt, dass er dem Unternehmen hilft, das Risiko zu minimieren. Wenn ich von Risiko spreche, dann meine ich das finanzielle Risiko, welches Unternehmen mit der Entwicklung von neuen Produkten auf sich nehmen.

Gunther Verheyen gehört zu den ersten und besten Professional Scrum Trainern weltweit. Als ich ihn einmal fragte, was die Aufgabe des Scrum Masters sei, beantwortete er diese in einem Satz: „Ein Scrum Master ist ein moderner Risikomanager.“

Ich gehe sogar noch einen Schritt weiter:

Ein Scrum Master ist der Risikomanager.

Zum einen ist Scrum nicht mehr modern, sondern die Norm. Zum anderen sind häufige Feedbackschleifen (Sprints) und kleine Investitionen („done“-Inkremente) der einzige Weg, das Risiko bei komplexer Arbeit zu reduzieren. Komplexe Arbeit, wie Produktentwicklung, zeichnet sich ja gerade dadurch aus, dass wir die Parameter, die über Erfolg oder Misserfolg bestimmen, nicht kontrollieren können. Somit können sie auch niemals gemanagt werden. Deshalb bringen detaillierte Risikoanalysen, Risikomatrizen oder Risikoregister keinerlei Mehrwert bei komplexen Arbeiten. Im Gegenteil, die Erstellung stellt nur Kosten dar und wiegt die Betrachter in einer falschen Sicherheit. Aus meiner Sicht sollten sie begraben werden, sie stellen Relikte aus einer längst vergangenen Ära dar.

Wenn du wieder einmal mit einer Aussage wie „Niemand hat dich gebeten, zu kommen!“ konfrontiert wirst, dann hoffe ich, dass deine Antwort lautet: „Ich bin der Risikomanager bei dieser Produktentwicklung. Damit trage ich maßgeblich zum Unternehmenserfolg bei, indem ich dafür sorge, dass wir nicht Zeit und Geld durch zu viele ungeprüfte Annahmen verschwenden.“

Wie kannst du dafür Sorge tragen?

Ich verrate dir das bestgehütetste Geheimnis erfolgreicher Scrum Master. Es lautet:

Scrum Master nutzen dafür die Definition of Done.

Wenn du jetzt stutzt, dann geht es dir wie vielen anderen. Sie erliegen alle einem Irrtum. Sie glauben, dass in Scrum die Definition of Done nur dazu da ist, die Qualitätskriterien an das Produkt festzuschreiben. Das stimmt erst mal, aber hinter ihr verbringt sich noch ein viel mächtigeres Werkzeug.

Die Definition of Done ermöglicht es, das Risiko, welches bei der Entwicklung von Produkten herrscht, sichtbar zu machen und zu managen. Wenn du als Scrum Master dafür Verantwortung übernimmst, dann bist du der Risikomanager des Produkts!

Ich erkläre dir, was ich damit meine:

Wenn ich gefragt werde, was Scrum ausmacht, dann antworte ich:

„Scrum ermöglicht empirisches Arbeiten, indem mindestens einmal pro Sprint ein „done“-Inkrement erstellt wird.“

Der Zweck von Scrum ist also, ein „done“-Inkrement zu erstellen.

Als Ken Schwaber, der Scrum-Miterfinder, vor einigen Jahren danach gefragt wurde, um was es im Kern bei Scrum geht, antwortete er in einem Wort: „done“. Seither hängt im Hauptsitz von Scrum.org in Boston ein eingerahmtes Foto. Es zeigt Ken mit einer Sticky-Note mit der Aufschrift „done“.

Dies zeigt dir, wie zentral das Verständnis eines „done“-Inkrements für den Erfolg von Scrum ist. Deshalb ist es auch so wichtig, dass Scrum Teams Zeit aufwenden, um zu klären, was zur Erstellung eines „done“-Inkrements gehört. Welche Arbeiten sind dafür erforderlich? Welche Tests müssen durchgeführt werden? Was muss noch erledigt werden, um den Qualitätsrichtlinien des Unternehmens zu entsprechen?

Dieses gemeinsame Verständnis wird als Definition of Done bezeichnet und hat in der Regel die Form einer Checkliste.

Als Scrum Master übernimmst du für die Erstellung und das gemeinsame Verständnis dieser Definition of Done die Verantwortung.

Wie hilft die Definition of Done, das Risiko zu managen?

Alle Einträge im Product Backlog sind nur Annahmen.

In der Regel sind sie so lange Annahmen, bis sie umgesetzt wurden und als neue Version des Produkts in den Händen der Anwender liegen.

Hier einige Beispiele für derartige Annahmen:

• „Wird die Implementierung dieses Eintrags die Nutzererfahrung verbessern?“
• „Werden die Nutzer verstehen, wie sie die Funktion verwenden sollen?“
• „Haben wir genug Serverkapazitäten geschaffen, damit alle Nutzer die App gleichzeitig benutzen können?“
• „Wie können wir diesen Product-Backlog-Eintrag testen und liefern?“
• „Auf welche technischen Probleme werden wir bei der Umsetzung stoßen?“
• „Haben wir gut genug verstanden, was entwickelt werden soll?“

Jede dieser Fragen offenbart Annahmen, die Scrum Teams bei der Entwicklung machen. Deshalb gilt:

Jede dieser Annahmen stellt ein Risiko dar.

Das Risiko,

• dass die Wünsche eines Anwenders missverstanden wurden und das Feature überarbeitet werden muss.
• dass beim Programmieren die Entwickler an technische Grenzen stoßen und die bisherige Arbeit verworfen und ein neuer Ansatz gefunden werden muss.
• dass die Funktion weniger angenommen und verwendet wird, als erwartet, und deshalb zusätzliches Marketing, vermehrte Nutzerführung oder Dokumentation nötig ist.
• dass sich beim Erstellen der automatisierten Tests Fehler einschleichen, die dazu führen, dass die Tests häufig aus unerklärlichen Gründen abbrechen.
• dass Geld und Zeit für die Umsetzung von Anforderungen ausgegeben werden, die der Kunde dann doch so nicht haben will und sich auf die kostenlose Änderungsklausel im Vertrag beruft.

Diese Risiken haben zwei Dinge gemein:

1. Die Risiken werden erst erkannt, nachdem die Arbeit getan wurde.
2. Die Risiken führen im Nachhinein zu weiterer Arbeit.

Diese Arbeit nennen wir „undone work“ oder ungetane Arbeit, da es sich um Arbeit handelt, die noch zu erledigen ist, bis das Inkrement „done“ ist. Sie hat die Tendenz, immer dann aufzutauchen, wenn wir sie am wenigsten erwarten und sie die Arbeit in diesem Sprint durcheinanderbringt.

Die beste Möglichkeit, das Risiko ungetaner Arbeit zu vermeiden, besteht darin, dafür zu sorgen, dass jeder Sprint zu einem „done“-Inkrement führt, das potenziell geliefert werden kann. Mit lieferbar meine ich: Der Product Owner muss nur mehr auf das Knöpfchen drücken und die neue Version des Produkts ist in den Händen der Nutzer. Das bedeutet: Das Inkrement ist vollständig getestet und funktioniert einwandfrei, die Dokumentation ist auf dem neusten Stand und die Qualität entspricht den Unternehmensstandards.

Erst, wenn es keine ungetane Arbeit mehr gibt, wird die Feedbackschleife über den Nutzer geschlossen. Die empirische Prozesskontrolle wird ausgeübt, indem das Inkrement freigegeben wird, um zu überprüfen, ob das Produkt seine Ziele erfüllt und das tut, was die Anwender begeistert!

Um diese Schritte zu veranschaulichen, zeige ich dir das folgende Schaubild. Im fortgeschrittenen „Professional Scrum Master“-Training erkläre ich den Teilnehmenden anhand dieses Schaubilds, wie sie die Definition of Done verwenden können, um ihr Team zu unterstützen. Es geht auf Gunther Verheyen, Christiaan Verwijs und Barry Overeem zurück.

In dem Maße, in dem sich die Fähigkeit von Scrum-Teams, „done“-Inkremente zu liefern, nach rechts verschiebt, sinkt das Risiko von ungetaner Arbeit.

Anders gesagt: Als Scrum Master managst du das Risiko, indem du deinem Team vermittelst, dass „done“ auch potenziell auslieferbar bedeutet.

Das verstehe ich unter Risikomanagement bei komplexer Arbeit. Du erstellst keine Dokumente, sondern du schaffst ein Umfeld, in welchem Risiken frühzeitig transparent gemacht werden, sodass das Scrum Team sie eliminieren kann. Denn erst dann ist das Risiko auf die Kosten von maximal einem Sprint reduziert worden.

Dadurch wirst du als Scrum Master zum Risikomanager im Unternehmen!

In jedem Sprint ein „done“-Inkrement zu erstellen, ist sicherlich eine Herausforderung für viele Teams. Allerdings geht es genau darum in Scrum. Scrum Master, die dafür Verantwortung übernehmen, zeichnen sich als professionelle Scrum Master aus. Sie helfen ihren Teams, ein gemeinsames Verständnis von der aktuellen Definition of Done herzustellen, und unterstützen ihr Team dabei, nicht eher zu ruhen, als dass „done“ wirklich potenziell auslieferbar bedeutet.