DevOps war gestern.
Eine lineare, schrittweise Abfolge von Änderungen — in der Regel durchgeführt von funktional getrennten Abteilungen — ist völlig unvereinbar mit der Änderungsgeschwindigkeit und Komplexität moderner Softwareprodukte. Die Annahme, dass der Softwareentwicklungsprozess nur wenig davon lernen kann, wie die Software in einer realen Umgebung betrieben wird, ist grundlegend falsch und wurde bereits vor einigen Jahren begraben. Welche aktuellen Trends folgen erfolgreiche Scrum Teams also stattdessen?
Als Steward kuriere ich die Praktiken, welche sich bei der Arbeit mit Scrum Teams in der weltweiten Professional Scrum Trainer Community bewährt haben. Hierbei sind mir folgende zwei Trends aufgefallen:
Trend # 1: Maximierung des Produktwerts, durch das Erzeugen von Outcomes anstelle des Fokus auf das Liefern
Nach Marty Cagan ist die erste unbequeme Wahrheit, welche Produktmanager lernen müssen, dass mindestens die Hälfte ihrer Produktideen einfach nicht funktionieren werden.
Stelle dir für einen Moment vor, du bist im Rahmen einer humanitären Mission in einem abgelegenen Dorf unterwegs. Du beobachtest mehrere Menschen, die jeden Tag viele Stunden damit verbringen, zu einem Fluss zu laufen, um Wasser zu holen und es zurück ins Dorf zu schleppen. Spontan fallen dir bestimmt viele Möglichkeiten ein, wie du den Dorfbewohnern helfen könntest. Einen Brunnen bauen, einen Lkw zum Wasserholen verwenden oder einen Wasserkanal zum Dorf graben. Diese Ideen für mögliche Produkte haben alle eines gemeinsam: Sie beschreiben nur Lösungen.
Welche von diesen Produktideen liefert wirklich das gewünschte Ergebnis, dassdas die Dorfbewohner weniger Zeit mit dem Tragen von Wasser verbringen?
So wenig, wie wir in diesem Beispiel die richtige Lösung wissen können, so wenig können es Produktentwicklungsteams bei ihrer Arbeit wissen. Deshalb konzentrieren sich erfahrene Scrum Teams darauf, dass ihre Lieferungen wirklich die Nutzererfahrung ihrer Kunden verbessert. Das regelmäßige Liefern funktionierender Software innerhalb weniger Wochen ist aus Sicht moderner Produktentwicklung nicht mehr ausreichend, um sicherzustellen, dass damit Outcome erzeugt werden. Ergebnisse zu erzeugen, die positive Auswirkungen auf die Geschäftszahlen haben, ist der einzige Maßstab für den Erfolg dieser Teams.
Wie fokussiert sich ein Scrum Team auf den Outcome seiner Arbeit?
Indem es der Entdeckung und der Validierung der Ergebnisse einen genauso hohen Stellenwert einräumt, wie der Lieferung von Features und Funktionen. Diese funktionsübergreifenden Teams haben nicht nur UX-Experten als Teammitglieder, sondern nutzen Experimente, um ihre Hypothese frühzeitig zu validieren, Product-Backlog-Einträge umfassen neben der Entwicklungsarbeit auch die Entdeckungsarbeit und im Sprint Review hat die Überprüfung der Outcomes den höchsten Stellenwert.
Trend # 2: Verbesserung der Vorhersagbarkeit durch kontinuierliche Optimierung des Arbeitsflusses statt durch mehr Planung
Wann wird das Feature fertig sein?
Diese legitime Frage, die Kunden im Sprint Review stellen und die Mitglieder der Scrum Teams häufig zusammenzucken lässt, sollte ein erfolgreiches Team beantworten können. Leider sind wir Menschen bekannt für unsere schlechte Fähigkeit, den zeitlichen Aufwand von Arbeit einzuschätzen. Dazu kommt noch, dass in Produktentwicklungsarbeit vieles ungewiss ist. Haben wir das Problem des Nutzers wirklich verstanden? Können wir eine Lösung bereitstellen, die dieses Problem löst? Ist die Bedienung unseres Produkts intuitiv genug, dass der Nutzer es verwenden wird? Ist der Preis so gewählt, dass Kunden das Produkt auch tatsächlich kaufen? Rentiert sich die Investition unseres Unternehmens in das Entwicklungsvorhaben auch langfristig? Schlechtes Schätzen und Ungewissheit bilden keine fundierte Grundlage um die Frage, wann die Arbeit fertig ist, exakt zu beantworten.
Sind Story Points die Lösung?
Durch die Verwendung von Story Points versuchen Scrum Teams die herrschende Unsicherheit bei der Beantwortung der Frage miteinzubeziehen. Aus meiner Erfahrung trifft das bei wenigen Stakeholdern auf Akzeptanz. Zurecht argumentieren sie, was sind Story Points eigentlich? Im Business sprechen wir darüber, wie viel Zeit und Geld ein Vorhaben kosten wird, ob es technisch machbar ist und wie viel Geld oder Geschäftswert es stiften kann. Aus meiner Sicht sind Story Points nicht per se ungeeignet, um vorherzusagen zu treffen, wann Product-Backlog-Einträge wahrscheinlich fertiggestellt sind. Allerdings haben Story Points einen gravierenden Nachteil, welcher in den Tiefen des industrialisierten Denkens des 20. Jahrhunderts verwurzelt ist.
Story Points versuchen die Zukunft zu approximieren.
Story Points vergleichen die zukünftige Arbeit mit der bereits geleisteten Arbeit. Dadurch können sie niemals die herrschende Ungewissheit adäquat beschreiben. Deshalb beantworten Scrum Teams, die sich vom industrialisierten Denken lösen konnten, die Frage, wann ein Feature geliefert wird, nicht mehr basierend auf Approximationen, sondern mit Prognosen. Eine Prognose beschreibt eine Reihe von Eintrittswahrscheinlichkeiten zu allen möglichen Zukunftsszenarien. Wann ein Feature fertig ist, könnte beispielsweise wie folgt prognostiziert werden: Mit einer Wahrscheinlichkeit von 50 % ist es in weniger als 13 Tagen fertig. Mit einer Wahrscheinlichkeit von 85 % ist es in weniger als 18 Tagen fertig. Mit einer Wahrscheinlichkeit von 95 % ist es in weniger als 27 Tagen fertig. Und so weiter. Im Unterschied zu Approximationen beziehen Prognosen die Ungewissheit durch die Angabe von Wahrscheinlichkeit, mit ein.
Erfolgreich Scrum Teams denken probabilistisch und nicht mehr deterministisch.
Diese Teams messen ihren aktuellen Prozess, indem sie den Durchsatz und die Cycle Time ihrer Arbeit festhalten. Die Einsicht, die ihnen diese Daten liefern, hilft ihnen, Prognosen zu geben, wann die Arbeiten im Product Backlog wahrscheinlich abgeschlossen sind. Sie geben ihnen auch Informationen, wie sie ihren Arbeitsprozess in Zukunft verbessern können. Zum Beispiel liefert die Reduzierung der Anzahl der Product-Backlog-Einträge, an welchen gleichzeitig gearbeitet wird, häufig eine Steigerung des Durchsatzes.
Möchtest Du mehr erfahren?
Hoffentlich war dieser Artikel nützlich für Dich. Wie du die Cycletime misst, ist eines der vielen interessanten Themen, die in meinen Professional Scrum Trainings behandelt werden.
Wenn du keinen neuen Beitrag mehr verpassen willst, dann abonniere meinen Newsletter, dort wirst du als Erster über neue Beiträge informiert.
👉 Hier geht zur Anmeldung.