Dynamische Fokusteams - Erfahrungsbericht

Die Ausgangssituation

Unser Team hatte mit über 20 Beteiligten eine Größe erreicht, die ein effizientes Arbeiten unmöglich machte. Die üblichen Scrum Meetings (Refinements, Estimations, Planning, Review und Retro) dauerten immer länger und fühlten sich unglaublich zäh an. In diesen Meetings wurden viele Themen detailliert besprochen, waren aber oft nur für eine kleine Gruppe relevant.

Durch die Größe des Teams und den starken Wunsch aller schnell voranzukommen, hatte sich eine große Themenvielfalt eingeschlichen, die die Situation noch befeuert hat. Das Produktteam hatte keinen Fokus. Es wurden zu viele Dinge gleichzeitig angegangen, aber nur wenige abgeschlossen. Teilweise hat jede Entwickler:in an ihrem Thema gearbeitet. Trotzdem hat man immer wieder etwas von den Kolleg:innen gebraucht. Das hat für alle zu vielen Unterbrechungen und Kontextwechseln geführt.

Der Zustand ist in Abbildung 1 dargestellt. Die grünen Linien markieren konstruktive / produktiver Zusammenarbeit, die roten Linien sind Störungen und Unterbrechungen, die das Vorankommen des Teams behindert haben.

Durch die Vielzahl an Themen war eine echte, intensive Zusammenarbeit zwischen den Teammitgliedern fast unmöglich. Das war nicht nur ein Problem für die Leistung des Teams, sondern hat auch zu Unzufriedenheit geführt.

Es war also Zeit zu handeln. Dank der starken Bereitschaft von Chrono24 neue Dinge auszuprobieren, war es für das Team (in dem der Autor zum Zeitpunkt des Schreibens als ‘Head of Development’ tätig ist) möglich verschiedene Arbeitsweisen über einen längeren Zeitraum zu testen und schrittweise zu verbessern. Als Erstes haben wir uns gemeinsam verschiedene Skalierungsmodelle von Scrum angeschaut und uns entschieden LeSS zu testen.

Erster Lösungsansatz: LeSS

LeSS (Large Scale Scrum) [1] ist einer der Skalierungsansätze für Scrum. Vereinfacht gesagt, arbeiten hier mehrere Teams an einem Produkt mit einem Product Owner und einem Backlog, planen und reviewen gemeinsam, gehen für die Umsetzung aber in die einzelnen Teams. In unserem Fall hat das bedeutet das Produktteam in zwei gleichwertige, vollfunktionale Teams aufzuteilen.

Das klang für uns erstmal sehr gut: Wir brauchen die Themen nicht aufzuteilen und können so immer mit beiden Teams am wichtigsten arbeiten. Die Meetings werden kleiner und die Teams können sich besser fokussieren. So die Annahme.

Leider hatte die Aufteilung nicht den gewünschten Effekt, da es weiterhin viel Kommunikation zwischen den Subteams gab (siehe Abbildung 2). Es hat eine Weile gedauert, bis wir uns hier des Problems und der Ursache bewusst geworden sind.

Idealerweise sollten die Teams innerhalb des Sprints unabhängig voneinander arbeiten können, dies war aber offensichtlich nicht der Fall. Grund dafür war, dass die Themen, die in dem Team bearbeitet wurden, meist einen starken Schwerpunkt (UX / Frontend / Backend) hatten. Das führte dazu, dass beispielsweise die Backendentwickler:innen aus beiden Teams unterschiedliche Stories bearbeitet haben, die zum gleichen Thema gehörten, und sich dementsprechend abstimmen mussten. Auf der anderen Seite konnten die Frontendkolleg:innen nichts zu dem Thema beitragen und haben dementsprechend andere Tickets / Stories bearbeitet.

Durch diese Situation sind die Dailies zu einem reinen Reporting verkommen. Es war meist gar nicht relevant, was die anderen im Team machen und diejenigen, mit denen man sich hätte abstimmen müssen, waren nicht da.

