Vom glorifizierten Backlog zum Kundenerfolg

Das Backlog als süßes Gift der Antiagilität

“André, was ist die wichtigste Kompetenz eines Agile Coaches?”

Nach kurzem Überlegen sage ich: “Ist doch klar, gute Softwarekompetenz, idealerweise in Confluence oder Jira”.

Was sich aberwitzig liest, ist der Eindruck, den ich beim Lesen einiger Stellengesuche für Agile Coaches gewinne. Ich nenne es “das süße Gift der Antiagilität”. Und an diesem Gift leiden viele Organisationen und Teams. Es macht sie träge, uninspiriert und langsam. So langsam, dass große Vorhaben fast zum Erliegen kommen. Und an all den Problemen ist ein Stapel Holzscheite schuld: das Backlog!

Wie alles begann: das Holzscheit im Mittelalter

Wie begann das Backlog eigentlich?

In der ursprünglichen Bedeutung war das Backlog nichts anderes als die Holzscheite (das Holzscheit, engl. the Log), die im Hintergrund eines offenen Holzfeuers gestapelt wurden. Wenn das Feuer niederzubrennen drohte, gab es Nachschub über das Backlog. Das Backlog wurde also systematisch verbrannt.

Schauen wir, was der Scrum Guide dazu sagt: “In the simplest definition the Scrum Product Backlog is simply a list of all things that needs to be done within the project“. Das Backlog ist also nichts anderes, als eine vollständige Liste aller bekannten To-dos, die für die Erledigung eines Projekts erforderlich sind. Es ist eine glorifizierte To-do-Liste. Noch klarer formuliert es der Toolhersteller Atlassian:

The product backlog: your ultimate to-do list!

“Aber André, was ist denn jetzt an einer ultimativen To-do-Liste schlecht?”

Außer den Worten “ultimativ” und “To-do-Liste” nichts.

Das Backlog leidet an schwerer Adipositas

Eigentlich ist eine To-do-Liste etwas Wunderbares. Ich bin selbst großer Freund von To-do-Listen und ihrer reizvollen Schwester, der Checkliste. Nützliche Tools, die meinen Kunden und mir helfen, produktiv zu werden. Aber jede mir bekannte To-do-Liste, die nicht am Ende des Tages entsorgt wird, der große Soziologe Niklas Luhmann nennt es auch, das “Geschenk des Vergessens”, wächst. Und sie wächst und wächst. Und eines Tages wandert die Nadel des Body-Mass-Index (BMI) des Backlogs vom roten unwiderruflich in den dunkelroten Bereich. Das Backlog leidet an schwerer Adipositas und das Projekt bekommt im wahrsten Sinne des Wortes einen Infarkt. Es geht kaum noch etwas vorwärts.

Wir groomen, groomen, groomen im Sauseschritt

“Aber André, es gibt doch das Grooming! Das Grooming ist doch gut!”

Das Grooming bzw. Refinement hat die Aufgabe, “das Backlog aktuell zu halten”. Aktuell bedeutet, dass Irrelevantes entsorgt werden soll. Aber was ist irrelevant? Der ganze Prozess des Refinements erinnert mich an einen Messi, der etwas wegschmeißen soll. Er entscheidet sich für … nichts! Und das kann ich gut verstehen, denn alles war zu einem bestimmten Zeitpunkt aus einem unbekannten Grund einmal wichtig.

Auftritt der Hersteller: “Nutzt unsere Tools und alles wird gut!”

Das Backlog ist groß, das Backlog ist schwer, ein gutes Tool, das muss jetzt her. Und es gibt richtig gute Tools. Der Marktführer hat sein altes Ticketsystem zur Störungsbearbeitung im IT-Service Management so umgestaltet, dass es aussieht wie das allerschönste Kanban-Board. Es ist eine wunderschöne Fassade, die dennoch nicht verschleiert, was sich dahinter verbirgt. Es bleibt ein Ticketsystem. Und Ticketsysteme haben eine Eigenschaft, die für sie unabdingbar ist: Sie vergessen nichts. Das ist gut für die Störungsbearbeitung und sehr schlecht für die Kreativität.

Leider gilt auch: Tools machen ein fettes Backlog genauso agil, wie eine Rolltreppe Ihren sportlichen Treppenaufstieg ersetzt. Doch zurück zu unserem Holzscheit.

Das Holzscheit ruft: Muda, Mura und Muri

Warum ist das “Vergessen ein großes Geschenk”? Und warum war das Backlog im Mittelalter nicht so hoch wie der Turm von Pisa und wurde nicht täglich neu sortiert und inventarisiert?

