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
____________________________________________________________________________________________________
Seizing opportunities for better collaboration, part 1
A case study on leveraging opportunities for better collaboration
Introduction
With this article I would like to describe and reflect on an organizational development process that I accompanied some time ago.
Often, goals are defined for development measures and, based on these, interventions are designed and implemented. Often resistance is reported and how it should be dealt with. I often take a different approach.
As an internal Agile Coach, I accompany the organization over a longer period of time, participate in everyday life and am in contact with many teams and different levels. Over time, this repeatedly reveals to me ways of working that (in my view) are not conducive to success. Sometimes this results in change assignments, as described above, but often not. I have learned over time to continue to observe in these cases and wait for a suitable opportunity. For me and the organizations I accompany, this opportunity-based approach works well. To me, it seems to be a low-energy way to change. By picking up on existing momentum, much of the resistance can be avoided.
In this paper, I describe one such opportunity-based development process.
Starting point
I facilitated this process in a mid-sized tech company running a B2B digital product. Just over 15 agile and cross-functional product development teams work there to develop the product and keep it running. The company believes in delegating responsibility to the teams as much as possible. This means that product owners on the teams are responsible for product strategy and prioritization decisions.
After a period of extreme decentralization, management decided to introduce a Head of Product function. They did this because they thought that product development was not sufficiently aligned with an overarching strategy. The idea was to keep the autonomy of the teams, but to work within certain frameworks. Some people in the organization interpreted this as a return to „command and control“ and limiting their freedom.
The Agile Coaching Team was tasked with guiding the ongoing development and ensuring that the product organization was working across teams on strategy and operating effectively. In doing so, we had to be careful to address concerns about a return to old, rigid hierarchies and find an appropriate balance between autonomy and alignment.
Joint coexistence
When structuring agile teams, an attempt is made to keep interdependencies to a minimum to enable independent action and avoid costly coordination. However, when agile teams contribute to an integrated product offering, interdependencies are inevitable. For example, one team builds its work on software components for which another team is responsible, or components from different teams exchange data with each other. Dealing with these dependencies has a significant impact on the speed of development and innovation.
The teams‘ decoupled working methods led to a lack of knowledge about the other teams‘ plans. Only late in the development process were dependencies identified and unplanned coordination with the team in question had to take place. Those responsible for the team had to be convinced to plan capacities for support. Because of their own goals and other teams‘ plans aligned with them, there were often long waiting times, blocking the dependent team.
Although a mechanism existed for teams to edit dependencies in the other team’s source code themselves, in practice this often resulted in similarly long wait times, as support from the other team was required for anything but trivial adjustments and no capacity was accounted for.
These inefficiencies were not limited to dependencies, but also resulted in missed opportunities for business due to lack of communication and shared situational awareness.
Community Building
As Agile coaches, we observed that teams working independently led to inefficient processes. Our position as facilitators of multiple teams allowed us to identify patterns and take initiative based on them.
We sought to talk with the Head of Product to share our observations and encourage more connected collaboration. At first, we were met with skepticism: „If the product owners all talk to each other as much as they talk to me, there’s no room left for the actual work.“
But as things progressed, we were able to convince him together of the benefits of better networking. We agreed that bilateral coordination meetings or big planning meetings would be wrong and that there is a better way. We were convinced that this way would be better developed through shared learning than through analysis and design.
