Wie wird der Erfolg deines Scrum Teams gemessen?
Die Chancen stehen gut, dass der Erfolg des Teams am Verhältnis von versprochenen zu gelieferten User Stories festgemacht wird. Laut dem 15. State of Agile Report trifft dies bei 35 % aller Unternehmen zu. Warum ist diese Einstellung noch so weit verbreitet?
3 Erklärungsversuche, warum diese Denke auch im Jahr 2022 noch in vielen Unternehmen tief verankert ist
- Zuerst muss die Arbeit analysiert werden. Nachdem der Umfang geschätzt wurde, kann die Arbeit in eine zeitliche Abfolge gebracht werden. Da ein Arbeitsschritt erst dann begonnen werden kann, wenn der vorherige Schritt abgeschlossen ist, resultieren Abweichungen vom Plan in Verzögerungen. Diese Verzögerungen gilt es zu vermeiden. Viele Unternehmen glauben, dass für maximale Produktivität alle Ressourcen immer ausgelastet werden müssen.
- Die Ausbildung in Universitäten folgt leider immer noch diesem Muster: Am Anfang der Vorlesung bekommen die Studierenden ihren Lehrplan ausgehändigt und es wird ihnen gesagt, welche Kapitel sie in welchen Büchern studieren müssen. Am Ende des Semesters wird in einer Prüfung das Wissen der Bücher abgefragt. Das verheerende an diesem Vorgehen? Den Studenten wird eingebläut, dass Erfolg bereits vorab feststeht und es nun bloß darum geht, den vorgeschriebenen Schritten zu folgen, um bestmöglich abzuschneiden. So ausgebildet, fällt es Absolventen schwer, diese Einstellung im Berufsleben zu vergessen.
- Was ist die verbreitetste Metrik in der IT? Laut dem 15. State of Agile Report messen immer noch 45 % der befragten Unternehmen die Velocity. Das Schlimme daran ist, dass die wenigsten Teams das wirklich mit Absicht machen, allerdings spuckt Jira automatisch diese Zahl als Fortschrittsfaktor eines Teams aus. Ich befürchte, wenn kein einschneidender Grund besteht, dann scheuen Teams den Aufwand, daran etwas zu ändern. Und wenn Scrum Teams die Zahl kennen, wie viel sie im letzten Sprint erledigt haben, ist es nur natürlich, sich für den nächsten Sprint die gleiche Menge vorzunehmen. Leider sehen immer noch viele Menschen darin ein Maß an Effizienz. Und welches Unternehmen wünscht sich nicht, dass seine Teams effizient arbeiten?
Die Gründe sind vielfältig, aber alle eint der Glaube, dass die Einhaltung eines Lieferversprechens den Erfolg eines Scrum Teams bestimmt.
Wenn du das ändern möchtest, dann stellst du dir unweigerlich die Frage: Wo soll ich beginnen?
Als erfahrener Scrum-Anwender weißt du, dass der Erfolg eines Scrum Teams ausschließlich daran gemessen werden sollte, wie viel Wert die Teammitglieder mit ihrem Produkt bei den Kunden des Unternehmens stiften. Und dir ist auch bewusst, dass die Grundvoraussetzung für die Realisierung für Wert ist, dass Teams wirklich das Produkt in die Hände der Nutzer legen können. Teams müssen also in der Lage sein, regelmäßig zu liefern.
Wo beginnst du also? Fokussierst du dich auf die Wertgenerierung oder die Lieferfähigkeit?
Half-Life sollte ursprünglich im November 1997 released werden, um nicht gegenüber Quake II ins Hintertreffen zu gelangen. Obwohl Valve im September bereits innovative Aspekte bei Waffen, Gegnern und Leveldesign ins Spiel integriert hatte, erkannten die Entwickler, dass noch die wichtigste Zutat fehlte. Es machte einfach keinen Spaß, das Spiel zu spielen. Deshalb verzögerte Valve die Markteinführung und überarbeitete jedes Level. Obwohl Half-Life erst im November 1998 released wurde, war es ein Kassenschlager.
Die Geschichte des Softwarestudios Valve zeigt, dass es für Unternehmen erfolgversprechend ist, den Kundenwert über die pünktliche Lieferung zu stellen.
Ich würde jedoch der Lieferfähigkeit den Vorzug geben.
Unternehmen, die nicht in der Lage sind, kritische Fehler kurzfristig zu beheben, setzen ihr Geschäftsmodell einem enormen Risiko aus. Nicht in der Lage zu sein, auf Probleme schnell zu reagieren, kann dazu führen, dass Kunden reihenweise dem Unternehmen den Rücken kehren. Für ein Beispiel musst du nicht weit in die Vergangenheit schauen. Mitte Dezember 2021 wurde eine Schwachstelle in der Java-Bibliothek Log4j gefunden. Diese Schwachstelle führte zu einer extrem kritischen Bedrohungslage. Im schlimmsten Fall könnte eine Ausnutzung der Log4Shell-Sicherheitslücke dazu führen, dass das betroffene System vollständig von Angreifern übernommen werden kann. Nach Bekanntwerden der Bedrohung setzten mehrere Krankenkassen, darunter die AOK, die DAK, die LKK und alle Betriebskrankenkassen, die Aktensysteme ihrer Apps zwischenzeitlich „in den Wartungsmodus“. Die Geschwindigkeit, mit der eine solche Sicherheitslücke geschlossen wird, bestimmt nun, ob die Kunden dem Unternehmen den Rücken kehren oder nicht.
Wenn du also nicht sicher bist, wie du deinem Team aus der „Promised vs. delivered“-Sackgasse helfen kannst, dann lautet mein Rat: Beginne damit, die Lieferfähigkeit zu verbessern.
Erst wenn dein Team in der Lage ist, regelmäßig zu liefern, solltest du dich dem eigentlichen Ziel zuwenden: Nicht nur wie versprochen zu liefern, sondern wirklichen Wert zu stiften.
4 Schritte, wie du dabei vorgehen kannst
Schritt 1:
Hilf deinem Team zuerst, einen kontinuierlichen Fluss von gelieferter Software herzustellen. Mindestens jeden Sprint sollte dein Team eine neue Version des Produkts ausliefern. Der potenzielle Wert der einzelnen Lieferungen steht hierbei nicht im Vordergrund, es geht nur darum, kontinuierlich zu releasen. Um die Haltung des Teams dahingehen zu beeinflussen, habe ich mal einem Team folgende Wette vorgeschlagen: Wenn ihr es schafft, in den nächsten 10 Tagen jeweils einen kleinen Bug zu fixen und zu liefern, dann backe ich jedem von euch einen Kuchen. Falls nicht, müsst ihr mir einen Kuchen backen. Im nächsten Sprint musste ich viele Kuchen backen.
Schritt 2:
Liefert das Team regelmäßig, besteht der nächste Schritt darin, dem Team zu helfen, in Outcomes zu denken. Es geht nun nicht mehr darum, Features zu liefern, sondern zu verstehen, welche Verhaltensänderungen das Team bei den Nutzern des Produkts bewirkt. Da diese Denkweise für Teams ungewohnt ist, benötigt es hier viel Fingerspitzengefühl. Du musst das Team langsam befähigen, in Outcomes zu denken, ohne es dabei zu überfordern. Ein guter Startpunkt ist, Product-Backlog-Einträge nicht mehr als Lösungen, sondern als Probleme, Fragen, Annahmen oder Hypothesen zu formulieren. Hier ein Format, wie eine Hypothese formuliert werden kann.
Wir glauben, [Feature] ermöglicht Nutzern [Vorteil]. Wir werden wissen, ob wir [richtig/falsch] liegen, sobald wir folgendes [Feedback] von Nutzern erhalten oder [Verhaltensänderung] beobachten.
Dieses Format leitet sich aus der Arbeit mit Lean-UX-Canvas ab. Wenn du eine praxisorientierte Einführung in das Arbeiten mit dem Lean-UX-Canvas suchst, empfehle ich dir das Professional-Scrum-With-UX-Training zu besuchen.
Schritt 3:
Schritt 2 ist abgeschlossen, wenn das Team Erfolg darin sieht, so lange zu iterieren, bis die gewünschte Verhaltensänderung bei den Nutzern hervorgerufen wurde. Und nicht mehr darin, ob die versprochene Menge an Product-Backlog-Einträgen erledigt wurde. Da die Abarbeitung des Product Backlog jetzt nicht mehr das Ziel des Teams ist, muss ein wertstiftendes Ziel für das Team gefunden werden. Das Team benötigt einen Nordstern, auf welchen es sich hinbewegt. Hierfür eignen sich Metriken, die den Geschäftswert beschreiben, welchen sich das Unternehmen durch die Entwicklungsarbeit des Teams erhofft. Ein Beispiel hierfür könnte etwa die Verbesserung des Net Promoter Scores, die Steigerung der Retention-Rate, die Reduzierung der Abwanderungsrate, die Steigerung des Umsatzes oder die Verbesserung der Konvertierungsrate sein. Die Definition eines solchen Produkt-Ziels stellt die Verbindung zwischen dem erhofften Wert für das Unternehmen und den Zielen oder Vorteilen der Nutzer des Produkts dar.
Schritt 4:
Ist das Team in der Lage, regelmäßig zu liefern und somit den Wert seiner Arbeit zu validieren, setzt es nicht mehr vorgegebene Lösungen um, sondern trifft Annahmen darüber, wie das Nutzerverhalten beeinflusst werden kann, und sucht eigenständig nach Lösungen. Richtet es darüber hinaus seine Arbeit nach Unternehmenszielen aus, dann sollten am Ende die Stakeholder nicht außer Acht gelassen werden. Für das Einbeziehen von Stakeholdern eignet sich etwa die regelmäßige Diskussion der Roadmap. Diese Roadmap besteht nun aber nicht mehr aus Features und Fristen, sondern aus Produkt-Zielen, Problemen und Hypothesen. Im Folgenden ein Bild einer Roadmap, in der das Team sukzessive die Features durch Hypothesen und offene Fragen ersetzt hat.
Diese vier Schritte haben mir in der Vergangenheit geholfen, aus der „Delivered vs. Promised“-Sackgasse zu entfliehen und ein Feature-Factory-Team in ein wahres Produktteam zu verwandeln. Wenn du sie befolgst, schreib in die Kommentare, was bei dir funktioniert und auf welche Schwierigkeiten du bei der Umsetzung stößt.