Wenn du Scrum Product Owner (PO) bist, ist dir die Überflutung des Product Backlogs durch neue Umsetzungs- oder Verbesserungsideen, durch Abbau von Produktschulden oder Fehlerbehebungen sicherlich schmerzlich bekannt.
Diese schiere Überforderung des Eingangskanals (Backlogtrichter) macht das Backlog absolut unübersichtlich. Die Priorisierung wird damit zum Glücksspiel und das endet häufig in einem Niedergang des durch involvierte Teams erzeugten Outcomes.
Und das ist nur eine von vielen Herausforderungen, vor denen Product Owner in der Realität tagtäglich stehen.
Doch was kann einen PO in solchen Situationen unterstützen, um eben nicht zur produktiven Engstelle im Gesamtprozess und damit zum Sargnagel des wirtschaftlichen Produkterfolges zu werden?
Aus meiner Sicht ist es Kanban. Aber warum?
Wie stellt sich das Problem dar?
Scrum sieht mit der Review ein Event vor, in dem das Besprechen und Beschließen der agilen Produktentwicklung mindestens für die nächsten Iterationen auf der Agenda stehen sollte. Leider sieht die Realität in vielen Scrum-Umfeldern aber anders aus.
Was als Pull in der Review erfolgen sollte, artet in der Praxis häufig in Push-Aktionen außerhalb der Review und damit dem eigentlich prädestinierten Event aus.
Da werden von Stakeholdern oder Developern Themen mal eben in Richtung des POs über den Zaun geworfen und dann kommt es maßgeblich auf das Agieren dieser Rolle an. Ist aus solchen Situationen die Meinung entstanden, dass das wichtigste Talent eines Product Owners das Neinsagen ist?
Warum kann Kanban dieses Problem lösen?
Das eingangs geschilderte Problem entsteht, indem ein von Pull geprägtes System wie Scrum durch Push-Aktionen überfordert wird. Diese Überforderung zeigt sich beim Verantwortungsbereich des Product Owners, der letztlich Bedarf und Kapazität für den bestmöglichen Kundeneffekt nicht mehr effizient in Einklang bringen kann.
Kanban – richtig verwendet – visualisiert Arbeitsabläufe und macht so Engstellen im Prozess sehr schnell für jeden Beteiligten ersichtlich. Der Verantwortungsbereich des POs käme im geschilderten Szenario also recht schnell ins Augenmerk.
Dazu nutzt Kanban – im Gegensatz zu Scrum – als ebenfalls Pull-basiertes System, sogenannte Work in Progress-Limits (WiP-Limits). Diese beschränken das Volumen eines Prozessschrittes und können so für einen Product Owner quasi als Türsteher am Eingangskanal fungieren.
Zusätzlich macht Kanban Informationen sehr transparent und eignet sich so auch zur Koordination und Planung und das nicht nur auf Team- (und damit operationeller) Ebene, sondern auch bis hoch in den strategischen Bereich.
Und genau diese geschilderten Effekte sind es, die den Product Owner in seinem Verantwortungsbereich enorm unterstützen können. Doch was könnte ein PO nun beispielhaft in seinem Arbeitsumfeld mittels Kanban etablieren?
Das Flight Level Model
Auf diese Frage gibt das Flight Level Model von Klaus Leopold gleich dreifach eine Antwort. Beim Flight Level Model handelt es sich um ein agiles Management-Modell, das auf den Prinzipien der Systemtheorie basiert. Es betrachtet Organisationen als komplexe, adaptive Systeme und zielt darauf ab, die Leistungsfähigkeit und Effektivität von Teams und Unternehmen im Ganzen zu verbessern.
Das Modell definiert drei Ebenen, die sogenannten Flight Levels:
- Flight Level 1: operative Ebene
- Flight Level 2: koordinative Ebene
- Flight Level 3: strategische Ebene
Auf jeder dieser Ebenen wird nun ein Teil des Gesamtprozesses in der Wertschöpfungskette mit Hilfe von Kanban in unterschiedlichem Detailgrad abgebildet.
Dabei legt das Flight Level Modell seinen Fokus auf die Kanban-Prinzipien. Durch kontinuierliche Verbesserung, Transparenz, Zusammenarbeit sowie schnelles Feedback wird eine anpassungsfähige und lernende Organisation gefördert und Business Agilität etabliert.
Wie helfen das Flight Level Modell und Kanban einem PO?
Ein Product Owner kann nun jeden dieser drei Flight Level für sich und die Personen nutzen, mit denen er in den entsprechenden Flight Levels kollaboriert.
Flight Level 1: operative Ebene
Die operative Ebene ist die Team-Ebene. Jetzt sagst du dir zu Recht: Aber da machen wir doch Scrum?! Und ja, natürlich folgt ein Scrum-Team grundsätzlich (mehr oder weniger) dem Regelwerk des Scrum-Frameworks.
Scrum bietet aus meiner Sicht aber wenig Anhalt zur Unterstützung von Scrum-Teams bezüglich des Eingangstrichter-Managements. Scrum sieht die Reviews und Refinements dafür vor und spricht von einem DEEP-Backlog, also der Tatsache, dass Tickets am Anfang des Eingangstrichters eher grobe Informationen enthalten und dann nach und nach durch Refinements immer feiner und damit für die Entwickler letztlich bearbeitbar werden.
DEEP steht für …
- Detailed (appropriately)
- Estimated
- Emergent
- Prioritised
Doch welche Arbeitsschritte laufen innerhalb dieses Teilprozesses ab und wo werden diese und der jeweilige Zustand transparent? Wie hilfreich ist dieser Ansatz in dem oben geschilderten Szenario? Funktioniert der mit Zyklen von ein bis vier Wochen avisierte iterative Scrum-Ansatz hier in der Praxis?
Aus meiner Sicht nein und deshalb habe ich gute Erfahrungen damit gemacht, ein Kanban-Board zur Abbildung der realen Prozesse zu erstellen und dieses mit dem Team für Refinements zu nutzen.
Beispielhaft bildet ein solches Board dann vom Eingang einer wie auch immer gearteten Aufgabe bis hin zum Erzielen der vom Team beschlossene Definition of Ready (DoR) bei dieser Aufgabe alle Prozessschritte im Team ab.
Der Vorteil dieses Ansatzes ist, dass das im Scrum-Guide lediglich in Bezug auf das Artefakt Product Backlog genannte und nicht näher definierte Refinement durch das Kanban-Board zum Flight Level 1 in einen visualisierten Prozess gehoben wird.
Needs und Probleme werden frühzeitig sichtbar, was dem Team wiederum eine stete Verbesserung des Refinement-Prozesses ermöglicht. Und der PO hat endlich einen visuellen Anhalt, um die richtigen Dinge zum notwendigen Zeitpunkt mit dem Team für die Umsetzung bereit zu haben. Ein Luxus, den das Backlog so nicht hergibt.
Flight Level 2: koordinative Ebene
Die koordinative Ebene kann für einen PO in der Eingangs geschilderten Problematik aus meiner Sicht in zwei Richtungen gedacht werden. So kann jeder PO diese Ebene grundsätzlich zur thematischen Koordination zwischen Team und Stakeholder(n) verwenden.
Zusätzlich bietet diese Ebene dem PO aber ggf. auch die Möglichkeit, mehrere Teams über bestehende Teamgrenzen hinweg auf der Zeitachse zu koordinieren.
Scrum bietet für diesen Fall bestenfalls das Product Backlog. Aber bietet das die gewünschten Fähigkeiten und vor allem die Transparenz?
Für mein Empfinden nein und deshalb habe ich in der Vergangenheit auch bei dieser Problemstellung mit einem Kanban-Board gute Erfahrungen gemacht.
Genutzt habe ich dazu ein Kanban-Board auf Basis von Epics, das die Prozessschritte vom Eingangskanal bis zum Erreichen der Definition of Done (DoD) abbildete. Um die Workload zu optimieren, nutze ich WiP-Limits effektiv.
Natürlich ist hier der augenscheinlichste Vorteil dieser Anwendung wieder die Visualisierung des Prozesses. Zusätzlich wird aufgrund der genutzten Epics ein gröberer und für die Problemebene meistens vollkommen ausreichender Überblick geschaffen, den ein Product Backlog so mal überhaupt nicht hergibt.
Priorisierung, Koordination und damit Kapazitätsverteilung kann mit diesem Kniff eines Product Owners leicht an einem übersichtlichen Kanban Board erfolgen. Zeitliche Erwartungen von Stakeholdern können direkt verifiziert werden. Abhängigkeiten zwischen involvierten Teams werden sichtbar.
Aufgrund der Verwendung von Kanban werden Prozessprobleme auch hier schnell sichtbar und können stetig gezielt verbessert werden.
Und last but not least wird durch die Nutzung von WiP-Limits quasi der vorher schon erwähnte Türsteher für die einzelnen Eingangskanäle der Entwicklungsteams installiert und die Überflutung des Product Backlogs bleibt aus.
Flight level 3: strategische Ebene
Die strategische Ebene ist nun die Ebene, in der der Product Owner hauptsächlich mit den Stakeholdern und dem Top-Management kollaboriert. Diese Ebene kann der PO wunderbar zum Ideen- und Portfolio-Management nutzen.
Scrum bietet für diese Aufgabenstellung einzig die Review und auch hier bin ich der Meinung, dass das vom Scrum-Guide gegebene Rüstzeug gerade für unerfahrene Product Owner mehr Fragen aufwirft als Antworten liefert.
Ich habe in dieser Problemstellung zusammen mit Stakeholdern und dem Top-Management ein Kanban-Board auf Initiativen-Basis genutzt, das den gesamten Prozess von der Einreichung einer Idee bis hin zur erfolgten Verifizierung des Outcomes der aus einer Idee hervorgegangenen Initiativen abbildete. Um auch hier die Workload zu optimieren, nutzen wir wiederum WiP-Limits.
Basis dieses Ansatzes ist erneut das Visualisieren von Prozessen. Daraus resultierend bieten sich zunächst die Möglichkeit zur transparenten Auseinandersetzung mit Ideen, sowie nach deren wirtschaftlicher Bewertung auch der Priorisierung.
Da in diesem Flight Level aus meiner Sicht auch die Verifikation des Outcomes einer Initiative absolut dazugehört, ermöglicht dieser Ansatz zusätzlich nicht nur die in den vorherigen Leveln ebenfalls genannte stete Verbesserung des Prozesses.
Die Verifikation ermöglicht vor allem das Erzielen von extrem wertvollen, kundenbasierten Produkt-Learnings und das bis hoch ins Top-Management. Gerade wenn im Management Entscheidungen noch immer basierend auf dem Bauchgefühl getroffen werden, ermöglicht dieser Ansatz eine Entwicklung hin zu Daten-getriebenen Entscheidungen.
Folgerungen für die Umsetzung
Die Überforderung des Scrum Product Owners durch fehlendes Handwerkzeug ist eine absolut lösbare Aufgabe. Auch als PO gilt es, sich die Scrum-Werte vor Augen zu führen und diese zu leben!
Warum also nicht mutig sein und auch über den Tellerrand hinausschauen?
Als ich vor vielen Jahren durch einen Meetup-Beitrag von Klaus Leopold auf das Flight Level Modell aufmerksam wurde, hatte ich direkt diverse Problemfelder vor Augen, die ich experimentell mit Kanban angehen wollte.
Die fünf Scrum-Werte
- Focus
- Openess
- Courage
- Commitment
- Respect
Die hier aufgeführten Beispiele der Implementierung von Kanban durch den PO, also
- der Refinement-Prozess,
- die Koordination von Teams untereinander und mit den Stakeholdern,
- das Ideen- und Portfolio-Management,
sind von meiner Seite bewusst grob gehalten und spiegeln nicht den letzten Entwicklungsstand wider, denn der Ansatz von Kanban und des Flight Level Models ist, dort zu beginnen, wo man als Product Owner bzw. als Unternehmen gerade steht.
Dieser initial in den Kanban-Boards abgebildeten Prozessstand inkl. der WiP-Limits sollte dann im Laufe der Zeit durch iterative Anpassungen immer weiter verbessert werden.
Und auch wenn in deinem Unternehmen bereits mit Objektives & Key Results (OKRs) gearbeitet wird und du dir als PO die Frage stellst, wie du das alles unter einen Hut bringen sollst, sind die Flight Levels absolut dafür gemacht!
Fazit
Der Outcome meiner Kanban-Implementierungen, also
- die gemeinsam vereinbarten und optimierten Prozesse,
- die hohe Transparenz bzgl. Informationen, Priorisierung und getroffener Entscheidungen,
- die Verringerung / Ausmerzung der Umsetzung von eher Wert-armen Ideen / Initiativen,
- die Beschleunigung der Lead Time / Time To Market von Initiativen,
sorgten für deutlich mehr Zufriedenheit bei allen Beteiligten und begeisterten damit letztlich nicht nur mich, sondern eben auch die involvierten Kollegen.
Also lebe als Product Owner die Scrum-Werte, sei offen und schau dir Kanban und das Flight Level Model mal genauer an. Sei mutig, entwickle Ideen zur Kanban-Implementierung in deinem Scrum-Umfeld und experimentiere mit diesen.
Solltest du Unterstützung wollen, um für dein Umfeld Ansätze zu finden und diese zu etablieren, stehen wir dir von MAYFLOWER natürlich auch gerne zur Seite. Und wenn du Fragen hast oder dich unverbindlich austauschen möchtest, dann schnappe dir einen Termin aus meinem Kalender.
Schreibe einen Kommentar