Effiziente Backlogs

Reaktionsfähig bleiben in Startups und agilen Großprojekten

Was haben Startups und Großprojekte gemeinsam? Sie existieren in hochkomplexen Kontexten, also in Umfeldern, die von ständigem Wandel und Unsicherheit geprägt sind und daher längerfristige Planungen ad absurdum führen. Beide haben unterschiedliche Komplexitätstreiber (Schnelligkeit, Größe). Beide setzen auf agile Vorgehensweisen, um immerfort in der Lage zu sein, auf wechselnde Prioritäten zu reagieren. In beiden sehen wir immer wieder Product Owner und Teams, die mit ihren wild gewachsenen Backlogs kämpfen, welche ihnen zunehmend die Reaktionsfähigkeit rauben.
Eine durchdachte Aufbau- und Ablauforganisation rund um ein zentrales Product Backlog ist der wesentliche Erfolgsfaktor für reaktions- und lieferfähige Entwicklungsteams in hochkomplexen Kontexten.

Typische Fehlanwendung von Backlogs

In agilen Projekten sind Backlogs das Planungs- und Übersichtswerkzeug der Wahl. Laut Scrum Guide ist das Product Backlog eine „geordnete Liste von allem, von dem [aktuell] bekannt ist, dass es im Produkt enthalten sein soll.“
In diesem missverständlichen Sinne werden Backlogs meist falsch verwendet: zu oft betrachten wir die zu entwickelnden Produkte, Services oder Geschäftsprozesse als eine Sammlung von Features. Folglich degeneriert das dazu gehörige Product Backlog zu einer Liste von Systemeigenschaften, die zu erfüllen sind – also das, was man gemeinhin auch als Lastenheft bezeichnet.

Derartige Backlogs zeigen ein typisches Symptombild. Zum einen besitzen sie eine nicht mehr überschaubare Anzahl von Einträgen. Als situativer Workaround werden in Software-Tools wie JIRA gerne Filter erstellt, um kurzfristig (Über-)Sichten auf Teilmengen zu gewinnen. Zum anderen kommen mehr Einträge hinzu als das Entwicklungsteam abarbeiten kann (vgl. Abbildung 1). Ein Begleitsymptom von überhitztem Wachstum und „Lagerhaltung“ ist die Bindung von Ressourcen an den falschen Stellen der Wertschöpfungskette. Anders ausgedrückt, verbringen die Entwickler im Verhältnis zu ihrer Umsetzungsarbeit zu viel Zeit in Workshops für Refinements und Schätzungen.

Backlog
Abbildung 1

In der Konsequenz verlieren die Entwicklungsteams ihre Reaktions- und Lieferfähigkeit. Stakeholder werden ungeduldig und es kommt zu Kurswechseln in der Strategie. Bei einem solchen Kurswechsel, auch Pivot genannt, kommen neue Anforderungen dann im Schwall. Das Team muss dann die Umsetzungsarbeit meist ad hoc unterbrechen und die neuen Anforderungen verfeinern und schätzen. Das Team verliert den Fluss, fühlt sich getrieben und büßt Effizienz sowie Motivation ein.

Qualitätskriterien effizienter Backlogs

Zur Entschärfung dieser Symptome braucht es eine angemessene Struktur des Backlogs, die richtigen Inhalte sowie einen bewussten Umgang damit. Hierzu genügen keine allgemeinen Vorgaben von außen. Vielmehr ist es erfolgskritisch, dass das Team die im Folgenden näher vorgestellten Aspekte als Qualitätskriterien seiner Performance begreift. Product Owner und Entwicklungsteam müssen sich stetig und aus eigenem Antrieb um ein effizientes Backlog bemühen.
Konkret hat Accso hierzu in zahlreichen agilen Projekten erfolgreich eine Reihe von Leitplanken und Prinzipien eingesetzt. Diese Leitplanken und Prinzipien spiegeln sich im Modell des Product Backlog Canvas wider. (vgl. Abbildung 2).
Eine Vorlage in Din A0 für das Product Backlog finden sie hier->

