Produkt- und Teamschnitt: Skalierung oder Portfolio?

Diese Woche hatte ich wieder einen sehr spannenden Termin mit einer Teilnehmerin aus einem Professional Scrum Product Owner - Advanced Training, die gerne mehr über Produktschnitt und Skalierung wissen wollte. Ich freue mich immer über solche Termine, weil sie konkrete Probleme behandeln und die oft so klare Theorie plötzlich unscharf wird.

Ein zentraler Punkt, den ich mit ihr besprochen habe, und der auch bei anderen Organisationen und Teams immer wieder aufkommt, ist die Frage nach dem richtigen Produktschnitt und - häufig damit verbunden - der Skalierung von (Scrum) Teams.

Deshalb hier mal ein paar Gedanken dazu.

Ein zentrales Problem der agilen Produktentwicklung

Das Bild oben zeigt trotz seiner maximalen Einfachheit ein zentrales Problem agilen Arbeitens: wir wollen in kleinen Teams arbeiten, die Probleme, die wir lösen, sind aber gleichzeitig so umfangreich oder komplex, dass wir das mit einer handvoll Menschen nicht hinbekommen. Deshalb machen wir uns Gedanken zum richtigen Schnitt des Produkts und landen in der Regel bei einer Baumstruktur. Der Wurzelknoten (oben, Mathematiker sind komische Biologen) ist die äußere Klammer und die Blätter (unten) sind die kleinen und interdisziplinären Teams, die den Wert schaffen.

So abstrakt, wie das Bild es zeigt, ist das auch total klar, aber wir geraten in der Regel an mehreren Stellen ins Straucheln:

• Wo ist der Produkt Owner? In der Wurzel oder in den Blättern?
• Wie synchronisieren die einzelnen Teams sich und gehen mit ihren Abhängigkeiten um?
• Welche Aspekte der Produktentwicklung werden zentral in der Wurzel oder dezentral in den Blättern gelöst und entschieden?

Weil das Ganze so schwierig ist, suchen viele Organisationen und Teams nach einer Vorlage, die sie anwenden können und die “einfach funktioniert”. Das ist ein wenig wie zum Architekten zu gehen, und ein Haus zu bestellen, das “einfach passt”. Ohne zu wissen, welches Problem in welchem Kontext gelöst werden soll, ist es schwierig bis unmöglich, die richtige Lösung vorzuschlagen. Denn - und das habe ich am Wochenende erst mit Oli diskutiert - Lösungen, die vorgeben, alles zu können, können nichts so richtig.

Also ist am Ende doch wieder Handarbeit gefragt und wir müssen eine individuelle Lösung finden. Deshalb hier ein paar Ideen, wie ihr die oben beschriebenen Fragestellungen für Euch bearbeiten könnt, um zu einer Lösung zu gelangen, die Euer Problem löst.

Produktschnitt

Die erste Frage, die ich bearbeiten würde, ist die nach dem Produktschnitt. Ist die Wurzel das Produkt und die Blätter sind Teile dieses Produkts oder ist die Wurzel ein Produktportfolio und die Blätter sind Produkte?

Diese Frage klingt vielleicht erst mal nach Haarspalterei, aber sie ist relevant und wesentlich.

Wenn der Wurzelknoten das Produkt ist, dann ist der Product Owner (oder wie auch immer ihr die Person nennt) auf dieser Ebene anzusiedeln. Die Wertschöpfung und das Kundenproblem werden also auch auf dieser Ebene und damit recht zentral gesteuert. Das eignet sich sehr gut für Probleme, die einen zentralen Kunden sowie ein zentrales Kundenproblem haben.

Der Produkt Owner in diesem Szenario wird allerdings dann auch in einer eher strategischen und teamübergreifenden Verantwortung stehen. Das bedeutet, dass die eher taktischen Arbeiten in den Teams von anderen Menschen übernommen werden müssen. Wir müssen uns also überlegen, wie wir die Aufgaben des Product Owners auf den unterschiedlichen Flughöhen gut verteilen und delegieren.

