Die optimalen Teamstrukturen einer agilen Organisation

Teamstrukturen spielen in der Zusammenarbeit mit mehreren Teams eine zentrale Rolle. In der Praxis vieler Unternehmen kommt es jedoch immer wieder dazu, dass das Zusammenspiel von Teams nicht optimal funktioniert und ein dichtes Netz von Abhängigkeiten entsteht.

Warum das so ist und welche Rolle dabei teamübergreifende Kollaboration spielt, erfährst Du in diesem Blogartikel. Außerdem zeige ich Dir, wie Du mit Hilfe von klaren Domänen & Verantwortungsbereichen mehr Autonomie für jedes Deiner Teams erzeugen kannst.

Bevor wir über optimale Teamstrukturen einer agilen Organisation sprechen, müssen wir uns zunächst vergegenwärtigen, dass Organisationen mehrere Strukturen haben. Ich werde mich dabei auf die Grundgedanken von Niels Pfläging beziehen, die er in seinem Buch Organisation für Komplexität entwickelt hat.

Nach Pfläging besitzt jede Organisation eine formelle, eine informelle und eine Wertschöpfungs-Struktur. Und zwar unabhängig davon, ob sie sich dessen bewusst ist oder nicht.

Die bekannteste und geläufigste Struktur einer Organisation ist die formelle Struktur in Form eines Organigramms.

Natürlich erfüllt diese Struktur einen gewissen Zweck und klärt vor allem vorhandene Hierarchien, die (künstlich) geschaffen wurden.

Das Problem dabei ist nur, dass die formelle Struktur gar nicht abbildet, wie Arbeit tatsächlich erledigt wird oder wie der Wertstrom einer Organisation funktioniert.

(Obwohl es schlichtweg gar nicht mehr möglich ist, wird es aber leider immer wieder versucht.)

Die informellen Struktur einer Organisation entsteht schlichtweg durch die Interaktion zwischen einzelnen Menschen bzw. Individuen.

Das ist weder gut noch schlecht, sondern einfach unvermeidlich.

Die informelle Struktur äußert sich beispielsweise als Gerüchte, Netzwerke, Koalitionen, Solidarität usw.

Wenn Organisationen in Krisen oder andere Notsituationen geraten, übernehmen diese inoffiziellen Netzwerke auch gerne „das Kommando“, weil die formelle Struktur schlichtweg versagt.

Die Wertschöpfungs-Struktur basiert nach Pfläging auf den Teams & ihren Interaktionen untereinander.

Der Wertstrom, den diese Teams bedienen bzw. erzeugen, fließt dabei von „innen nach außen“; also vom Inneren der Organisation nach außen zum Kunden bzw. Nutzer. In dieser Darstellung von Teamstrukturen wird also deutlich, dass Arbeit stark vernetzt ist.

Diese Wertschöpfungs-Struktur ist nach Pfläging übrigens in jeder Organisation vorhanden! (Und sei sie auch noch so ineffektiv oder bürokratisch.)

Das Problem ist jedoch, dass die Wertschöpfungs-Struktur nur selten aktiv gestaltet wird, weil wir uns nur allzu gerne auf die formelle Struktur unserer Organisation fokussieren.

Dieser Gedanke ist natürlich gar nicht so neu. Denn die meisten agilen Methoden und Frameworks denken in wertstrom-orientierten Teams. (Allen voran natürlich Scrum, das mit dem Scrum Team quasi den Archetypen des Wertstrom-Teams entworfen hat.)

In Team Topologies nennen sich diese Teamtypen Stream-aligned Teams, wodurch diese nicht auf eine bestimmte Methode oder Framework festgelegt werden. Die Grundprinzipien sind dabei jedoch die gleichen wie bei Scrum Teams und fußen auf der Erkenntnis, dass wertstrom-orientierte Teams der beste bekannte Weg sind, um komplexe Herausforderungen zu lösen.

Obwohl die Prinzipien und Vorteile von Stream-aligned Teams weithin bekannt sind, kommt es in der Praxis immer wieder dazu, dass Organisationen Teamstrukturen schaffen, die zu Abhängigkeiten und Problemen zwischen Teams führen.

Das liegt vor allem daran, dass sie Kollaboration zum obersten Prinzip erheben, wodurch Autonomie & Selbstorganisation einzelner Teams ins Hintertreffen gerät.

Kollaboration ist ein zweischneidiges Schwert. Während sie innerhalb Deiner Wertstrom-Teams das wichtigste und sinnvollste Interaktionsmuster darstellt, führt sie zwischen Teams dazu, dass Selbstorganisation und Autonomie verschwinden. Ich möchte Dir das an einem kurzen Beispiel illustrieren, das Du so oder ähnlich in fast allen Organisationen beobachten kannst, in denen mehrere Teams existieren.

Stell Dir vor, Du hast 3 Scrum Teams, die gemeinsam an Deinem Produkt arbeiten. In der täglichen Arbeit kommt es immer wieder dazu, dass einzelne Teammitglieder sich für die Umsetzung „ihrer“ User Story mit Kollegen aus den jeweils beiden anderen Teams absprechen (müssen).

Sehr oft liegt das daran, dass sich die betreffenden Kollegen besonders gut in dem aktuell zu bearbeitenden Thema auskennen. Folglich kollaborieren sie teamübergreifend, um das Problem zu lösen, weil die aktuellen Teamstrukturen die Lösung nicht ermöglichen.

Auf den ersten Blick erscheint Dir das vielleicht unproblematisch.

Treiben wir das Beispiel einmal auf die Spitze und unterstellen, dass jedes von 5 Teammitgliedern mit jeweils einem anderen Teammitglied der beiden anderen Teams kollaborieren muss, um seine Aufgaben zu lösen, ergibt sich ein dichtes Netzwerk an Abhängigkeiten zwischen Deinen Teams.

Im Grunde lässt sich dieser Zustand auch als Schatten-Teamstruktur bezeichnen. Denn „auf dem Papier“ hast Du zwar 3 Scrum Teams, in der Realität existiert jedoch eine Teamstruktur, die aus 5 „virtuellen Teams“ besteht. (Die sich schlimmstenfalls auch noch überschneiden.)

Je nach aktuell zu bearbeitendem Thema kann es sogar sein, dass sich diese Konstellationen verändern, um Aufgaben überhaupt bearbeiten zu können.

Mit dieser leider oft gängigen Praxis geht ein weiteres Problem einher. Denn die Lösungen, die durch teamübergreifende Kollaboration entstehen, sind später keinem existierenden Team zugeordnet.

Falls Du in der Softwareentwicklung arbeitest, kannst Du dieses Phänomen ziemlich leicht erkennen. Es sind all die kleinen Softwaremodule und -lösungen, die ursprünglich durch teamübergreifende Kollaboration entstanden sind, die jedoch später niemals klar einem Team zugeordnet wurden.

Sie werden weder gepflegt noch weiterentwickelt, weil sich niemand dafür zuständig fühlt.

Erst wenn sie Probleme bereiten, erhalten sie die notwendige Aufmerksamkeit. Was mit den beliebten Diskussion einhergeht, wer sich nun darum kümmern darf.

Glücklicherweise existiert eine Handvoll klarer Prinzipien, mit deren Hilfe Du Teamstrukturen entwickeln kannst, die die Autonomie Deiner Wertstrom-Teams begünstigen und fördern.

Mit Hilfe von zwei weiteren Teamtypen ist es darüber hinaus möglich, Komplexität aus der Domäne von Stream-aligned Teams herauszulösen und bestimmte Themen als Service zur Verfügung zu stellen, der „einfach genutzt“ werden kann.

Das Problem teamübergreifender Kollaboration lässt sich vermeiden (oder zumindest stark abschwächen), indem Du Teamstrukturen etablierst, in denen jedem Team ein klarer Verantwortungsbereich bzw. Domäne innerhalb Deines Produktes zugeordnet ist. Dieser Verantwortungsbereich muss natürlich so gestaltet sein, dass er einen eigenen, unabhängigen Wertstrom beinhaltet.

Wenn Du beispielsweise eine Musik-Streaming-App entwickelst, ergäben sich daraus sinnvolle Domänen wie beispielsweise:

Diese Domänen lassen sich dann eindeutig einem Team zuordnen, das einen eigenen, autonomen Wertstrom bearbeitet.

(Durch klare Domänen ist es außerdem viel leichter zu entscheiden, welche Kollegen zu welchem Team gehören (müssen) und welche nicht.)

Das zweite Prinzip für gute Teamstrukturen basiert auf der Cognitive Load Theory. Vereinfacht gesprochen besagt dieses Modell, dass Komplexität kognitive Belastung erzeugt. Denn falls der Verantwortungsbereich eines Teams zu groß ist, kann ein Team diesen alleine gar nicht mehr überblicken. Die Folge ist wieder teamübergreifende Kollaboration.

Auch hier kommen die bereits erwähnten Domänen wieder ins Spiel. Denn diese müssen nicht nur einen klaren, autonomen Wertstrom für ein Team beinhalten, sondern müssen auch so gestaltet sein, dass dieses Team den Themenbereich auch (kognitiv) überblicken kann.

Eine wichtige Rolle zur Reduzierung der kognitiven Belastung agiler Teams spielen in Team Topologies die beiden Teamtypen Complicated-Subsystem Teams und Platform Teams.

Durch Complicated-Subsystem Teams werden Themen, die absolutes Expertenwissen benötigen, aus der Domäne Deiner Stream-aligned Teams herausgelöst.

Platform Teams hingegen stellen technische Dienste oder Produkte für andere Teams zur Verfügung, die dann “einfach konsumiert” werden können.

Beide Teamtypen fördern damit Teamstrukturen, die sowohl den Cognitive Load für Deine Stream-aligned Teams reduzieren als auch autonome Wertströme ermöglichen.

Das Ganze funktioniert natürlich nur dann wirklich gut, wenn es gelingt, die von diesen beiden Teamtypen verwalteten Bereiche als Service für andere Teams zur Verfügung zu stellen.

Ich hoffe, ich konnte Dir die Probleme vermitteln, die durch (unbedachte) teamübergreifende Kollaboration entstehen. Optimale Teamstrukturen entstehen nur dann, wenn Du das Prinzip der Kollaboration nicht über das Prinzip der Selbstorganisation stellst. Klare Domänen und Verantwortungsbereiche für jedes Deiner Teams unterstützen Dich dabei, ein dichtes Netz von Abhängigkeiten zu vermeiden.