Scrum Teams, die Entwicklung und UX in einem Team vereinen, stehen unweigerlich vor der Frage:
„Wie gehen wir mit den Resultaten von Experimenten im Sprint Review um?“
Wenn du auch vor dieser Frage stehst, dann lies weiter:
Gleich vorweg eine Warnung aus dem Scrum Guide:
Warnung 1: Stelle keine unfertige Arbeit im Sprint Review vor
Wir sind uns einig, dass wir niemals unfertige Features liefern sollten.
Stellen wir uns nur vor, ein Team entwickelt ein Fahrerassistenzsystem. Da es gegen Ende des Sprints zeitlich eng wird, verzichtet das Team auf umfangreiche Tests. Würde das Team die Software jetzt live nehmen, dann würde sie vorsätzlich das Leben von Fahrern riskieren. Dieses Verhalten wäre nicht nur unethisch, sondern es würde auch die Zukunft des Unternehmens riskieren.
„Arbeit kann nicht als Teil eines Increments betrachtet werden, solange sie nicht der Definition of Done entspricht.“ – Scrum Guide
Dürfen Scrum Teams den Stakeholdern zumindest im Sprint Review unfertige Arbeit vorstellen?
Hierauf gibt der Scrum Guide auch eine Antwort:
„Innerhalb eines Sprints kann mehr als ein Increment erstellt werden. Deren Summe wird im Sprint Review vorgestellt, womit Empirie unterstützt wird.“ – Scrum Guide
Zusammenfassend könnten wir aus den Passagen des Scrum Guides also schließen, dass ein Scrum Team keine unfertige Arbeit im Sprint Review vorstellen darf.
Hinter dieser Warnung verbirgt sich Folgendes:
Außenstehende können bei digitalen Produkten häufig nicht unterscheiden, ob die Version des Produkts wirklich fertig ist oder nicht.
Stakeholder aus dem Sales- oder Marketingbereich besitzen in der Regel keinen IT-Hintergrund. Es fällt ihnen schwer, den Unterschied zu erkennen, ob eine Anwendung nur lokal auf einem Rechner eines Entwicklers läuft oder bereits auf dem Mobiltelefon der Nutzer. Sie wundern sich dann zurecht, dass zwischen diesen für sie identischen Zuständen des Produkts häufig noch mehrere Wochen der Entwicklungszeit liegen.
Was ist die Auswirkung davon?
Es besteht kein gemeinsames Verständnis über den Fortschritt der Entwicklung zwischen Scrum Team und Stakeholdern. In Scrum-Sprache sagen wir dazu, es herrscht keine Transparenz. Transparenz stellt die Grundsäule des empirischen Prozesses dar.
Ist die Empirie gestört, funktioniert Scrum nicht. Und davor will uns der Scrum Guide warnen.
Unerfahrene Scrum-Anwender schließen nun daraus, dass Scrum Teams auch nicht die Resultate von Experimenten in Sprint Reviews vorstellen dürfen.
Dabei erliegen sie folgendem Irrtum:
Irrtum: Alle Arbeit, die ein Scrum Team erledigt, muss die Definition of Done erfüllen
Dem ist nicht so!
Nur die Arbeit, deren Ergebnis auch Bestandteil des Produkts ist, muss die Definition of Done erfüllen.
Der Unterschied an einem Beispiel erklärt:
- Die ungetestete Software des Fahrerassistenzsystems erfüllt offensichtlich nicht die Qualitätsstandards des Produkts. Das Ergebnis der Entwicklung, etwa eine neue Produktfunktion, ist erst Bestandteil des Fahrerassistenzsystems, wenn es getestet wurde. Vorher erfüllt die Funktion nicht die Definition of Done.
- Das Ergebnis einer Kundenbefragung erfüllt auch nicht die Definition of Done, da das Ergebnis nicht direkt vom Nutzer zu verwenden ist.
Beide Arbeiten können aber Einträge im Produkt Backlog sein. Dies ist eines der Grundprinzipien, welches ich auch im Professional-Scrum-Master-2-Training unterrichte. Einem Training für Scrum Master, die ihr Wissen über Scrum vertiefen möchten und sich auf die PSM-2-Prüfung vorbereiten.
Der entscheidende Punkt hier ist:
Tatsache: Die Definition of Done gilt nicht für die Einträge im Produkt Backlog, sondern ist das Commitment zum Produkt.
Scrum Teams verpflichten sich dazu, diesen Qualitätsstandard bei ihrer Arbeit zu wahren, aber nur wenn das Ergebnis der Arbeit Teil des Produkts sein soll. Noch mal anders gesagt: Nimmt das Team Änderungen am Produkt vor, dann verpflichtet es sich (Commitment), die geltenden Qualitätsstandards zu wahren.
Da das Ergebnis einer Kundenumfrage erstmal nicht unmittelbar Bestandteil des Produkts ist, ist es also keine unfertige Arbeit und kann im Sprint Review besprochen werden. Der Scrum Guide hält dies so fest:
„Das Scrum Team stellt die Ergebnisse seiner Arbeit den wichtigsten Stakeholder:innen vor und die Fortschritte in Richtung des Produkt‐Ziels werden diskutiert.“ – Scrum Guide
Ich habe die Kundenumfrage als ein einfaches Beispiel für ein Lern-Experiment gewählt. Ein Spike oder ein Prototyp sind weitere Beispiele für Experimente. Wenn du eine praxisorientierte Einführung zu Lern-Experimenten suchst, empfehle ich dir das Professional-Scrum-With-UX-Training zu besuchen.
Bei der Vorstellung von Ergebnissen im Sprint Review möchte ich dir noch eine Warnung mit auf den Weg geben:
Warnung 2: Das Präsentieren von Resultaten aus Experimenten darf die Transparenz nicht schmälern.
Stell dir vor, du arbeitest in einem hippen Software-Start-up in Berlin. Der Dresscode ist locker, sportlich und leger. Eines Tages erhältst du einen Anruf eines Recruiters aus einer Versicherung. Natürlich bist du glücklich in deiner aktuellen Firma, aber das Angebot klingt zu verlockend, um nicht mehr darüber zu erfahren. Du stimmst einem Treffen in der Versicherung zu. Da das Treffen in deiner Mittagspause stattfinden soll und das mögliche Gehalt dir den Eindruck gibt, dass du besser einen Anzug tragen solltest, kommst du bereits am Morgen im Anzug in dein aktuelles Büro.
Natürlich bleibt es deinen Kollegen nicht verborgen, dass du dich fein herausgeputzt hast. Du musst also mit der Sprache herausrücken, was du heute Mittag vorhast. Mit welcher Absicht, denken deine Kollegen, wirst du zu diesem Gespräch gehen? Dein Versuch, deine Karrieremöglichkeiten auszuloten, kann schnell als Commitment interpretiert werden. Deine Kollegen und Vorgesetzten können denken, dass du die Firma verlassen willst. Infolgedessen wird sich ihr Verhalten dir gegenüber ändern.
Wenn wir das Gespräch als Experiment auffassen – ist es jetzt noch safe to fail?
Safe to fail bedeutet, dass bei einem Fail keine negativen Konsequenzen folgen werden. Es ist also sicher, auch wenn das Experiment schief gehen sollte.
Wenn über Experimente in Sprint Reviews gesprochen wird, besteht die Gefahr, dass aus Experimenten ein Commitment wird. Wird der Versuch als Verpflichtung missverstanden, führt es dazu, dass sich die Menschen dahin ausrichten. Dies kann so weit geschehen, bis es die einzige verfügbare Option wird. An diesem Punkt ist es nicht mehr sicher, dass diese Option scheitern wird.
Diese Einsicht sollte dir die Geschichte vor Augen führen.
Um dies zu vermeiden, kommuniziere bei Experimenten immer sorgfältig die Intention dahinter. Ein Experiment sollte immer bedeuten, dass wir auch scheitern können, ohne verurteilt zu werden.
Wichtig: Das Scrum Team darf keine negativen Konsequenzen zu befürchten haben, wenn Experimente scheitern.
Um die Intention klar herauszustellen, hat es sich für mich bewährt, bewusst zu benennen, für wen das Ergebnis des Experiments bestimmt ist. Hierfür ein Beispiel, anhand der obigen Experimente:
- Umfrage: Sie soll dem Scrum Team und den Stakeholdern Aufschluss geben, ob etwas wertvoll ist.
- Spike: Er soll dem Scrum Team Aufschluss geben, ob etwas möglich ist.
- Prototyp: Er soll einem Stakeholder zeigen, dass etwas möglich ist.
Wenn Experimente nicht klar kommuniziert werden, kann das zu Missverständnissen führen. Wie bei unfertiger Arbeit reduziert dies die Transparenz der Arbeiten. Die Stakeholder und das Scrum Team besitzen kein gemeinsames Verständnis mehr über den Fortschritt des Teams.
Fassen wir noch mal zusammen:
Unfertige Arbeit sollte nie im Sprint Review vorgestellt werden. Das Resultat von Experimenten kann jedoch vorgestellt werden. Hierbei lautet aber mein Rat an dich: Die Intention des Experiments und für wen das Ergebnis bestimmt ist, sollte immer klar kommuniziert sein. Sonst besteht die Gefahr, dass es für das Team nicht mehr sicher ist, wenn das Experiment fehlschlägt.