Wirkungsvolle Agilität mit Scrum – Feedbackschleifen

Von der Idee ...

Hinter jeder Softwareentwicklung steckt ursprünglich eine Idee. Diese kann auf vielfältige Art und Weise entstehen, z. B. durch

• Herausforderungen innerhalb des Unternehmens, die mit einer neuen maßgeschneiderten Software gelöst werden sollen,
• Bedürfnisse der Zielgruppe, die durch eine Marktanalyse identifiziert wurden und mit einem neuen Softwareprodukt befriedigt werden sollen,
• Benutzerfeedback zu einer bestehenden Software, das zu neuen Funktionen oder Verbesserungen führen soll.

... zur erfolgreichen Umsetzung

Die Frage ist, wie und wann sichergestellt wird, ob mit der Softwarelösung tatsächlich das identifizierte Problem gelöst oder Bedürfnis erfüllt wurde.

In der Softwareentwicklung gibt es mehrere Vorgehensweisen, vorrangig klassisch nach Wasserfall oder agil.

Klassisch nach dem Wasserfallmodell werden zunächst die Gesamtanforderungen detailliert geplant, die Disziplinen „Analyse“, „Design“, „Implementierung“, „Testen“ und „Inbetriebnahme“ erfolgen anschließend sequenziell. Bei diesem Vorgehen kann es Monate oder Jahre dauern, bis eine erste nutzbare Version der Softwarelösung auf Grundlage des fest geplanten Umfangs entwickelt ist. Zu dieser Softwareversion erfolgt ein Feedback, mit dem überprüft werden kann, ob das identifizierte Problem gelöst oder Bedürfnis erfüllt wurde.

In der Softwareentwicklung sind jedoch in der Regel im Vorfeld nicht alle Anforderungen bekannt oder es ändern sich diese. Deshalb ist es in diesen Fällen nicht wirtschaftlich, einen Plan für den gesamten Entwicklungszeitraum zu machen und diesen starr umzusetzen, weil so Zeit-, Kosten und Funktionalitätsziele verfehlt werden.[1] Im Blogbeitrag “Vor- und Nachteile der agilen Softwareentwicklung” hat mein Kollege Stanislaw Nasin weitere interessante Aspekte dazu aufgeführt.

Eine Alternative ist es, den Umfang variabel zu halten und agil vorzugehen. Bei diesem Vorgehen ist das Ziel, dem Kunden so schnell wie möglich Wert mit der Softwarelösung zu liefern. Dazu erfolgt das wiederholte Durchlaufen von Entwicklungszyklen mit Feedbackschleifen, um den Wert zu überprüfen und neue oder geänderte Anforderungen im Entwicklungsprozess zu berücksichtigen. Dieses agile Vorgehen hat sich in der Softwareentwicklung etabliert. Zu den bekanntesten Frameworks zählt Scrum.

Bei Scrum werden die Entwicklungszyklen als Sprints bezeichnet und dauern maximal einen Monat. In diesem Zeitraum wird eine wertvolle und potenziell auslieferbare Version des Produkts entwickelt. Am Ende des Sprints wird diese Version, das sogenannte Software-Inkrement, überprüft und künftige Produktanpassungen festgelegt.

Die Verkürzung von Feedbackschleifen in der Softwareentwicklung ist ein Kernelement für wirkungsvolle Agilität, dem Überprüfen und Anpassen des Produkts. Wie eine erfolgreiche Umsetzung mit Hilfe des Scrum Frameworks gelingen kann und was dabei zu berücksichtigen ist, beschreibe ich im nachfolgenden Artikel.

Die Voraussetzungen schaffen

Bevor das Scrum-Team aus Product Owner, Entwicklern und Scrum Master mit der Entwicklung starten kann, müssen noch Voraussetzungen für wertvolle Feedbackschleifen geschaffen werden. Ziel ist es, Feedback, das der Wertsteigerung des Produkts dient, von den Stakeholdern zu erhalten.

Als erster Schritt hilft ein bedarfsgerechtes Training bei allen Beteiligten (Stakeholdern[2] und Scrum-Team), um Wissen zum agilen Vorgehen mit Scrum[3] und der Bedeutung von Feedbackschleifen aufzubauen. Daraus lassen sich wichtige Erkenntnisse gewinnen, z. B.