Bei einem Produktschnitt, bei dem die einzelnen Blätter in sich geschlossene Produkte sind, haben wir genau das Gegenteil: die Product Owner arbeiten mit “ihrem” Team und können sich im jetzt kleineren Kontext vermutlich breiter und umfassender um das Produkt auch auf der taktischen Ebene kümmern. Dafür fehlt jetzt aber übergeordnet jemand. Könnte das der Chief Product Owner sein? Natürlich nicht, das führt zu einer Verwässerung des Begriffs: Eigentum kommt mit Verantwortung und diese muss klar zugeordnet sein, damit sie greift. Deshalb würde ich hier auch begrifflich Klarheit schaffen. Das Konstrukt ist ein Portfolio von Produkten und wir könnten z.B. einen Portfolio Owner etablieren.

Diese Lösung bietet sich eher an, wenn die einzelnen kleineren Produkte für sich genommen Wert schaffen und vielleicht sogar eigene Kunden haben. Die Teams werden dadurch in der Regel unabhängiger voneinander, was aber auch bedeutet, dass wir mehr Autonomie in die Teams bringen sollten, um die Abhängigkeiten zu minimieren und damit Wartezeiten und Flussverzögerung zu vermeiden.

Abhängig vom Produktschnitt ist es jetzt wichtig, sich auch Gedanken zum Teamschnitt und zur Architektur zu machen. Der Teamschnitt soll vor Allem dafür sorgen, dass das Team mit hoher Kohäsion nach innen und möglichst wenigen bremsenden Abhängigkeiten nach außen arbeiten kann. Die Architektur sollte so gestaltet werden, dass im gewählten Produkt- und Teamschnitt optimal gearbeitet werden kann und gleichzeitig die Qualitätsziele des Produkts oder der Portfolio-Produkte erreicht werden können.

Synchronisation und Abhängigkeiten

Und da sind wir schon bei den Abhängigkeiten und der deshalb notwendigen Synchronisation. Egal, ob es sich bei unserem Bild um ein Produkt mit mehreren Bestandteilen handelt, oder um ein Portfolio aus Produkten mit eigener Wertschöpfung, die Teams der Blätter müssen sich aneinander und am gemeinsamen Ziel ausrichten.

Bei einem Produkt aus verschiedenen Bestandteilen ist das gemeinsame Ziel die Produktvision. Diese hilft den unterschiedlichen Teams dabei, das große Ganze zu sehen. Allerdings schleichen sich dann in der Praxis häufig Abhängigkeiten zwischen den Teams ein, die zu Zähigkeit und langsamerem Fluss in der Wertschöpfung führen. Einerseits durch Übergaben von Arbeit zwischen Teams bzw. der gemeinsamen und teamübergreifenden Bearbeiten von Aufgaben. Aber auch durch technische und fachliche Abhängigkeiten, die durch zentral getroffene Entscheidungen erzeugt werden und berücksichtigt werden müssen.

Ein Portfolio von eher unabhängigen Produkten ist hier deutlich schlanker aufgestellt. Jedes Produkt schafft für sich Wert, hat deshalb auch für sich eine Daseinsberechtigung und kann in der Regel deshalb auch freier entscheiden. Dafür ist es häufig schwieriger, gemeinsame Standards zu etablieren und auch zu halten. Das sorgt für unnötig individuelle Lösungen, die dezentral und mehrfach entwickelt und vor allem betrieben werden müssen. Gleichzeitig sind die Abhängigkeiten, die trotzdem bestehen bleiben, häufig noch störender für die Teams als im zentralen Produkt, da jedes Team eigentlich von der eigenen Unabhängigkeit ausgeht und deshalb häufig keine richtig guten Lösungen für die Synchronisation und Beseitigung von oder Umgang mit Abhängigkeiten entwickelt werden.

Auch hier gibt es keine ultimativ beste Lösung. In jedem Kontext muss entschieden werden, wie viel Autonomie und wie viel Zentralismus hilft, die eigenen Ziele zu erreichen. Wie zentral ist das Kundenproblem und die -lösung? Wie eng wollen und sollten wir zusammenarbeiten, um diese Lösung zu schaffen? Und wie flexibel möchten oder müssen wir sein, um einen Arbeitsfluss zu etablieren, der es uns ermöglicht, unsere Hypothesen im Produkt schnell zu vertesten und bei Bedarf unseren Weg häufig anzupassen?

Entscheidungskompetenz

Im letzten Abschnitt ist es schon angeklungen: ein wichtiger Punkt bei der Skalierung ist Entscheidungskompetenz, also “wer entscheidet was?”. Die Standardantwort im agilen Arbeiten lautet Selbstorganisation, aber das hilft bei der Vielzahl von Entscheidungen sowie Umgebungen leider nicht viel. Deshalb schauen wir uns das noch ein wenig genauer an.