Ganz einfach, weil das Backlog eine kolossale Verschwendung ist. Und nicht nur das, als große To-do-Liste erzeugt es auch eine immense kognitive Last. Es blockiert mit all seinen Einträgen das Denken, sodass es neue, einfache und kreative Lösungen schwer haben. Aus dem Product Owner wird der Facility Manager seines Ticketsystems.

Im Lean Management wird der Prozess rund um das Backlog als “Muda”, “Mura” und “Muri” bezeichnet. Diese “M & Ms” sind keine süßen Schokoladenbonbons, sondern die drei apokalyptischen Reiter der “Verschwendung”:

• Muda – Die ganze Arbeit rund um das Backlog hat keinen Kundenwert. Gar keinen! Ich kenne keinen Kunden, der ein Backlog, also eine Absichtserklärung, kauft.
• Mura – Das Refinement und Priorisieren sind  eine Arbeitsspirale, die nicht vom Kunden ausgelöst wird. Sie ist ein Ergebnis einer agilen Prozessmaschine und sorgt für Stress im Team und beeinflusst die Moral der Truppe negativ.
• Muri – Das Backlog ist hervorragend dafür geeignet, eine Pseudo-Produktivität zu messen. Wir messen einfach die Burn-Down-Rate. Oh, wie produktiv wir sind, und wenn wir noch härter arbeiten, dann sind wir noch produktiver. Das führt leider zur Überhitzung und Übermüdung, die manche Entwickler an Scrum & Co verzweifeln lassen.

Das Backlog ist nichts anderes als Verschwendung und Wasserfall im agilen Gewand. Während in der Wasserfall-Ära alle Tätigkeiten eins Projekts vorgeplant wurden, werden jetzt alle Tätigkeiten eines Projekts kontinuierlich umgeplant. Beides ist in einer komplexen Welt weitestgehend sinnlos, denn der Produkterfolg liegt ganz woanders, beim Kundenerfolg. Und dieser Kundenerfolg ist kein Bestandteil von agilen Methoden.

Meine Kritik am Backlog zusammengefasst

Jetzt meine Kritik in der Zusammenfassung, mal ganz ohne Holz. Das Backlog ist im Sinne des Lean Managements Verschwendung. Es verursacht hohe Lagerkosten, auch Opportunitätskosten genannt, weil es einen kontinuierlichen Verwaltungsprozess hervorruft.

Dieser Verwaltungsprozess wird nicht durch Anforderungen vom Kunden, sondern einzig aus der Methode oder das verwendete Framework – bspw. Scrum – ausgelöst. Das Team verliert sich in Details, während das Grooming als kontinuierliche Inventarisierung das Problem des Verwaltungsaufwands verschärft.

Ticketsysteme wiederum sind die falschen Werkzeuge, weil die Entsorgung unnützer Punkte im Backlog aufwändig und kaum durchsetzbar ist. Löschen von Tickets ist teuer!

Die Standish Group hat vor einiger Zeit eine Untersuchung bei 2.000 Softwareprodukten gemacht, wie viele der gelieferten Features wirklich genutzt wurden. Das Ergebnis war erschreckend: Satte 64 % aller Features wurden im Schnitt gar nicht oder kaum genutzt, aller agilen Arbeit zum Trotz.¹ Hier zeigt sich, dass der Glaube, dass eine Priorisierung über Business Value hilft, sich empirisch belegt als Irrglaube entpuppt.

Was wir benötigen, ist eine neue Arbeitsgrundlage. Und die heißt “Kundenerfolg”! Das, was den Kunden erfolgreich macht, das macht auch Ihr Produkt und Team erfolgreich. Leider ist der Kundenerfolg kein Bestandteil des Agilen Manifests. Und das ist sogar verständlich, denn die Herren, die vor 20 Jahren das Manifest zusammenstellten, hatten andere Probleme: Ihre Projekte brannten lichterloh.

“Und André, wie plant man Kundenerfolg?”

Von rechts nach links zum Kundenerfolg

Kundenerfolg erfordert etwas, was Mike Burrows als Denken von “rechts nach links” bezeichnet.² Statt vom Backlog, über Features bis hin zu Releases zu planen, wird die Denkrichtung gedreht. Überlegen Sie sich,