Zusammenfassend lässt sich sagen: Die benötigten Skills der Themen passten nicht zu den Skills der Teams. An dieser Stelle gibt es viel Spielraum für Diskussion:

• Sollte ein Thema nicht trotzdem nur in einem Team bearbeitet werden auch wenn es dann ggf. länger dauert?
• Sollte es nicht für alle eine Möglichkeit geben zu dem Thema beizutragen? Und wenn es nur durch Tests ist?
• Ist es nicht auch okay, wenn einzelne Rollen etwas Leerlauf haben?
• Wollen wir uns in Richtung Fullstack bewegen?

Die Liste lässt sich beliebig erweitern. Vieles haben wir diskutiert. Am Ende haben wir uns für Folgendes entschieden:

• Ein Thema soll immer in einem Team bearbeitet werden.
• Die Skills im Team sollen zu den benötigten Skills passen. Wir wollen keinen erzwungenen Leerlauf und Fullstack ist in dem Kontext zzt. nicht sinnvoll machbar.

Unser Lösungsansatz, um das zu erreichen: Dynamische Fokusteams

Das stellte uns aber vor ein großes Dilemma:

Wollen wir wirklich dynamische Teams? Verletzt das nicht eine der Grundregeln von Scrum?

Das Dilemma: Stabile vs. dynamische Teams

Das Dilemma, vor dem wir standen, lässt sich wie folgt zusammenfassen:

• Um produktiv zu sein, brauchen wir feste, eingespielte Teams. (Stichwort: Tuckman Team Performance Model: Forming, Storming, Norming, Performing [2])
• Um Themen optimal bearbeiten zu können, brauchen wir flexible Teams mit den passenden Skills.

Wir müssen möglichst produktiv sein und Themen optimal bearbeiten, damit das Unternehmen langfristig erfolgreich sein kann.

Wie lässt sich dieser Konflikt lösen?

Forming, Storming, Norming, Performing. Das sind die vier Phasen durch die jedes neue Team gehen muss und erst in der letzten ist ein Team richtig produktiv [2]. Jede Änderung der Teamstruktur führt dazu, dass die Phasen erneut durchlaufen werden müssen.

Das ist eine der Grundannahmen von Scrum und spricht für stabile Teamstrukturen [3].

Ist das wirklich so?

Diese Annahme haben wir uns genauer angeschaut. Aktuelle Forschung [4] zeigt, dass Storming tatsächlich kontinuierlich über den Lebenszyklus eines Teams stattfindet. Weiterhin sollten Organisationen die Team Dynamik kontinuierlich nähren, um eine hohe Leistung dauerhaft beizubehalten. Sprich, die besten Teams kommen immer wieder in den ‘Storming’ Zustand. Dynamische Teams können - in gewissem Rahmen - also auch dazu beitragen die Leistungsfähigkeit hochzuhalten.

Weiterhin stellt sich die Frage, ob diese Phasen immer gleich intensiv sein müssen. In unserem Fall war es beispielsweise so, dass sich alle Teammitglieder gut kennen und eine insgesamt offene und konstruktive Atmosphäre herrscht. Es gibt bereits in vielen Punkten eine gemeinsame Basis und einen guten Rahmen für mehr Dynamik.

Außerdem werden nicht beliebig ‘Ressourcen’ vom Management im Unternehmen hin und her geschoben, sondern es gibt einen begrenzten Rahmen (das alte Team) in dem sich Teams formen können. Hier entscheidet das Team selbst - zu festen Zeitpunkten - wie es sich auf die Themen verteilt.

Es ist also möglich, dass die Phasen zwar durchlaufen werden müssen, dieser Prozess sich aber sogar positiv auf die Performance und Zufriedenheit der Teams auswirkt. Zusammen mit dem gewonnenen Fokus haben dynamische Fokusteams in diesem Kontext also hohes Potential.

Dynamische Fokusteams

