Eine Fallstudie zur Nutzung von Chancen für eine bessere Zusammenarbeit
Einleitung
Mit diesem Beitrag möchte ich einen Organisationsentwicklungsprozess beschreiben und reflektieren, den ich vor einiger Zeit begleitet habe.
Oft werden für Entwicklungsmaßnahmen Ziele definiert und ausgehend davon Interventionen konzipiert und umgesetzt. Vielfach wird dann von erlebten Widerständen berichtet und wie mit diesen umgegangen werden sollte. Ich gehe oft anders vor.
Als interner Agile Coach begleite ich die Organisation über längere Zeit, nehme am Alltag teil und stehe mit vielen Teams und unterschiedlichen Ebenen in Kontakt. Mit der Zeit zeigen sich mir dabei immer wieder Arbeitsweisen, die (aus meiner Sicht) dem Erfolg nicht dienlich sind. Manchmal ergeben sich daraus Veränderungsaufträge, wie oben beschrieben, oft aber auch nicht. Ich habe im Laufe der Zeit gelernt, in diesen Fällen weiter zu beobachten und auf eine passende Gelegenheit zu warten. Für mich und die Organisationen, die ich begleite, funktioniert dieser gelegenheitsbasierte Ansatz gut. Mir scheint dies ein energieschonender Weg zur Veränderung zu sein. Indem vorhandene Impulse aufgegriffen werden, kann vieles an Widerstand vermieden werden.
In diesem Beitrag beschreibe ich einen solchen Entwicklungsprozess, der auf einer Gelegenheit basiert.
Ausgangslage
Ich habe diesen Prozess in einem mittelgroßen Tech-Unternehmen begleitet, das ein digitales B2B-Produkt betreibt. Etwas mehr als 15 agile und crossfunktionale Produktentwicklungsteams arbeiten dort daran, das Produkt zu entwickeln und am Laufen zu halten. Das Unternehmen glaubt daran, Verantwortung so weit wie möglich an die Teams zu delegieren. Das bedeutet, dass die Product Owner in den Teams für Entscheidungen zur Produktstrategie und Priorisierung verantwortlich sind.
Die Unternehmensleitung hat nach einer Phase der extremen Dezentralisierung beschlossen, eine Head of Product Funktion einzuführen. Sie taten dies, weil sie dachten, dass die Produktentwicklung nicht ausreichend auf eine übergreifende Strategie ausgerichtet war. Die Idee war, die Autonomie der Teams beizubehalten, aber innerhalb bestimmter Rahmenbedingungen zu arbeiten. Einige Menschen in der Organisation haben das als Rückkehr zum „Command & Control“ und Einschränkung ihrer Freiheit interpretiert.
Das Agile Coaching Team hatte die Aufgabe, die laufende Entwicklung zu begleiten und sicherzustellen, dass die Produktorganisation teamübergreifend an der Strategie arbeitet und effektiv agiert. Dabei mussten wir darauf achten, dass wir die Bedenken hinsichtlich einer Rückkehr zu alten, starren Hierarchien berücksichtigen und einen passenden Ausgleich zwischen Autonomie und Ausrichtung finden.
Ein Schritt in die richtige Richtung
Die Einrichtung der Head of Product Funktion führte dazu, dass sich die Planung der Teams stärker an der Unternehmensstrategie ausrichtete. Das kam daher, dass der Head of Product und die Product Owner regelmäßig miteinander sprachen und der Head of Product seine übergeordnete Perspektive in die Diskussion einbrachte. So hatten die Product Owner die Möglichkeit, diese Perspektive bei ihren Planungen zu berücksichtigen.
Allerdings erfolgte diese Ausrichtung in einer sternförmigen Struktur. Jeder Product Owner stand regelmäßig im Kontakt mit dem Head of Product, aber der Austausch zwischen den Teams war eher informell und situativ organisiert.
Gemeinsames Nebeneinander
Bei der Strukturierung agiler Teams wird versucht, die Abhängigkeiten untereinander möglichst gering zu halten, um eigenständiges Handeln zu ermöglichen und aufwendige Koordination zu vermeiden. Wenn jedoch die agilen Teams zu einem integrierten Produktangebot beitragen, sind gegenseitige Abhängigkeiten unvermeidlich. Zum Beispiel baut ein Team seine Arbeit auf Softwarekomponenten auf, die ein anderes Team verantwortet, oder die Komponenten unterschiedlicher Teams tauschen Daten miteinander aus. Der Umgang mit diesen Abhängigkeiten hat erhebliche Auswirkungen auf die Entwicklungs- und Innovationsgeschwindigkeit.
Die voneinander entkoppelte Arbeitsweise der Teams führte zu einer fehlenden Kenntnis über die Pläne der anderen Teams. Erst spät im Entwicklungsprozess wurden Abhängigkeiten erkannt und es musste eine ungeplante Abstimmung mit dem betreffenden Team erfolgen. Die Verantwortlichen des Teams mussten davon überzeugt werden, Kapazitäten für die Unterstützung einzuplanen. Aufgrund eigener Ziele und darauf abgestimmter Planungen anderer Teams kam es häufig zu langen Wartezeiten, wodurch das abhängige Team blockiert wurde.
Obwohl ein Mechanismus existierte, mit dem die Teams selbst Abhängigkeiten im Quellcode des anderen Teams bearbeiten konnten, führte dies in der Praxis häufig zu ähnlich langen Wartezeiten, da für alles andere als triviale Anpassungen Unterstützung durch das andere Team erforderlich war und keine Kapazitäten berücksichtigt wurden.
Diese Ineffizienzen beschränkten sich nicht nur auf Abhängigkeiten, sondern führten auch dazu, dass Gelegenheiten für Geschäft ungenutzt blieben, da aufgrund mangelnder Kommunikation und gemeinsamen Lagebildes Chancen nicht erkannt oder nicht schnell genug genutzt werden konnten.
Community Building
Als Agile Coaches beobachteten wir, dass die unabhängige Arbeitsweise der Teams zu ineffizienten Prozessen führte. Unsere Position als Begleiter mehrerer Teams ermöglichte es uns, Muster zu erkennen und darauf aufbauend die Initiative zu ergreifen.
Wir suchten das Gespräch mit dem Head of Product, um unsere Beobachtungen zu teilen und eine stärker vernetzte Zusammenarbeit anzuregen. Zunächst stießen wir auf Skepsis: “Wenn die Product Owner alle so viel miteinander reden wie mit mir, bleibt kein Raum mehr für die eigentliche Arbeit.”
Doch im weiteren Verlauf konnten wir ihn gemeinsam von den Vorteilen einer besseren Vernetzung überzeugen. Wir waren uns einig, dass bilaterale Abstimmungstermine oder große Planungstermine falsch wären und es einen besseren Weg gibt. Wir waren überzeugt, dass sich dieser Weg besser durch gemeinsames Lernen entwickeln lassen würde, als durch Analyse und Design.
Foto von Edz Norton auf Unsplash
