Dynamische Teamstrukturen - Pattern oder Anti-Pattern?

Sind flexible Teamstrukturen gut oder schlecht?

Auf der einen Seite wünscht sich (meist) das Management Flexibilität bei den Teamstrukturen, damit die richtigen Leute an den wichtigsten Themen arbeiten können. Auf der anderen Seite ist Stabilität über einen längeren Zeitraum notwendig, um ein Hochleistungsteam zu entwickeln.

Was machen wir mit diesem Zielkonflikt?

Flexibilität - Woher kommt der Wunsch?

Der Bedarf Teams flexibel zusammenzustellen entsteht genau dann, wenn die Skills zur Bearbeitung eines Themas nicht zu den Skills des Teams passen.

Beispiel (Abbildung 1): Das neue Thema hat einen geringen gelben und einen hohen roten Anteil an Aufgaben. Das Team besteht aus 3 gelben und einem roten Mitglied. Wenn sich an der Aufgabe und der Teamzusammensetzung nichts ändert, führt das zwangsläufig zu einer Überlastung von rot und einer Unterforderung von gelb.

Es gibt jetzt verschiedene Möglichkeiten darauf zu reagieren:

• Leerlauf akzeptieren. Das Thema wird in dem Team bearbeitet, auch wenn es länger dauert und einzelne Teammitglieder nichts oder nur sehr wenig dazu beitragen können. Unsere Erfahrung: Leerlauf fällt allen schwer, da jeder etwas Sinnvolles zum Teamziel beitragen möchte. Oft werden dann andere Dinge gestartet, was zu einer Defokussierung führt.

• Das Team findet Möglichkeiten für alle etwas beizutragen, zum Beispiel durch Tests, Nutzerinterviews oder andere Tätigkeiten. Unsere Erfahrung: Das ist nur begrenzt möglich. Leute wollen in ihrem Kompetenzbereich arbeiten und suchen vornehmlich dort Aufgaben. Hier besteht ebenfalls das Risiko einer Defokussierung.

• Entwicklung der Teammitglieder, sodass gelbe Mitglieder auch rote Aufgaben übernehmen können (Stichwort Fullstack). Unsere Erfahrung: Das ist nicht in jedem Team und jeder Codebasis ohne weiteres möglich und nicht jedes Teammitglied möchte das.

Also bleibt die naheliegende Lösung, das Team entsprechend der Anforderungen der Aufgabe zusammenzustellen.

Dynamische Teamstrukturen als Anti-Pattern

Die Autoren von Team Topologies - Matthew Skelton und Manuel Pais - beschreiben dynamische Teamstrukturen als Antipattern [1]:

“The other common anti-pattern is shuffling team members. This leads to extremely volatile team assembled on a project basis and disassembled immediately afterward, perhaps leaving one or two engineers behind to handle the “gardening” and maintenance phases of the applications(s).”

Dem können wir in dem hier beschriebenen Szenario nur zustimmen.

Für ein neues Projekt / Thema wird vom Management aus einem Pool aller Mitarbeiter ein Team mit den passenden Skills zusammengestellt. Das Team existiert nur für den Projektzeitraum und wird danach aufgelöst. Die Maintenance bleibt an ein oder zwei Engineers hängen.

Das hat unter anderem folgende Wirkung:

• MitarbeiterInnen fühlen sich fremdbestimmt, mit allen Konsequenzen: Burnout, geringe Motivation, keine Ownership.
• Es gibt keinen Fokus auf eine Domäne / einen Bereich, um dort wirklich hohe Expertise zu entwickeln.
• Es gibt keine (oder nur eine sehr lose) persönliche Bindung zwischen den KollegInnen im Team.
• Es gibt keine Identifikation mit dem Produkt, dem Team und dem Code.
• Zu guter Letzt entstehen keine eigenen Ideen aus dem Team.

Das bring uns zu der Frage: Gibt es eine Möglichkeit flexible Teamstrukturen zu nutzen, ohne diese unerwünschten Nebenwirkungen in Kauf nehmen zu müssen?

Dynamische Teamstrukturen als Pattern

Eine Möglichkeit, viele der oben genannten Nachteile aufzulösen, besteht in einem festen Rahmen, in dem sich Teams formen und wieder auflösen können. Die folgenden Rahmenbedingungen haben sich für uns als hilfreich erwiesen:

• Die Flexibilität erfolgt nur ein einer Gruppe von ca. 30 Personen in der sich alle Beteiligten gut kennen und die persönlichen Beziehungen bereits vorhanden sind.
• Es gibt eine abgegrenzte Domäne mit klarem Zweck (Purpose), für die die gesamte Gruppe verantwortlich ist.
• Durch die Domäne ist auch eine klare Ownership des Codes gegeben.
• Teams entstehen selbstbestimmt, z.B. durch Self Selection.
• Es gibt einen festen Takt, nach dem die Aufteilung erfolgt, z.B. 3 Monate angelehnt an den OKR-Rhythms des Unternehmens.

Abbildung 3 zeigt an einem Beispiel, wie dynamische Teams funktionieren können.

Die gesamte Domäne, in der das Unternehmen aktiv ist, ist in drei unabhängige Subdomänen unterteilt. Jede Domäne hat ihren eigenen Code-Bereich und ihre eigenen Teams mit allen Skills die notwendig sind, um in dieser Domäne produktiv zu sein.

Jede Domäne hat ca. 30 Teammitglieder mit denen drei bis vier crossfunktionale Teams gestartet werden können.

Die Domäne teilt sich im Rahmen einer Self Selection auf die drei bis vier Themen auf.

Unsere eigenen Erfahrungen mit dynamischen Fokusteams bei Chrono24 haben wir hier beschrieben.

Fazit

Um dynamische Teamstrukturen ermöglichen zu können, braucht man einen festen, klar abgesteckten Rahmen, in dem sich Teams selbstbestimmt formen können. Nur dann kann man die größten Nachteile aushebeln und von der Flexibilität profitieren.

Nichtsdestotrotz sind dynamische Teamstrukturen immer nur die zweite Wahl, wenn - wie in schnell wachsenden Unternehmen - feste Teamstrukturen nicht sinnvoll möglich sind.

Referenzen

[1]: Team Topologies