Agile Transformation Backlog

Wenn du diesen Artikel liest, ist deine Organisation vielleicht gerade mitten in einer agilen Transformation oder möchte diese durchführen. Egal ob deine Transformation auf Scrum, Kanban, SAFe oder einer Kombination davon basiert, hoffentlich hast du deine Due Diligence gemacht und hast die Rechtfertigung und die Daten, um die Transformation zu unterstützen. Dies ist kein Schritt, den du ignorieren solltest. Alle Tipps der Welt werden den Erfolg nicht sicherstellen, wenn du nicht einen Business Case entwickelt hast, der auf realistischen Erwartungen bezüglich der Kosten und Vorteilen von Agile basiert.

Das heißt, der nächste Schritt in einer Transformation sollte die Bestimmung der Lücken zwischen dem IST-Zustand und dem SOLL-Zustand sein. Diese Liste von Lücken, Unterschieden und Veränderungen zu deinem Business-as-usual-Modell wird eine lange Liste von Aktionen und To-Do-Elementen erzeugen.

Das Transformation Board

(siehe auch hier)

Anstatt dass das Product Backlog eine Liste von Features, Epics, Stories oder Bugs ist, werden die Aktionen und To-Dos, die aus der Gap-Analyse kamen, einfach als „Work Items“ aufgeführt. In der Fallstudie wurde ich als Berater hinzugezogen und hielt ein paar Workshops ab, um die Gap-Analyse durchzuführen. Hier ein paar häufig auftretenden Items:

SAFe Orientierung für das Management
Teams neu ausrichten
Communities of Practice und Zünfte schaffen
Bootcamp-Training für geschäftliche und technische Teammitglieder
Rollenspezifisches Training (z.B. Coder, Tester, Business Analyst)
Definieren von Geschäftswert und Wertströmen
Definiere, generiere und nutze Metriken und KPIs
Definiere ein konsistentes Sizing Format
Shared Services einrichten
Co-Located Arbeitsumgebungen schaffen
Anpassen von Titeln, Rollen und Stellenbeschreibungen
Backfill-Positionen basierend auf neuen Rollen (z.B. Release Train Engineer, Product Owner)
Einrichten von laufendem Coaching und Mentoring für neue Scrum Master
Erstellen eines funktionsübergreifenden Trainingsframeworks
Aufbau einer agil ausgerichteten DevOps-Umgebung
Erstellen einer Testautomatisierungsstrategie
Alte Zeremonien auflösen
Neue Zeremonien einführen (z.B. Program Increment Planning, Scrum of Scrum)

Diese Liste wird von Organisation zu Organisation variieren. Die Arbeitselemente werden auf allen Ebenen zu finden sein – Team, Programm und Portfolio. Viele der oben aufgelisteten Punkte sind Epics und müssen in kleinere Inkremente heruntergebrochen werden.

Verwaltung durch Transformation Owner

Das Verwalten des Agile Transformation Backlogs erlaubt es dem Team, das die Transformation beaufsichtigt, auch agile Prinzipien zu praktizieren. Ich verwende oft einige der Sprint-Zeremonien, um effektiv zu kommunizieren. Wir haben tägliche Stand Ups mit dem Kernteam der Transformation abgehalten und am Ende der Woche wurde ein Show-and-Tell-Call für jeden angesetzt, der sich einwählen und über den Fortschritt und die Ziele für die kommenden Wochen hören wollte. Hinweis: Viele Workitems benötigen keine Sprintkadenz, du musst also nicht auf das Ende eines Sprints warten, um sie zu liefern.

Darstellung

Wie bei allen Backlogs ist der größte Wert die visuelle Darstellung der Arbeit und die Transparenz. Jeder kann dem Backlog etwas hinzufügen. Dies ermöglicht es dir, alle Bedenken, Hindernisse oder Hürden zu erfassen, an die das Kernteam der Transformation vielleicht nicht gedacht hat. Es war tatsächlich ein Teammitglied, das zuerst eine Transformations-Retrospektive vorschlug, also haben wir ein Workitem erstellt, und jetzt ist es ein fester Bestandteil des Backlogs. Am Ende eines Sprint-Zyklus lassen wir diejenigen, die von der Transformation betroffen sind, darüber sprechen, was funktioniert und was nicht funktioniert. Das Transformation Board soll allen gehören, nicht nur dem Team, das die Transformation koordiniert.

Top-Down?

Eine Agile Transformation sollte sich nicht wie eine Top-Down-Implementierung anfühlen. Oft kommt der Katalysator für Veränderungen rund um Agile von unten nach oben. Das Transformation Board ist ein großartiges Werkzeug, um die Teams die Prioritäten des Backlogs bestimmen zu lassen.

Anpassungen müssen vorgenommen werden

Wenn du an einem Transformations-Workitem arbeitest, ist eine der wichtigsten Anpassungen, die du vornehmen musst, das typische „Design, Code, Test und Deploy“-Modell durch Schritte zu ersetzen, die traditionell mit kontinuierlicher Verbesserung verbunden sind. Die Aufgaben, die mit den Transformationsaufgaben verbunden sind, werden sich an Six Sigma orientieren. Für jedes Workitem willst du:

