Kolumne: Groß und (fr)agil?

Wie sich Agilität skalieren lässt: One Product-Owner to rule them all…?

Christoph Niemann, Timo Becker

(c) Shutterstock / eelnosiva

Mit diesem Beitrag starten Christoph Niemann und Timo Becker in ihre neue JAXenter-Kolumne: „Groß und (fr)agil?“ Sie erhalten handfeste Tipps aus der Praxis, wie sich Agilität auch in großem Maßstab betreiben lässt, ganz nach dem Motto: Groß und agil – das muss kein Widerspruch sein!

Groß und (fr)agil?

Vielleicht kennen Sie die Situation: Man startet agil und alles läuft gut – bis das Team wächst und das Produkt von mehreren Scrum-Teams entwickelt wird. Schnell steht der agile Protagonist auf unbekanntem Terrain: Wie skalieren Product-Owner, Aufgabenverteilung und teamübergreifende Abstimmungen? In dieser neuen Kolumne wollen wir erprobte Lösungspraktiken und Patterns aus bekannten Skalierungs-Frameworks aufzeigen.

Die hier vorgestellten Bausteine sind leichtgewichtig und verringern Reibungsverluste auf dem Weg zum großen agilen Projekt. Sie können sie schon mit zwei Teams einsetzen. Sobald einfache Patterns nicht mehr ausreichen, lohnt sich der Blick auf vollwertige Skalierungsframeworks.

Heute geht es um den Product-Owner und das Product Backlog: Wie liefert ein einzelner Product-Owner mehreren Teams zuverlässig Anforderungen und User-Storys? Und wie viele Backlogs dürfen es bei mehreren Teams werden? Meine Antwort auf die erste Frage ist denkbar einfach:

One Product-Owner to rule them all…

Der Arbeitsumfang des Product-Owner (PO) wächst mit dem Entwicklungsaufwand für Produkt oder Anwendung: Je mehr Teams an seinem Produkt mitentwickeln, desto mehr User-Stories schneidet, entwickelt, priorisiert und nimmt er ab. Mit zwei Scrum-Teams funktioniert das in der Regel noch. Mit steigender Anzahl von Teams steigt die Last auf den PO. Schnell kann ein einzelner PO nicht mehr alle User-Stories schneiden und schreiben, das Product Backlog pflegen und priorisieren, und alle umgesetzten Storys in Reviews mit dem Team abnehmen. Wir haben unterschiedliche Erfahrungen gemacht, ab wie vielen Teams das der Fall ist. Es hängt stark von den Teams ab: Wenn das Scrum-Vorgehen noch relativ neu ist, können schon drei Teams zu viel für einen PO sein, bei eingespielten Teams kann ein PO möglicherweise auch fünf Teams „bedienen“.

Wenn sich die Überlastung ankündigt, ist der erste Impuls, einen PO pro Feature-Team zu etablieren. Damit sind wieder genügend User Stories für alle Teams formuliert. Im Gegenzug geht die zentrale Entscheidungsinstanz verloren. In der PO-Gruppe kann es erfahrungsgemäß schnell Konflikte über die Entwicklung und Priorisierung der User-Stories geben. Deswegen gilt für den PO immer das Highlander-Prinzip: „Es kann nur einen geben.“

Sinnvoller finde ich es, den PO durch Delegation von Aufgaben in das Team zu entlasten. Statt ausgearbeiteten User-Storys legt der PO beispielsweise nur eine kurze, informelle Beschreibung der Anforderungen vor. Ein Teammitglied arbeitet eine User-Story mit dazugehörigen Akzeptanzkriterien aus. Das Teammitglied ist dabei explizit nicht festgelegt, sondern die Aufgabe wechselt zwischen den Teammitgliedern. Sie machen das in der Zeit, die in Scrum für Arbeiten außerhalb der Entwicklung vorgesehen ist. Mit Rückfragen wenden sich die Bearbeiter direkt an den Kunden. Spätestens im Planning überprüft der PO die spezifizierte User Story final. Trifft die Story den Kerngedanken nicht, detailliert der PO sie im Gespräch und weist sie zur Überarbeitung zurück. Das Ergebnis dieser Maßnahme: Der PO wird entlastet und die Teammitglieder lernen die Domäne durch den direkten Kundenkontakt besser kennen.

Wenn das Produkt weiter wächst, kommen sogenannte Area-POs ins Spiel. Jeder Area-PO betreut ein großes Feature. Er schreibt eigenständig User-Storys, pflegt diese ins Backlog ein und nimmt realisierte Storys ab. Über mehreren Area-POs arbeitet ein einzelner Chef-PO, der nur noch auf Epic-Ebene arbeitet und in Konfliktsituationen als Entscheidungsinstanz fungiert. So bleibt ein großer Vorteil erhalten: eine Person, die über die großen Linien im zentralen Produkt-Backlog entscheiden kann.

…One Backlog to bind them

Oft geht es ganz schleichend: Teams etablieren ihr eigenes Team-Backlog als Grundlage für das Planning. Auf den ersten Blick wirkt das übersichtlicher. Mittelfristig nehmen Team-Backlogs aber den Überblick, denn sie verschleiern die Sicht auf das Gesamtprodukt. Ich sehe einen zweiten Nachteil: Die Backlogs laufen nach einigen Sprints auseinander. Deshalb lohnt sich – trotz steigender Größe – ein einziges, zentrales Produkt-Backlog.

Das zentrale Product-Backlog enthält alle Anforderungen und User-Storys an das Produkt ohne Zuordnung zu einem konkreten Team. Zu Beginn jedes Sprints werden Storys zugeteilt und dann in die Team-eigenen Sprint-Backlogs überführt: Sie enthalten nur die aktuellen Aufgaben, bleiben in der Alltagsarbeit übersichtlich und müssen trotzdem nicht mühsam zur großen Vision zurück synchronisiert werden. Dem übergreifenden Product-Backlog stehen so in jedem Sprint mehrere Sprint-Backlogs als Arbeitsversionen der einzelnen Teams gegenüber.

So verbinden sich zwei Vorteile: Die einzige Quelle der Wahrheit für die Zukunft ist das Product-Backlog. Es ist gleichzeitig die Arbeitsebene für den PO. Die Gegenwart, also der aktuelle Sprint, spiegelt sich übersichtlich in den Sprint-Backlogs. Und die Teams leiden nicht unter dem Rauschen von zu vielen Stories im Backlog.

Wie sind Ihre Erfahrungen mit der Skalierung agiler Praktiken auf große Maßstäbe? Was funktionierte gut, was weniger gut? Wir freuen uns auf Ihre Kommentare!

Aufmacherbild: elephant running across a tightrope von Shutterstock / Urheberrecht: eelnosiva

Geschrieben von
Christoph Niemann
Christoph Niemann
Christoph Niemann ist IT-Consultant bei MaibornWolff. Er arbeitet am liebsten im agilen Requirements-Engineering an der Schnittstelle zwischen Fachbereich und Entwicklungsteam. Mit seiner agilen Erfahrung, besonders mit Scrum, hilft er Projekten beim Umbau vom Wasserfallmodell auf ein iteratives Vorgehen.
Timo Becker
Timo Becker
Timo Becker ist Software-Ingenieur bei MaibornWolff und entwickelt aktuell Individual-Software in einem großen agilen Projekt.
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: