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!

Agile Toolbox
Scrum
Schätzen
bgloger-redakteur
August 31, 2012

Table of content

Diesen Beitrag teilen

Das könnte auch interessant sein:

Agile Coach
Agile Management
Agile Organization
Agile Prinzipien
Agile Toolbox

FRAGE: Warum macht ihr eigentlich kein SAFe?

Agile Management
Agile Organization
Agile Prinzipien
Agile Toolbox
Transformation

FRAGE: Was kostet eine agile Transformation?

Agile Management
Agile Organization
Agile Toolbox
Leadership
Agiles Lernen

FRAGE: Welche Rolle spielt Training?

Agile Coach
Agile Management
Agile Organization
Agile Prinzipien
Agile Toolbox

FRAGE: Wer sind die Top 10 agilen Unternehmensberatungen?

Agile Management
Agile Organization
Agile Tools
Agiles Management
Leadership

FRAGE: Wie viel bringt die Investition? Was ist der Business Case dahinter?

Agile Management
Agile Organization
Agile Prinzipien
Agile Toolbox
Führung

FRAGE: Welche sind häufige Herausforderungen, die ihr beim Kunden löst?

Agile Management
Agile Organization

FRAGE: Warum sollten wir mit borisgloger arbeiten?

Agile Management
Agile Organization
Agiles Management
Transformation

FRAGE: Wie viel kostet eine Beratung und ist es wirklich rentabel bei borisgloger?

Agile Prinzipien
Agile Toolbox
Projektmanagement

The Lie Behind the Parable of the Golf Balls and the Jar

Video
Change
Digitale Transformation
Hardware
Agile Organization

Agile in Industrial Automation: The Digital Transformation of Yokogawa

Versicherung
Neues Arbeiten
Führung
Agile Prinzipien
Kundenfokus

Kundenzentrierte Versicherung: Kann ein agiles Projekt die Organisation retten?

Versicherung
Change
Digitale Transformation
Agile Prinzipien
Kundenfokus

Agilität in den Vertrieb bringen – für Versicherer sinnvoll

Versicherung
Agile Prinzipien
Kundenfokus
Agile Toolbox
Produktentwicklung

BizDevOps in der Versicherungsbranche – Wie multidisziplinäre Teams wirklich besetzt sein sollten

Versicherung
Agile Prinzipien
Kundenfokus
Neues Arbeiten
Meetings

Undercover Agile für Versicherer: 5 agile Praktiken für Ihr klassisches IT-Projekt

Versicherung
Change
Digitale Transformation
Agile Prinzipien
Kundenfokus

IT-Projekte in der Versicherungsbranche – Das Rennen um die Time-to-Market

Team
Neues Arbeiten
Agile Prinzipien
Selbstorganisation
Social Skills

Umgang mit Fehlern & Diversität – Erfolgreiche agile Teams #2

Team
Neues Arbeiten
Agile Toolbox
Produktentwicklung

Das Geheimrezept von High-Performance-Teams

Team
Arbeiten bei borisgloger consulting
Agile Prinzipien
Freiwilligkeit
Selbstorganisation

Konsent und offene Wahl: 2 Prinzipien aus der Soziokratie, die jedes agile Team gebrauchen kann

Team
Neues Arbeiten
Meetings
Social Skills

Der agile Adventkalender

Team
Agile Toolbox
Scrum
ScrumMaster-Praxistipps
Agile Prinzipien

Selbstorganisation der Teams fördern: Ask the team!

Team
Agile Toolbox
Design Thinking

Who Recognizes the Truly Good Ideas?

Team
Agile Organization
Transformation

Pizza Is Not Dead, and Neither Is Agility

Scrum4Schools
Neues Arbeiten
Führung
Life
Social Skills

Trauen wir unseren Kindern mehr zu – auch in der Schule!

Scrum4Schools
Change
Agiles Lernen
Neues Arbeiten
Remote Arbeiten

Eine Scrum4Schools-Projekt-Rückschau mit Physiklehrer Ivan Topic

Scrum4Schools
Mehr Formate
Interview
Nachhaltigkeit

Mit Scrum4Schools dem Weltraum auf der Spur

Scrum4Schools
Change
Agiles Lernen

Scrum4Schools - ein Projekt nimmt Fahrt auf

Scrum4Schools
Agile Schulentwicklung
Agile Toolbox

Technik im Alltag - Scrum4Schools zu Gast in Langenzersdorf

Projektmanagement
Agile Toolbox
Scrum
Scrum-Begriffe
ScrumMaster-Praxistipps

Sprechen Sie Agile? Den klassischen Projektplan in die agile Welt überführen

Projektmanagement
Agiles Management
Agile Toolbox
Scrum
Enterprise Scrum

Das Management in Scrum

Projektmanagement
Change
Digitale Transformation

Agilität in der Logistik oder: Liefern wie Amazon

Projektmanagement
Agile Toolbox
Scrum

Meilensteine und Scrum

Portfoliomanagement
Project management

Too many projects? Portfolio management simplified

Neues Arbeiten
Mehr Formate
Agile Toolbox
Scrum
Scrum Values

Wie agiles Arbeiten die Kommunikation aus der Selbstverständlichkeit holt

Neues Arbeiten
Change
Agiles Lernen
Mehr Formate
Audio

New Learning heute für das New Work von morgen – mit Angelika Weis

Neues Arbeiten
Change
Soziale Innovation

New Work Experience 2019 – ein Erfahrungsbericht

Neues Arbeiten
Audit
Change

Agil im Audit: das Starter-Kit

Neues Arbeiten
Agile Toolbox
Scrum
Scrum4Schools
Agile Prinzipien

Scrum4Schools: Lernen für die Zukunft

Neues Arbeiten
Agile Toolbox
Scrum
Scrum Meetings
Retrospektive

Arbeiten wir uns gesund!

Neues Arbeiten
Agile Toolbox
Scrum
ScrumMaster-Praxistipps

Who should be in (agile) HR?

Neues Arbeiten
Agile Toolbox
Scrum
Scrum Values

Glauben Sie an die Seele Ihrer Firma?

Neues Arbeiten
Agile Toolbox
Scrum
Product Owner
ScrumMaster-Praxistipps

Produktivität auf Irrwegen: "Führen wir schnell mal Scrum ein!"

Neues Arbeiten
Agile Prinzipien
Selbstorganisation
Social Skills
Team

Freiwilliges Teilen von Wissen – Erfolgreiche agile Teams #5

Neues Arbeiten
Agile Prinzipien
Selbstorganisation
Social Skills
Team

Doing vs. Being Agile – Erfolgreiche agile Teams #1

Neues Arbeiten
Agile Prinzipien
Selbstorganisation
Social Skills
Team

Freude bei der Arbeit & Sustainable Pace – Erfolgreiche agile Teams #3

Neues Arbeiten
Agile Prinzipien
Selbstorganisation
Social Skills
Team

Anpassungsfähigkeit & schonungslose Offenheit – Erfolgreiche agile Teams #4