Definiere den Arbeitsschritt mit dem Ergebnis und dem Wert im Hinterkopf.
Identifiziere die Messung des Erfolgs. (Dies ist das „So That“-Element in den User Stories.)
Analysiere und lege deine IST-Metriken fest, damit du etwas hast, mit dem du vergleichen kannst, wenn du feststellst, ob die Veränderung erfolgreich war.
Implementiere die Verbesserungen.
Gib ihnen ausreichend Zeit (z.B. zwei oder drei Sprints), um zu sehen, ob sie einen Mehrwert bringen und ihren Zweck erfüllen.
Kontrolle durch Checkpoints und gemeinsame Verantwortlichkeit. Manchmal ist es ohne Verantwortlichkeit einfach, in schlechte Gewohnheiten und Verhaltensweisen zurückzufallen.
Hier sind ein paar Tipps und Merkmale eines Product Backlogs, die du für dein Transformation Backlog Framework nutzen kannst:
Definiere das Workitem mit dem Ergebnis und dem Wert im Hinterkopf.
Identifiziere die Messung des Erfolgs. (Dies ist das „So That“-Element in User Stories.)
Analysiere und lege deine AS IS Metriken fest, damit du etwas zum Vergleich hast, wenn du feststellst, ob die Änderung erfolgreich war.
Implementiere die Verbesserungen.
Gib ihnen ausreichend Zeit (z.B. zwei oder drei Sprints), um zu sehen, ob sie einen Mehrwert bringen und ihren Zweck erfüllen.
Kontrolle durch Checkpoints und gemeinsame Verantwortlichkeit. Manchmal ist es ohne Verantwortlichkeit einfach, in schlechte Gewohnheiten und Verhaltensweisen zurückzufallen.

Tipps

Außerdem gibt es hier ein paar Tipps eines Product Backlogs, die du für dein Transformation Backlog Framework nutzen kannst:

Ein Product Backlog ist eine Liste der neuen Elemente oder Änderungen an Elementen.
Das Product Backlog ist die Quelle für Dinge, an denen die Stakeholder der Transformation arbeiten werden.
Items im Backlog sind Platzhalter, bis sie an die Spitze der Liste priorisiert werden. Einige Punkte werden es vielleicht nie an die Spitze der Liste schaffen.
Jeder kann Elemente zum Backlog hinzufügen.
Von Zeit zu Zeit können sich die Stakeholder darauf einigen, Elemente aus dem Backlog zu entfernen.
Die Stakeholder der Transformation können über das Format der Punkte im Backlog entscheiden.
Wenn ein Punkt bearbeitet werden soll, sollten ausreichend Details zur Verfügung gestellt werden, um das richtige Ergebnis und die richtige Lösung zu gewährleisten (z.B. Akzeptanzkriterien, Szenarien und/oder Beispiele).
Die zu bearbeitenden Punkte sollten in Inkremente aufgeteilt werden.
Der Product Owner (mit dem Rat und Input des Teams/der Stakeholder) sollte das Backlog regelmäßig priorisieren und in eine Reihenfolge bringen.
Jedes Workitem sollte einen Owner/Lead haben.
Das Ergebnis der Arbeit an einem Workitem sollte den Stakeholdern gezeigt werden, damit sie zustimmen können, ob es den Zweck des Workitems erfüllt.

Das Team ist Eigentümer des Backlogs und sollte sich auf eine Person einigen, die als Product Owner für die Transformation bestimmt wird. Diese Person wird als Entscheidungsträger oder Stellvertreter der Person, die die Transformation finanziert, am meisten für das Ergebnis verantwortlich sein.

Sichtbarkeit

Das Product Backlog kann in physischer Form mit Hilfe von Karteikarten oder Haftnotizen dargestellt werden, oder es kann in elektronischer Form wie einer Textdatei, einer Tabellenkalkulation oder einem der vielen Backlog Management Tools, die es gibt, dargestellt werden. Elektronische Tafeln sind eine gute Option für ein Team, das aus entfernten Mitgliedern besteht. Aber wenn möglich, bevorzuge ich immer noch physische Boards, weil sie den Vorteil bieten, das Product Backlog während der Diskussionen kontinuierlich sichtbar und greifbar zu machen.

Ein Transformations-Backlog kann ein effektiver Weg für ein Team sein, um zu kommunizieren, woran sie gerade arbeiten und was sie als nächstes planen. Der wertvollste Aspekt des Transformations-Backlogs ist, dass es allen Teams erlaubt, den laufenden Fortschritt zu sehen. Auch Stakeholder und Teammitglieder können sich das Backlog ansehen und sehen, dass ihre Ideen und Vorschläge berücksichtigt werden.

Kontinuierlicher Zyklus

Denke daran, es ist ein kontinuierlicher Zyklus und einige Änderungen werden nicht perfekt sein, aber bei Agile geht es um „schnelles Lernen“. Einige Workitems sind Lernerfahrungen, die unweigerlich weitere Workitems generieren werden. Dein Ziel ist es nicht, ein leeres Backlog zu haben, damit du die Transformation für erledigt erklären kannst. Die agile Umgebung ist eine kontinuierliche Lernumgebung und die agile Industrie als Ganzes reift und entwickelt sich immer weiter. Dein Backlog kann kleiner werden und die tägliche oder sogar 2-wöchige Kadenz ist vielleicht nicht notwendig, aber plane 16 – 24 Monate für eine komplette Agile Mindset Transformation ein. Natürlich gibt es auch viel kürzere Transformationen, aber aus Erfahrung kann ich sagen, je größer die Investition, desto größer die Auszahlung.