Agiles Risikomanagement mit Scrum - empört euch!

Eine der spannendsten Definitionen für Risiko, die ich in der letzten Zeit gelesen habe, kommt von Peter Sandman: "Risiko = Gefahr + Empörung". Im öffentlichen Leben, leider aber auch in vielen Organisationen bleiben die meisten Leute in der Empörung stecken und schüren negative Emotionen, statt sich mit der eigentlichen und drohenden Gefahr zu beschäftigen.So kann es schnell passieren, dass man sich über eine große Gefahr zu wenig empört oder eine kleine Gefahr mit viel Empörung zu sehr aufbauscht. Sehen wir uns das Beispiel der Brent Spar aus dem Jahr 1995 an: Der Konzern Shell wollte einen schwimmenden Öltank in der Nordsee versenken. Greenpeace besetzte die Brent Spar und sorgte dadurch für großes Medienecho, das von der Bevölkerung stark aufgenommen wurde. Im Nachhinein stellte sich heraus, dass die Empörung stärker war als die angenommene Gefahr. Aber erst die große Empörung führte dazu, dass das Risiko für die Entsorgung so groß eingeschätzt wurde, dass der schwimmende Öltank nicht mehr versenkt wurde.Vor allem, wenn wir über Zukünftiges diskutieren, empören wir uns schnell und werden emotional. Wir wissen nicht, was kommen wird. Diese Unsicherheit zwingt uns zu Vermutungen und bringt unsere Befindlichkeiten ins Spiel. Und während wir Zeter und Mordio schreien, verlieren wir den Kontakt zu den Tatsachen und geben einem Risiko manchmal mehr Macht, als es tatsächlich hat.Viele der Risiken, die uns bei der Produktentwicklung begleiten, entstehen während der Entwicklung des Produkts. Dass man zu diesem Zeitpunkt genau hinsieht, ist umso wichtiger. An dieser Stelle befassen wir uns in Scrum, dank eines empirischen Prozesses, mit Fakten - wir brauchen also keine Vermutungen mehr. Denn oft sind es, neben Time to Market, die Probleme der Organisation, die die Produktentwicklung gefährden."Wie geht Scrum eigentlich mit Projektrisiken um?", ist eine der Fragen, die in diesem Zusammenhang gerne gestellt wird. Hier 6 Punkte, die uns in der Agilen Software-Entwicklung und vor allem in Scrum helfen, effektiv mit Risiken umzugehen:

1. Agile Werte und Prinzipien
2. Impediment Backlogs und der ScrumMaster
3. User Stories und die Frage "Wozu?"
4. Schätzungen (Estimates)
5. Schnelles Feedback durch End-User
6. Potentially Shippable Increment

Agile Werte und Prinzipien

Durch einen offenen und mutigen Umgang mit Impediments gehen wir gemeinsam Risiken der Produktentwicklung an. Wir begrüßen Veränderung, sowohl organisatorisch, als auch auf das Produkt bezogen. Unseren Erfolg messen wir allein am Fortschritt des Produkts und setzen Kooperation an die Spitze unseres Handelns.Wir sind uns also des Risikos bewusst, dass eine zu genau geplante Zukunft ein sehr großes Risiko ist. Stattdessen arbeiten wir in kurzen Zeitspannen (Sprints) und reagieren frühzeitig auf die Veränderungen der Geschäftswelt. Wir berücksichtigen die Kundenwünsche, nehmen sie auf und gehen sie zum richtigen Zeitpunkt an - und zwar zum Zeitpunkt der Umsetzung. Somit widmen wir uns immer nur den wichtigen Anforderungen und unterscheiden zwischen wichtig und unwichtig.Ein offener und mutiger Umgang mit Herausforderungen, Fortschritt und Hindernissen hilft uns dabei, die Risiken aus dem Weg zu räumen.

Impediment Backlogs und der ScrumMaster

In Scrum beschäftigen wir uns an mehreren Stellen mit Hindernissen und Problemen (Impediments). Dabei handelt es sich um die Risiken, die während des Projekts auftreten und das Produkt gefährden. Wir sammeln und verwalten die Impediments transparent und öffentlich in Impediment Backlogs.Aus dem Impediment Backlog können wir sehr gut ablesen, welche Risiken im Projektverlauf in der Praxis auftreten. Hier findet man bspw. die zwischenmenschlichen Probleme und organisatorischen Hindernisse, die während der Zusammenarbeit entstehen. Wir unterteilen Impediment Backlogs nach Kontroll- bzw. Einflussbereichen:

1. Kann es vom Team gelöst werden, liegt die Verantwortung in der Zusammenarbeit zwischen den Teams oder in der Organisation. Folglich zeigt das Impediment Backlog des Teams die Hindernisse auf, die das Team betreffen und bei der Arbeit behindern.
2. Abhängigkeiten zu anderen Teams findet man in der Skalierung auf dem Company Board.
3. Im ScrumMaster Impediment Backlog verwalten die ScrumMaster gemeinsame, organisatorische Impediments und koordinieren über das Board ihre Vorgehensweise.

Dadurch, dass wir in Scrum echte Boards verwenden, machen wir Impediments für alle sichtbar. Damit können wir zum einen zeigen, dass Impediments vorhanden sind (Push-Prinzip), zum anderen steigert es die Empörung und es wird notwendig, einer Gefahr ins Auge zu sehen.Der Umgang mit Impediments und der Organisationsentwicklung bekommt in Scrum einen besonderen Stellenwert: Der ScrumMaster ist organisatorisch eingesetzt, um die Veränderungen an der Organisation voranzutreiben, damit sie schnell den Anforderungen gerecht wird. Er muss den Status Quo der Organisation angreifen, damit sich die Organisation in punkto Zusammenarbeit und Kultur positiv verändert. Er stößt also mit den Anforderungen der Gegenwart an die Grenzen des organisatorischen Rahmens, der ja auf den Kenntnissen der Vergangenheit beruht. Aus der Erfahrung heraus wissen wir, dass das größte Risiko bei Veränderungen darin liegt, zu langsam zu sein. Dass Veränderung nicht fehlschlägt, weil sie zu früh kommt, sondern weil wir zu lange gewartet haben - weil es nur wenige gibt, die die Veränderung nach vorne tragen. Bei einem ScrumMaster steht das in der Jobbeschreibung, er wurde für den Wandel angestellt.

User Stories und die Frage "Wozu?"

User Stories fordern und fördern Diskussionen. Dadurch verteilen wir das Wissen um Domäne und Anwendungsfall im gesamten Team. Durch Diskussionen schaffen wir den Raum für Fragen, Mitdenken und Kritik, lösen die Mehrdeutigkeit der Sprache leichter auf und vervollständigen das gemeinsame Bild der Story. Sobald wir als Team diskutieren und wir den Zweck der Funktion kennen, entwickeln wir eine gemeinsame Verantwortung (Ownership).Warum Diskussion zur Dokumentation? Mike Cohn bringt es auf den Punkt: "If you write them down, users will get exactly what they want. That's not true. At best, users will get exactly what was written down, which may or may not be anything like what they really want." (Mike Cohn, Succeeding with Agile, Addison-Wesley, 2010). Durch Diskussion nutzen wir das Potential der Gruppe, wir schaffen ein gemeinsames Verständnis und geben jedem eine Stimme. Denn erst durch die Bilder aller Beteiligten erkennen das komplexe System, in dem wir uns bewegen.Wozu das wozu?Die Anforderungen an unser System ändern sich. Ich weiß nicht, wie oft ich das schon gesagt, gelesen, geschrieben, gehört, gesungen, getanzt und... okay... in jedem Fall hilft uns das "wozu" auf mindestens drei Arten:

1. Es ist wertorientiert und der Wert ist beständiger als die beschriebene Funktion. Zudem lässt sich nur anhand eines Wertes bestimmen, ob die Funktion noch benötigt wird.
2. Der Wert kommuniziert das benötigte Verhalten besser als die Funktion selbst. Versteht ein Team, wozu die Funktion notwendig ist, so kann es diese anhand des Wertes kontrollieren. Ist nur der Wert bekannt, so kann das Team die Funktion entwickeln. Sind Funktion und Wert bekannt, kann das Team die Funktion in Frage stellen und ein besseres Ergebnis liefern.
3. Werte lassen sich anhand von Business Value vergleichen. D. h. Werte verstehen wir, sie sind eindeutiger und lassen weniger Spielraum für Interpretationen. Bei Funktionen muss jeder den Wert meist erst interpretieren, ihn sich "laden". Im Gegensatz dazu ist meist jedem klar, wie ein Wert durch eine Funktion erreicht werden kann. Durch Werte engen wir den Interpretationsspielraum einer Funktion ein.