Warum ist Selbstorganisation und die Übernahme von Verantwortung bei agilen Teams und Organisationen so hoch angesehen? Hierbei geht es um mehrere Punkte:

1. Schnelle und unkomplizierte Entscheidungen fördern schnelles und flexibles Arbeiten
2. Menschen, die über ihren Arbeitsbereich entscheiden dürfen und können, sind motivierter
3. Dezentrale Entscheidungskompetenz lädt zum mitdenken ein und schafft eine Umgebung, in der Menschen Verantwortung übernehmen

Große und traditionell hierarschisch sowie zentral geführte Organisationen tun sich damit oft schwer. Die Mitarbeitenden sind es nicht gewohnt entscheiden zu dürfen und haben Angst davor, falsche Entscheidungen zu treffen. In solchen Organisationen Entscheidungskompetenz in die Breite zu verlagern, hat also häufig nicht primär etwas mit den Enscheidungen selbst zu tun, sondern setzt grundlegender an. Das könnte ein Thema für einen eigenen Artikel sein. ;) Für uns hier ist jetzt erst mal nur relevant, was Entscheidungskompetenz für das beschriebene Problem bedeutet.

Bei einem zentralen Produkt braucht es üblicherweise Strukturen über den einzelnen Teams, die grundlegende Entscheidungen treffen. Oft werden hierzu Metastrukturen aus den Teams heraus geschaffen, die zentrale Aspekte bearbeiten und wichtige Entscheidungen treffen, z.B. ein Scrum of Scrums oder Nexus Integration Team. Diese - häufig virtuellen - Meta-Teams schaffen in der Regel den Rahmen, in dem sich die einzelnen Teams dann selbst organisieren können. Hier werden z.B. die strategische Ausrichtung des Produkts, die grundlegende Architektur oder einzuhaltende Rahmenbedingungen definiert. Weiterhin unterstützen diese übergeordneten Steuerungskonstrukte die Teams oft bei der Umsetzung dieser Vorgaben und stellen Strukturen bereit, sie unkompliziert einzusetzen.

Bei kleineren Produkten in einem übergeordneten Portfolio wandern Autonomie und Enscheidungskompetenz üblicherweise in die einzelnen Produktteams. Diese Teams werden dadurch automatisch selbstorganisierter und können mehr Verantwortung übernehmen. Das ist vorteilhaft für Arbeitsfluss, da weniger Schleifen gedreht werden und Entscheidungen unkomplizierter getroffen - und auch wieder verändert oder verworfen - werden können.

Des Einen Vorteil ist des Anderen Nachteil: schnellere Entscheidungen führen zu mehr Agilität, aber auch zu weniger Synchronisation und Standardisierung. Andererseits erleichtert eine zentrale Führung über ein größeres Produkt hinweg die strategische Ausrichtung und die Ausbildung von Standards und Struktur, aber oft zu Lasten der Agilität, Schnelligkeit und des Arbeitsflusses.

Was machen wir jetzt damit?

Es greift also wie so oft die abgedroschene Antwort der Berater und Agilisten: es kommt darauf an. Wenn diese Antwort nicht beinhaltet, worauf es ankommt, hilft sie nicht. In diesem Artikel habe ich versucht, die Faktoren, auf die es ankommt, ein wenig zu beleuchten.

Jede Organisation und jedes Teamgeflecht, das in eine größere Produktentwicklung investieren möchte, sollte sich die folgenden Leitfragen stellen, um zu entscheiden, welche Struktur am besten hilft, um die eigenen Ziele zu erreichen. Oder, um eine meiner Lieblingsphrasen rund um Skalierung zu bemühen: wo der temporäre Weg des geringsten Schmerzes entlang führt.

• Wer ist der oder wer sind die Kunden, deren Probleme wir lösen möchten?
• Wie einheitlich oder fragmentiert sind diese Probleme?
• Wie viel zentrale Standards und Kontrolle brauchen wir, um uns wohl zu fühlen; und wie viel Autonomie können wir gut in Wertschöpfung umsetzen, ohne uns in uns selbst zu verlieren?

Was meinst Du? Welche Aspekte habe ich übersehen und sollten ebenfalls mit berücksichtigt werden? Welche Form von Skalierung funktioniert bei Euch gut und weshalb? Schreib mir unter peter@flowdaptic.de.