• was Ihre Kunden langfristig erfolgreich macht! Stichwort: Jobs to be Done.
• an welchem Verhalten Ihrer Kunden Sie dauerhaft erkennen, dass der Kunde erfolgreich ist! Stichwort: Nordstern Metrik.
• an welchem Nutzerverhalten Sie vorausschauend erkennen, wie akute Probleme gelöst und Chancen ergriffen werden! Stichwort: Outcome-Based Planning.
• mit welchen Features und Experimenten diese Outcomes gefördert werden könnten! Stichwort: Mini-Backlog.

An diesen Beispielen können Sie sehen, dass es grundsätzlich möglich ist, konsequent Kunden und ihren Erfolg in den Fokus zu nehmen. Velocity, Burn-Down-Rate oder das letzte Grooming sind nicht wirklich interessant. Stattdessen geht es darum, sofort und dauerhaft Wirkung zu erzielen und Kunden erfolgreich zu machen.

Mit dem Outcome-Based Planning zum Mini-Backlog

Mein Vorschlag: Nutzen Sie Ihr Backlog als Ideenliste und wenden Sie sich dem Outcome-Based Planning zu.

Beim Outcome-Based Planning werden nur die wichtigsten Outcomes geplant. Aber was ist ein Outcome? Gerne nutze ich die Definition von Joshua Seiden³:

Ein Outcome ist eine Verhaltensänderung von Kunden, Nutzern, Menschen, die zu dem langfristigen Produkterfolg (Nordstern) beitragen.

Outcome-Based Planning bedeutet, dass an Stelle des vollständigen Backlogs die nächsten Outcomes geplant werden, die zum Kundenerfolg führen.

Beispiel:

Wir merken, dass die Abbruchrate der Customer Journey für die Erstanmeldung an unsere digitale Plattform viel zu hoch ist. Die Kunden werfen viel zu früh das Handtuch.

Statt User Storys oder Features zu planen, reicht es, das gewünschte Kundenverhalten zu planen:

Wir reduzieren die Abbruchrate bei der Erstanmeldung von 30 % auf 15 %.

Beim Outcome-Based Planning wird eine Roadmap der wichtigsten Outcomes erstellt. Die Roadmap besteht nicht aus Features, nicht aus Epics, nicht aus Meilensteinen, sondern aus gewünschten Nutzerverhalten. Ein Backlog gibt es weiterhin, aber nur für die Ideen zur Erzielung der nächsten Outcomes im nächsten Supersprint, beispielsweise 2-4 Monate. Danach wird ein neues leeres Backlog aufgemacht.⁴

Fazit

“Gut André, ich habe verstanden. Das Backlog kann, wenn es zu groß wird, zu einer Belastung werden. Es ist unerledigte Arbeit im System, was im Lean-Management als Verschwendung bezeichnet wird. Die dauernde Beschäftigung mit dem Backlog kostet viel Zeit, während wir total im Unklaren bleiben, was den Produkterfolg wirklich ausmacht!”

Das Backlog war eine gute Idee, als die Projekte noch klein und schnuckelig waren. Heute reden wir nicht über Projekte, sondern über Produkte und digitale Plattformen. Es gewinnen nicht die Markteilnehmer, die am schnellsten neue Features produzieren, es gewinnt, wer seine Kunden erfolgreich macht. Dazu ist es wichtiger, sich mit den Jobs des Kunden zu beschäftigen und sich in der Planung auf die Outcomes zu konzentrieren. User Storys und To-dos bleiben wichtig, aber in einem schmalen und überschaubaren Mini-Backlog. Genauso klein und nützlich, wie es der Holzstapel neben dem offenen Feuer im Mittelalter war.

Hinweise:

[1] David Rice: Why 45 % of all software features in production are NEVER used.
[2] Mike Burrows: Right – Left. Der Leitfaden zu Lean and Agile für Digital Leader.
[3] Josuha Seiden: Outcomes Over Output. Why customer behavior is the key metric for business success.
[4] Zur Umsetzung des Outcome-Based Plannings bietet sich das Framework Objectives & Key Results an.

Wenn Ihnen der Beitrag gefällt oder Sie darüber diskutieren wollen, teilen Sie ihn gerne in Ihrem Netzwerk. Und falls Sie sich für weitere Tipps aus der Praxis interessieren, dann testen Sie gerne unseren wöchentlichen Newsletter mit neuen Beiträgen, Downloads, Empfehlungen und aktuellem Wissen. Vielleicht wird er auch Ihr Lieblings-Newsletter!

André Claaßen hat im t2informatik Blog weitere Beiträge veröffentlicht, u. a.

Was macht eigentlich t2informatik? Ein Klick hier und Sie wissen es.