Letztlich entzerrt die Frage nach dem "wozu" die Anforderung von der Implementierung und hilft uns, den Wert der Story zu verstehen. Wir schränken dadurch im Vorfeld nicht unseren Lösungsraum ein, sondern lassen die Art der Implementierung frei. Wir benennen die Funktion, zeigen den Wert auf und geben diese Anforderung dann weiter. Jetzt kann das DevTeam seine Expertise einbringen.

Schätzungen (Estimates)

Wenn wir User Stories und Anforderungen betrachten, dann stolpern wir immer wieder über Probleme beim Verständnis und Detaillierungsgrad, sowie der technischen Umsetzung der Stories. Um die richtige Größe zu finden und Risiken bzgl. der technischen Umsetzung zu identifizieren, schätzen wir in Scrum regelmäßig unser Product Backlog.Mit Schätzungen (Estimates) identifizieren wir die Stories, die fachlich zu ungenau oder technisch zu schwer zu realisieren sind. Wir schätzen und erarbeiten gemeinsam im Team die Stories und bilden dadurch die Grundlage für einen Releaseplan. Schätzt das DevTeam, dann bekommen die Spezialisten eine gewichtige Stimme. Dadurch adressieren sie Risiken bzgl. Verständnis oder Ungewissheit der Umsetzung. Sind solche kritischen Stories identifiziert, untersuchen wir sie schnellstmöglich durch Experimente (Sprints). Wir schaffen somit eine faktenbasierte Entscheidungsfindung durch Inspektion. Anhand der Ergebnisse können wir unser weiteres Vorgehen abstimmen, da wir die riskanten Punkte bereits getestet haben.Ein wichtiger Punkt ist, dass wir nicht einmalig schätzen, sondern kontinuierlich. D. h. wir schätzen eine Story mehrmals und bringen sie in ein Größenverhältnis zu anderen Stories. Außerdem verändern sich Stories in ihrer Größe über die Zeit, auch das wird berücksichtigt (bspw. wird ein Prozess für ein Audit relevant und muss nachverfolgt werden). Letztlich sind unsere Schätzungen die Grundlage für die Arbeit am Produkt in der Zukunft und auch hier kann wieder der Faktor Empörung eingesetzt werden, um besonders gefährliche Stories in einem Backlog auszumachen. Die Stimme der Experten im DevTeam müssen ein Gewicht für die strategische Entwicklung des Produkts bekommen. Umso wichtiger ist es daher, dass Estimation Meetings regelmäßig durchgeführt werden.

Schnelles Feedback durch End-User

Plan - Do - Check - Adapt: der Regelkreis der Qualitätssicherung nach William E. Deming ist die Grundlage kontinuierlicher Verbesserungsprozesse und die Hintergrundmusik von Scrum. In Scrum führen wir jedes dieser Elemente in Form von Arbeits-Meetings aus, denn Qualität ist die Grundlage der Risikominimierung.

Risiken sind wahrscheinlich eintretende Fehler. Um zu erkennen, ob ein Risiko eingetreten ist, müssen wir schnell und regelmäßig die Ergebnisse unserer Arbeit prüfen. Dazu brauchen wir Feedback vom Kunden und von End-Usern, die das Produkt einsetzen. Das Feedback holen wir am Ende eines Sprints im Review ein. Hier inspizieren wir die neuen Funktionen und verifizieren, ob wir das richtige Produkt gebaut haben. Wir verifizieren also nicht nur: "Läuft das Ding?" - nein, wir prüfen/validieren, ob es auch so läuft, wie es ursprünglich gewünscht war.Konkret ist das Review der Zeitpunkt, an dem das DevTeam wieder mit dem End-User zusammenkommt. Hier tanken die Beteiligten Wertschätzung und Motivation für die eigene Arbeit, tauschen sich über den Nutzen der Funktionen aus und lernen, einander besser zu verstehen. Meines Erachtens lassen sich viele Risiken bei der Zusammenarbeit alleine dadurch auflösen, dass man Menschen zum einen zusammenbringt und dem Gegenüber ein Gesicht gibt, und zum anderen ein Ergebnis schafft, über das diskutiert werden kann.Abstrakt gesehen führt uns das Review dazu, dass wir unsere Ergebnisse sichtbar und greifbar machen. Wir schaffen anschauliche Fakten, die eine konkrete Diskussion zulassen. Wir unterstützen das Verstehen der Beteiligten mit einer gemeinsamen Grundlage und erden das theoretische Verständnis durch praktisches Erfassen.Das Review zeigt uns Folgendes frühzeitig auf: Große Empörung = frühes Scheitern, frühes Erkennen von Fehlern. Und auch frühe Erfolge mit und ohne Scheitern. Denn Scheitern und Fehler sind Entdeckungen, die wir im Vorfeld nicht erkennen konnten. Oft erkennen wir erst durch die neuerlangten Ergebnisse den nächsten Schritt für unser Produkt.