Eines vorweg: wenn wir von einem Thema sprechen, meinen wir eine nennenswerte Erweiterung des bestehenden Produkts mit klarem Ziel, die den gesamten Discovery-Delivery Zyklus umfassen kann.

Ein Fokusteam arbeitet für 3-6 Sprints (6-12 Wochen) an einem Thema, das danach abgeschlossen (validiert und live) ist. Es ist möglich ein Nachfolgethema zu definieren. Das muss sich aber neu gegen andere, evtl. wichtigere Themen durchsetzen.

Fokusteams werden nach Abschluss ihres Themas aufgelöst. Wir schauen am Ende jedes Sprints auf den Zustand der Teams und überlegen gemeinsam für jedes Team, ob es sinnvoll ist, das Team weiterlaufen zu lassen.

Weiterhin gibt es ein Core-Team, welches das Daily Business auffängt und so den anderen Teams den Rücken freihält. Das umfasst kritische Bugs und kleinere Stories / Tickets. Dieses Team besteht dauerhaft, wird aber immer wieder neu besetzt.

Die Einführung dynamischer Fokusteams hat die Kommunikation enorm verbessert, wie in Abbildung 3 zu sehen ist. Jedes Team hat einen klaren Fokus und ein klares Ziel. Die Produktivität der Meetings (insbesondere des Dailies) hat enorm zugenommen. Wir haben Stakeholder, die bisher nur sehr sporadisch in den Prozess eingebunden waren, teilweise mit in die Teams geholt. Der Fokus hat es uns erlaubt Themen schnell umzusetzen. Die Teams fühlen sich für das Thema verantwortlich.

Die Ergebnisse werden durch eine Umfrage, die wir in den Teams durchgeführt haben bestätigt (Abbildung 4). Die Umfrage wurde einmal im Arbeitsmodus von LeSS und einmal nach der Einführung der dynamischen Fokusteams durchgeführt. Ziel war es herauszufinden wie sich die Änderung auf die Zusammenarbeit der Teams und die Qualität der Meetings auswirkt. Die Ergebnisse zeigen, dass wir einige Aspekte massiv (Daily und Ziel) und andere leicht verbessern konnten.

Fazit

Mit dynamischen Fokusteams haben wir es geschafft, die Kommunikation, die Meetings und den Fokus der Teams zu stärken. Natürlich gibt es weiterhin Verbesserungspotential. Zum Beispiel hat sich gezeigt, dass Teams ca. einen Sprint brauchen, um sich zu finden und das Thema zu durchdringen. Auch der Wechsel zwischen den Teams hat sich als etwas weniger flexibel gezeigt als ursprünglich angenommen.

Inspiriert durch Shape Up [5] arbeiten wir zurzeit daran den Scope der Themen gezielt einzuschränken und uns auf einen festen Rhythmus einzuschwingen. Von dem Konzept ‘fixed time, flexible scope’ erhoffen wir uns langfristig mehr Fortschritt bei den relevanten Themen sowie einen leichteren Wechsel zwischen den Teams.

Noch eine Warnung am Schluss: Context Matters! Nur weil wir in unserem Setup mit dieser Struktur Erfolg hatten, heißt das nicht, dass es automatisch in anderen Kontexten genauso funktioniert. Hier ist es wichtig systematisch in kleinen Schritten vorzugehen, das Team in die Lösungsfindung einzubinden und den eigenen Fortschritt zu messen.

Das Ergebnis ist eine unglaubliche Teamleistung und nur durch die Unterstützung von Chrono24 und den starken Innovationswillen aller Beteiligten, insbesondere des Teams, möglich gewesen. Ein großes Dankeschön an Jana Schumann, Rouven Schaube, Danijel Nevistic, Sven Ferber, Manfredo Lanzas und das ganze Team bei Chrono24. Ihr seid die Besten!

Referenzen

[1]: LeSS Framework

[2]: Tuckman’s stages of group development

[3]: ScrumBook.org

[4]: Acquisition Community Team Dynamics: The Tuckman Model vs. the DAU Model, Pamela Knight

[5]: Shape Up, Ryan Singer