Teil 1 aus der Praxis-Serie „Hinter den agilen Kulissen“ – Ein- und Ausblicke für die agilen Profis von heute und morgen. In der 5-teiligen Blog-Artikel-Reihe geht es um zentrale Werkzeuge und Denkmodelle agiler Arbeit.
Das agile Framework
Sicher kennt die oder der geneigte Lesende den Begriff „Selbstorganisation“. Es ist ein Modebegriff, der gut zu den Ideen neuer, weniger hierarchischer Führungssysteme passt. Was viele in der Benutzung übersehen: Selbstorganisation bedeutet streng genommen Selbstüberlassung. Das System wird von den Elementen des Systems selbst gestaltet, also nicht fremdorganisiert.
Wenn man das im System Unternehmen ernst nimmt, hat das radikale Auswirkungen zum einen auf die Führung der Organisation, zum anderen auf die Art, was Teams und Mitarbeitende leisten müssen, um ihre Zusammenarbeit weiter funktionieren zu lassen. Das Ergebnis in den meisten Organisationen ist eine Balance aus rahmengebenden Maßnahmen der Führungskräfte und mehr Verantwortungsübernahme der Mitarbeitenden. Selbstorganisation, das wird schnell klar, ist ein hoher Anspruch.
Ein ähnliches Spannungsfeld tut sich für manch eine:n Einsteiger:in in die agile Welt auf. „Agil“, so hört man nach den ersten Stunden der Beschäftigung mit Scrum & Co., „das soll uns doch freier machen. Weg vom Arbeiten nach der Wasserfall-Methode, schneller, flexibler. Warum gibt es dann ein so detailliertes Framework für agiles Arbeiten?“
Beispielhaft für diese Fragestellung steht der „Agile Backlog“, eins der zentralen Tools im agilen Werkzeugkasten. Auf viele Dinge, das werden einem erfahrene Agile-Profis bestätigen, könnte man verzichten, auf irgendeine Art von Backlog nicht. Der Backlog, so würde man auf Englisch sagen „is the backbone of agile problem solving.“
Was ist das Agile Backlog?
Der Backlog oder auch Product Backlog ist die Liste aller Aufgaben, Funktionen und Elemente, die erledigt werden müssen, um das Ziel des Projekts zu erreichen. Diese vom Team laufend aktualisierte ToDo-Liste hat vor allem zwei Aufgaben: Den Überblick über das Projekt zu behalten (anders formuliert: Das auf dem Weg nichts verloren geht) und die Aufgaben zu priorisieren.
Agile Teams haben die Aufgabe, ein Produkt zu erstellen und dieses im Laufe eines Projekts immer weiterzuentwickeln. Agiles Projektmanagement unterscheidet sich von traditionellem Projektmanagement dadurch, dass es keinen in Stein gemeißelten Projektplan gibt. Das heißt aber auf keinen Fall, dass es keinen Plan gibt. Auch gibt es eine klare Vorstellung von der Lösung, der Weg dorthin ist aber nicht festgelegt. Er entsteht in einem ständigen Wechsel von Entwicklung, Beobachtung und Anpassung.
Der Backlog als agile ToDo-Liste spiegelt dieses „Mitgehen mit dem Problem“: Tauchen auf dem Weg der Entwicklung neue, unerwartete Herausforderungen auf, so werden die nächsten Entwicklungsschritte neu bewertet, es entsteht ein neuer Wegabschnitt.
Nun lautet eines der Prinzipien des Agilen Manifests aus dem Jahre 2001, dass „funktionierende Software wichtiger ist als umfassende Dokumentation“. Damit wollten die Pioniere der agilen Bewegung aber nicht sagen, dass der laufende Arbeitsprozess gänzlich sich selbst überlassen werden kann.
Insbesondere die Arbeit in Teams braucht Antworten auf die Fragen: Wer macht was und in welcher Reihenfolge. Dies und noch einiges mehr beantwortet ein gut gepflegter Product Backlog.
Wie funktioniert ein Agile Backlog?
Üblicherweise werden in einem Backlog vier Kategorien von Informationen erfasst:
- Eigenschaften (engl. features)
- Fehlerbehebungen (engl. bug fixes)
- Technische Schulden (engl. technical debt)
- Erworbenes Wissen (engl. acquired knowledge)
Diese Elemente sind im Backlog immer an eine konkrete User Story, eine für die Kunden wertvolle Funktion geknüpft. Diese Story dient vor allem dazu, den Entwickler:innen ein klares Bild der Funktion und des damit verbundenen Kundennutzens zu vermitteln ohne die Lösung zu diktieren.
Die Product Features sind die Produkt-Elemente, die zur Erfüllung der jeweiligen Funktion zwingend notwendig sind und aus der sich unmittelbar Entwicklungsaufgaben ergeben.
Fehler passieren selbst dem besten Entwickler:innen-Team. Weil „Bugs“ allerdings den Wert des Produkts und damit die Kundenzufriedenheit unmittelbar negativ beeinflussen, kann es sinnvoll sein, einen „Bug Fix“ im Backlog deutlich höher zu priorisieren. Was auch bedeuten kann, dass das Team einen aktuellen Sprint unterbrechen muss. Empfehlenswert ist, die erkannten Fehler im Product Backlog weit oben zu platzieren, damit sie auf keinen Fall in Vergessenheit geraten.
Wenn wir von „Technischen Schulden“ reden, dann meinen wir unbearbeitete Aufgaben im Backlog. Ähnlich wie bei finanziellen Schulden, bedeutet das Ignorieren höhere Kosten, sprich: Zinsen. Wenn also bestimmte Aufgaben im Backlog immer weiter nach unten rutschen, wird es immer schwieriger, sie abzuarbeiten. Genau dazu gibt es aber den Backlog: Dass es keinen Aufgabenstau oder vergessene ToDos gibt.
Schließlich noch ein Blick auf die vierte Kategorie von Informationen im Backlog, das erworbene Wissen. Sinn und Zweck dieser laufenden Notizen im Backlog, ist die Sammlung und das Teilen von Informationen, die das Team für die Erledigung zukünftiger Aufgaben benötigt. In der Praxis könnte sich daraus eine Recherche, ein Protoyp oder ein Proof of Concept ergeben, das dem Scrum-Team dabei hilft, bessere Entscheidungen zu treffen.
Das Backlog ist das zentrale Steuerungselement des Product Owners. Die Verantwortung des Backlogs liegen somit beim Product Owner. Diese komplexe Aufgabe beinhaltet unter anderem die Pflege des Backlogs, das Einbringen oder Ablehnen der Stakeholder-Anforderungen, des Festlegen der Prioritäten und der Abgleich mit der Produktvision ab. Ein gekonnter Umgang mit dem Backlog bedarf viel Erfahrung und Weiterbildung.
Wie bauen Product Owner den Backlog?
Grundlage eines Backlogs ist die Product Roadmap, ein Fahrplan, der die Veränderung des Produkts im Laufe des Entwicklungsprozesses auf übergeordneter Ebene beschreibt. Er vermittelt die langfristige Vision für die Produktentwicklung, was nicht heißt, dass er im Laufe der Zeit an aktuelle Entwicklungen angepasst werden kann.
Auf Basis der Roadmap können Team-Mitglieder nun alle Einträge für den Product Backlog auflisten. Es kann sich anfangs um sehr konkrete, dringliche, aber auch eher abstrakte Ideen handeln. Der Austausch mit allen Beteiligten des Projekts ist hier unbedingt notwendig, um sicherzustellen, dass alle notwendigen Produkteigenschaften mit in die Entwicklung einbezogen werden.
Nach der Erfassung der Einträge gilt es, diese zu sortieren und zu priorisieren. Die wichtigste Frage bei der Priorisierung sollte immer lauten: Wo schaffen wir den größten Kundennutzen?
Der Backlog ist ein lebendiges Dokument, das zwingend von allen Team-Mitgliedern genutzt und laufend aktualisiert wird. Dementsprechend müssen auch die Priorisierungen der Aufgaben immer wieder vom Product Owners angepasst werden. Am Ende dieser laufenden Koordinationsarbeit steht das Festlegen der nächsten Entwicklungs-Etappe, in der agilen Welt „Sprint“ genannt.
Warum brauchen Product Owner den Backlog?
Ein Product Backlog verbessert die Organisation und Zusammenarbeit im agilen Team. Es ist das zentrale Werkzeug zur Verwaltung und Abstimmung der Arbeit, in Kombination mit einem Multi-Channel-Messenger (wie z.B. Slack) bildet es auch das kommunikative Rückgrat der Entwicklung.
Das Prinzip des iterativen Arbeitens, d.h. des Verzichtens auf einen fixen, komplett ausgearbeiteten Plan zugunsten von kleinen, zeitlich limitierten Arbeitspaketen, wäre ohne die Orientierung eines Backlogs schlicht und einfach nicht möglich.
Die Team-Mitglieder sind selbst verantwortlich für die Erledigung ihrer Aufgaben, denn nur sie können wirklich beurteilen, welche Aufgabe wie anspruchsvoll ist. Es entsteht im besten Fall eine Mannschaft aus selbstorganisierten Höchstleister:innen, die laufend und ohne Überlastung zu einem besseren Produkt beitragen.
Fazit
Das Backlog ist ein wichtiges Steuerungselement für Product Owner, welches die Pflege, Priorisierung und Abstimmung von Aufgaben und Anforderungen einer Produktentwicklung ermöglicht. Es ist ein lebendiges Dokument, das laufend von allen Team-Mitgliedern genutzt und aktualisiert wird und dient vor allem dem Überblick über Projekte und der Aufgabenpriorisierung.
Hier lesen Sie Teil 2 aus der Praxis-Serie „Hinter den agilen Kulissen“
Stakeholder managen und Teams führenHier lesen Sie Teil 3 aus der Praxis-Serie „Hinter den agilen Kulissen“
Businessstrategien für Product OwnerHier lesen Sie Teil 4 aus der Praxis-Serie „Hinter den agilen Kulissen“
Kundenfokussierte Product Owner: Data-und UX-Profis
