3 Gründe wieso „Liefern“ das Backlog-Management schlägt

Beim disziplinierten Anwenden agiler Frameworks verschaffen wir uns gegenüber dem klassischen sequentiellen Vorgehen einen Vorsprung: Das iterative und inkrementelle Liefern hat bereits begonnen, während andere noch Grob- und Feinkonzepte schreiben. Teams, die das verstehen, nehmen gehörig an Liefergeschwindigkeit auf. Das zentrale Artefakt ist dabei das Backlog.

Wozu brauchen wir das Backlog nochmal?

Doch das Backlog-Management kostet Zeit. Was also tun, wenn die agile Technokratie zunimmt und das Backlog zum Verwaltungsgegenstand eines ganzen Teams wird? Was wenn der Product Owner mehr Zeit auf die Pflege des Backlogs verwendet, als sich über Entwicklungen am Zielmarkt, die Rahmenbedingungen des Produktes oder gelungene Stakeholder-Kommunikation Gedanken zu machen?An diesem Punkt ist es an der Zeit, noch stärker vom Kunden her zu denken. Denn das Problem eines ausufernden Backlog-Managements kann durch den Fokus auf die bloße Lieferung des Teams gelöst werdenGehen wir einen Schritt zurück: Was ist eigentlich ein Backlog? Ein Backlog wird verstanden als eine Liste von Produktfeatures, die es als Nächstes zu entwickeln gilt. Und es soll dem Team dabei helfen, dass

1. mögliche neue Features vor der Entwicklung durch das Team gesammelt und fortlaufend priorisiert werden können;
2. im Entwicklungsprozess fortlaufend der höchste Kundenwert generiert wird;
3. das Team weiß, was es als nächstes liefern soll.

Wenn das die drei wichtigsten Akzeptanzkritierien für das Backlog sind, dann stellt sich die Frage: Lassen sich diese nicht auch mit einem anderen Mittel erfüllen?Meine Antwort darauf lautet: Ja, das lässt sich machen! Das Mittel zum Zweck heißt „liefern“!Denn:

1. Liefern repriorisiert – und zwar gnadenlos

„Kein Plan überlebt den ersten Kundenkontakt.“ Dieses militärisch entlehnte Credo ist in der heutigen Businesswelt so wahr wie noch nie. Wer im Laufe eines Sprints nicht das Backlog für den kommenden Sprint repriorisieren muss, kann sich über eine sehr stabile Umgebung freuen. Aber das kommt sehr selten vor. Wozu also die Mühe des Priorisierens, wenn sich nach dem Review wieder so vieles ändert? Hochprofessionelle Scrum-Teams sparen diese Energie und verzichten einfach auf ein Backlog. Sie entwickeln, was gerade gebraucht wird. Sie demonstrieren es dem User, greifen sein Feedback auf und lernen daraus.

2. Liefern lässt den Kunden erst erkennen, welchen Wert das Produkt wirklich für ihn hat

Das Backlog ist nur ein Vehikel, um Wert zu generieren – es ist nicht der Wert selbst. Mit dem Backlog wird ein Bild davon gezeichnet, wie sich das Produkt entwickeln wird, was wichtig ist usw. Schlussendlich bleiben Backlog-Einträge aber nur Hypothesen, bis der Kunde sie einmal erlebt und den Nutzen der dahinterliegenden Funktionalität bestätigt hat. Wir müssen uns also bewusst machen, dass es sich beim Backlog um Annahmen handelt, die priorisiert und gemanagt werden. Die Diskussionen über Schätzungen und Business Value erzeugen für den Kunden noch keinen Wert. Es ist also gut investierte Zeit, wenn das Team mehr Zeit für das „echte“ Liefern hat, statt Stellvertreter-Diskussionen um Backlog-Einträge führen zu müssen. Realen Kundenwert schaffen – das ist das Ziel.

3. Liefern erzeugt-Feedback und damit Orientierung

Product Owner und Teams können sich ausufernd damit beschäftigen, eine User Story „richtig“ zu formulieren, das Bedürfnis des Kunden zu verstehen oder das Backlog so zu priorisieren, dass jeder Entwickler es sofort versteht. ODER: Das Team liefert dem User so schnell wie möglich das, was er als Nächstes braucht. Und zwar nicht, weil er gerade eine Idee hatte, sondern weil er bei der Nutzung des aktuellen Produktes einen wahren Bedarf erkennt. Für Kritiker wie Henry Ford sei hier ergänzt: Selbst wenn der Kunde es nicht selbst erkennt, so machen es moderne Methoden des UX-Designs (z.B. Tracking von Augenbewegungen) möglich, viele schneller zu erkennen, was der Kunde tatsächlich braucht. Das spart Analyseaufwand, Kommunikationsaufwand und Abstimmungsbedarf für die Backlog-Definition. In der gewonnenen Zeit kann das Team wieder etwas Sinnvolles liefern.

Was können wir daraus lernen?

Je nach Umgebung kann ein Backlog ein wertvolles Tool sein, es sollte sich aber niemand darin verlieren. Der Fokus agiler Methoden ist und bleibt das Liefern. Wenn das Backlog dabei hilft: Nutzen Sie es. Ist der der Aufwand höher als der Nutzen und gibt es genügend agile Expertise, um das beurteilen zu können, darf dieses Artefakt auch in Frage gestellt werden.Foto: pixabay license