Potentially Shippable Increment

Besonders bei Neuentwicklungen steckt ein großer Teil der Arbeit bei klassischen Projekten in der Planungs- bzw. Erfindungsphase. Wieviel unnötig dokumentiert und wieviel Information auf Halde produziert wird, lässt sich oft nicht sagen. Solange kein Ergebnis im Sinne eines Produkts fertiggestellt wird, bleibt der geschaffene Wert von Dokumentation und Information unsichtbar. Darüber hinaus besteht die Gefahr, dass zu viel Dokumentation und Information gesammelt wird und dabei hohe Kosten ohne direkten Gegenwert entstehen. Seth Godin schreibt in seinem Buch Tribes dazu: "The safer you play your plans for the future, the riskier it actually is."Priorisierung, kurze Sprints und dazu ein Potentially Shippable Increment am Ende jedes Sprints (Deliver every Sprint) helfen uns sehr, solche Risiken zu minimieren. Wir bekommen in jedem Sprint lauffähige, anwendbare Software, die Features mit dem höchsten Business Value liefert. Im Fall eines Projektabbruchs ist unsere Software lauffähig und kann eingesetzt werden. Funktionen sind durch alle Schichten hindurch implementiert und funktionsfähig. Wir können bspw. auch, sobald die wichtigsten Funktionen implementiert sind, die Entwicklung einstellen oder unmittelbar umschwenken. Dazu ist es wichtig, sich während des Sprints zu fokussieren. D. h., liefere Story für Story nach Business Value. Dadurch erhält man nach jedem Sprint ein System in einem lauffähigen Zustand."Liefere jeden Sprint" heißt auch, dass wir tatsächlich eine niedrige Time to Market haben und kurzfristig unser Produkt an neuen Kundenwünschen ausrichten können. Wir bekommen die Flexibilität, die wir benötigen und das bei konstanten Kosten. Zusätzlich können die End-User das Produkt frühzeitig nutzen, was wiederum auf die finanzielle Risikominimierung einzahlt.

Fazit

Die agile Produktentwicklung ist ein Baukasten, der stark darauf ausgerichtet ist, die Wahrscheinlichkeit von Fehlern bzw. Gefahren (Risiken) zu minimieren. Genauer gesagt haben wir damit einen Prozess für aktives Risikomanagement. Die Wahrnehmung von Risiken hängt sehr stark am Faktor der Empörung, der für die verbundenen Gefahren entstanden ist. Dazu kommt die Wahrscheinlichkeit, mit der ein Fehler eintritt, der die Gefahr auslöst.Scrum trägt dazu bei, Fehler frühzeitig zu erkennen und wertvolle Ergebnisse zu schaffen. Erreicht wird das dadurch, dass frühzeitig Ergebnisse geschaffen werden, Unsichtbares visualisiert wird, Empörung an den wichtigen Stellen verstärkt wird und wichtige Erkenntnisse von Experten frühzeitig anhand von Fakten diskutiert werden. Denn komplexe Systeme benötigen ein Vorgehen, das Entscheidungen aufgrund von Fakten trifft. Mit Scrum haben wir zusätzlich eine Methode, die erfolgreich den Status Quo angreifen kann und uns dadurch überdurchschnittliche Gewinne beschert. Wenn wir in kurzen Zyklen Funktionen mit Produktreife liefern und unsere Ergebnisse verifizieren, vermeiden wir Fehler und wandeln Risiken in Wettbewerbsvorteile um. Und das alleine durch entschiedenes Handeln. In jedem Management-Magazin der letzten Jahre wird empfohlen: Lassen Sie sich auf Experimente ein und versuchen Sie, durch schnelle Erfolge oder schnelles Scheitern zu lernen. Scrum hilft dabei, diese Experiment durchzuführen. Experiment und Scrum bieten Rahmen und Raum, den Menschen benötigen, um effektiv zu arbeiten und setzen die notwendigen Kontrollpunkte, um Risiken zu minimieren. Viel Erfolg!