Struktur

Zur Umsetzung selektieren Teams Backlog-Einträge, die klein genug und umsetzungsbereit („ready“) sind. In der Praxis sehen wir an der Spitze eindimensionaler Backlogs oft ein Gemenge aus selektierbaren Einträgen und solchen, die zu groß oder noch nicht ready sind. Ergänzen wir die Sortierung des Backlogs um den Reifegrad als zweite Dimension, erhält das Backlog eine bessere Übersichtlichkeit und es begünstigt das Prinzip „Voraus denken – auf Sicht fahren“. Dieses Prinzip trägt der Tatsache Rechnung, dass sich in einem Ein-Jahres-Zeitraum im Schnitt circa ein Drittel der Anforderungen ändern.

Inhalt

Neben Priorität und Reife unterscheiden sich die Einträge des Backlogs noch in der Größe, ihrem Detailgrad, ihrer Sichtweite (strategisch, taktisch, operativ) und ob sie fachlich oder technisch motiviert sind. Diese Unterscheidungen sind wichtig, denn sie helfen dem Team dabei, seine Ressourcen auf die richtigen Einträge und Aktivitäten zu fokussieren. Je näher der antizipierte Umsetzungszeitpunkt eines Backlog-Eintrags rückt, desto höher sollte dessen Detailgrad sein und desto kleiner im Sinne des Umsetzungsaufwands sollte er sein.
Gerade in großen Projektkontexten lohnt sich die Differenzierung nach Sichtweite. Das Scaled Agile Framework® (SAFe®) beispielsweise bezeichnet operative Elemente als „Story“, taktische als „Feature“ und strategische als „Epic“. Die Sichtweite eines Eintrags impliziert meist auch, welche Stakeholder an seiner Verfeinerung arbeiten. In der Regel ist es sinnvoll, nur kleine Zeitanteile der Entwickler auf die Besprechung strategischer und taktischer Einträge zu verwenden.

Umgang

Damit ein Team reaktions- und lieferfähig bleibt, muss es die Arbeit im Fluss halten. Product Owner und Teams sollten ihren Zeiteinsatz für die einzelnen Aktivitäten in der „Business Analyse“ explizit steuern. Der Product Owner muss Ideen und Anforderung explizit akzeptieren – oder ablehnen. Er tut jedoch gut daran, den Aufwand dafür klein zu halten. Das Team sollte wöchentlich einen fixen Zeitanteil in das Verfeinern von vagen, großen Einträgen stecken. Falls im Team
dedizierte Business Analysten arbeiten, können diese die Verfeinerung großer taktischer oder strategischer Themen übernehmen. Fachliche Einträge adressieren Pains und Gains konkreter Nutzerpersonas. Beim Pointieren sollte ein „Anforderer“ dem Entwickler den Bedarf so gut erklären, dass der Entwickler die User Story formulieren kann. Hierdurch entsteht automatisch Readiness und der Umsetzungsmotor kommt nicht bei der kleinsten Unklarheit ins Stottern. Falls Entwickler oder Architekten Anforderer sind, sollten sie ihre technischen Einträge (Qualitätskriterien, Enabler, etc.) dazu analog dem Product Owner erklären, sodass er den Nutzen versteht und den Aufwand kritisch hinterfragen kann.

Fazit

Unübersichtlichen Backlogs in hochkomplexen Projekten haben wir in der hier vorgestellten Weise umstrukturiert. Wir haben Teams methodisch beraten und situativ gecoacht und sie damit ertüchtigt, die richtigen Inhalte zur richtigen Zeit im richtigen Detailgrad mit den richtigen Personen zu verfeinern und zu pointieren. Im Ergebnis wurde nicht nur die Umsetzungsgeschwindigkeit gesteigert, sondern auch die Motivation im Team.