• Für eine agile Produktentwicklung wird ein Produktziel benötigt, an dem sich die Anforderungen ausrichten und auf das das Scrum-Team zur Wertsteigerung des Produktes hinarbeitet.
• Die Liste an Anforderungen wird in einem sogenannten Product Backlog beschrieben, welches kontinuierlich im Rahmen eines Backlog Refinements verfeinert wird. Dabei werden neue Einträge hinzugefügt, bestehende entfernt oder neu angeordnet.
• Die Stakeholder werden aktiv in den Entwicklungsprozess eingebunden, indem sie gemeinsam mit dem Scrum-Team ein Produktziel erarbeiten und mit Anforderungswünschen sowie Feedbackschleifen die Software ausgestalten.
• Die Definition of Done beschreibt das gemeinsame Verständnis der notwendigen Produktqualität für die Umsetzung der Anforderungen.

Es reicht jedoch erfahrungsgemäß nicht aus, nur die Theorie verstanden zu haben und Scrum mechanisch als Prozess zu implementieren. Denn die Einführung der neuen Rollen und Rituale führt nicht automatisch zu wertvollen Feedbackschleifen und einer wirkungsvollen Agilität.

Entscheidender ist es, ein gemeinsames Verständnis zu entwickeln, was sich von dem agilen Vorgehen erhofft wird (z. B. Verbesserung der Time-to-Market[4]) und an welchem Ziel sich bei der Softwareentwicklung orientiert wird. Denn Feedback unterstützt dabei, effektiv und effizient auf dieses Ziel hinzuarbeiten.[5]

Feedbackschleifen als Qualitätskatalysator

Zudem muss sich für wertvolle Feedbackschleifen eine förderliche Kultur etablieren. Die Feedbackkultur kann durch Glaubenssätze, Verhalten und Erfahrung gestaltet werden. Ein limitierender Glaubenssatz ist z. B.  „Wenn ich falsche Annahmen für die Softwareentwicklung treffe, hält mich das Team oder der Stakeholder für inkompetent.“, da für eine kontinuierliche Wertsteigerung des Produkts ein konstruktiver und positiver Umgang mit Fehlern notwendig ist.

Es ist davon auszugehen, dass die Arbeit an Glaubenssätzen ein begleitender Prozess innerhalb der Produktentwicklung ist.

Die Beantwortung folgender Fragen kann bereits im Vorfeld durch das Scrum Team erfolgen.

• Welches Ziel gibt uns bei der Softwareentwicklung Orientierung?
• Wobei hilft uns Feedback?
• Wer soll uns Feedback geben?
• Welche Art von Feedback brauchen wir?
• Wann sollen wir Feedback erhalten?
• Wie soll ein Feedback erfolgen?
• Wie gehen wir mit Feedback um?
• Wie priorisieren und bewerten wir Feedback?
• Welche Metriken können unseren Fortschritt messen?

Die befragten Aspekte sollen dabei unterstützen, den Sinn von Feedback zu verstehen, sich bei der Entwicklung an Zielen zu orientieren und Feedbackpraktiken mit den relevanten Stakeholdern zu etablieren. Relevant sind in diesem Fall die Endkunden, dessen Problem gelöst oder Bedürfnis erfüllt werden soll.

Es ist sinnvoll, zum späteren Zeitpunkt der Softwareentwicklung die gegebenen Antworten zu überprüfen und bei neuen Erkenntnissen anzupassen.

Kurze Feedbackschleifen etablieren

Das Scrum Framework definiert innerhalb des Sprints Events, in denen Feedbackpraktiken zum Überprüfen und Anpassen des Produktes und der Art der Zusammenarbeit möglich sind. Je größer die Unsicherheiten in der Produktentwicklung sind, desto sinnvoller sind kürzere Feedbackschleifen. Diese ermöglichen schnelleres Lernen und eine stärkere Risikokontrolle.  

Für den ersten Sprint muss das Product Backlog ausreichend verfeinert sein, da am Ende des Zyklus dem Kunden aus der ursprünglichen Idee Wert geliefert werden soll. Um zu überprüfen, ob das Software-Inkrement tatsächlich das Problem löst oder Bedürfnis erfüllt, erhält das Scrum-Team am Ende des Sprints Kundenfeedback.

Sprint Planning

Der Sprintzyklus startet mit einem Sprint Planning, in dem das Scrum-Team ein Ziel und einen Arbeitsplan für den kommenden Sprint erstellt. Das Ergebnis ist ein vollständiges Sprint Backlog.

Dazu werden gemeinsam folgende Fragen beantwortet:

• Welchen Wert erzeugt dieser Sprint?
• Was kann in diesem Sprint abgeschlossen werden?
• Wie wird die ausgewählte Arbeit erledigt?

Hinweis: Für ein wertvolles Feedback hilft es, sich als Scrum-Team bereits im Sprint Planning Gedanken zu machen, was und wie etwas im Sprint Review gezeigt werden kann.

Daily Scrum

Um sicherzustellen, dass am Ende des Sprints Wert geliefert wird, erfolgt ein Daily Scrum. In dieser Feedbackschleife auf täglicher Basis wird der Fortschritt in Richtung des Sprintziels überprüft und das Sprint Backlog an den aktuellen Kenntnisstand angepasst.

Hinweis: Für ein Stimmungsbild darüber, wie wahrscheinlich es ist das Sprint-Ziel zu erreichen, kann ein Daumen-Voting helfen (Daumen nach oben: es läuft nach Plan und wir müssen nichts anpassen oder Daumen nach unten: wir erreichen unser Ziel so nicht mehr und müssen etwas anpassen).

Sprint Review

Am Ende wird im Sprint Review mit den relevanten Stakeholdern die potenziell auslieferbare Version des Produkts überprüft. Wertvolles Feedback bekommt das Scrum-Team, wenn die Endkunden das Inkrement selbst ausprobieren können und nicht lediglich die Ergebnisse präsentiert werden.

Hinweis: Um das Feedbackgeben zum Überprüfen und Anpassen des Produkts zu unterstützen, helfen Skalenfragen, z. B. auf einer Skala von 0 bis 10: Wie viel hat das Sprintergebnis geholfen, sich der Produktvision zu nähern? Was hätte es für eine nächsthöhere Zahl gebraucht?

Retrospektive

Die Retrospektive fokussiert das Überprüfen und Anpassen der Art der Zusammenarbeit innerhalb des letzten Sprints. Das Event wird nach dem Review mit dem Scrum-Team durchgeführt, um konkrete Schritte zur Steigerung der Effektivität und Qualität für den nächsten Sprint zu planen.

Hinweis: Die Definition of Done soll einem regelmäßigen Verbesserungsprozess innerhalb der Retrospektive unterliegen. Aus den Erfahrungen des letzten Sprints und dem Feedback des Reviews lassen sich Anpassungen ableiten, wann eine Version des Produkts als potenziell auslieferbar gilt.

In Kürze zu dem Hintergrund des Themas

In der Softwareentwicklung ist es selten wirtschaftlich, im Vorfeld einen Plan für den gesamten Zeitraum der Entwicklung zu machen, da neue oder geänderte Anforderungen auftreten. Eine agile Vorgehensweise setzt den Fokus auf das Reagieren von Veränderung durch kurze und regelmäßige Feedbackschleifen. Dafür definiert das Scrum Framework sogenannte Events, die dem Überprüfen und Anpassen des Produkts und der Art der Zusammenarbeit dienen. Jedoch reicht es nicht aus, diese als Rituale einzuführen und zu erwarten, dass automatisch Feedback zur Wertsteigerung des Produkts erfolgt. Wesentliche Voraussetzungen sind, unter den Beteiligten ein Verständnis zu entwickeln, was das Ziel der agilen Softwareentwicklung ist, den Sinn von Feedback zu verstehen, eine Feedbackkultur zu etablieren und Feedback vom Endkunden zu erhalten.

Ich bedanke mich bei Ralf Kruse, Caroline Haussmann, Philipp Pelka, Stefan Roock, Sabine Canditt, Cordula Schuchardt, Stefan Post, Ralph Ehler und Maurice Ziola für eure Perspektiven sowie den Austausch zu dem Thema.

Mit Sicherheit gibt es noch weitere Möglichkeiten, kurze Feedbackschleifen zu etablieren oder eine andere Sicht auf das Thema. Ich freue mich auf eine Diskussion, um meine Perspektiven zu erweitern und weiter zu lernen.

[1] https://www.cio.de/a/projektmanagement-methoden-im-vergleich,3640284

[2] Siehe zur Analyse und Klassifizierung der Stakeholder https://agilescrumgroup.de/stakeholder-management-matrix-model/

[3] Siehe zum Scrum-Guide https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-German.pdf

[4] Siehe zur Auftragsklärung https://www.consist.de/de/unternehmen/blog/artikel/Wirkungsvolle-Agilitaet-mit-Scrum-Auftragsklaerung/

[5] https://agilescrumgroup.de/feedback-in-scrum/