Bessere Team-Kommunikation mit dem Team Assembly

Felix

22. April 2020

Was ist das wichtigste für jedes Team? Gute Kommunikation! Das gilt nicht nur in der Softwareentwicklung. Denn nur so kann man gemeinsam lernen, gemeinsam wachsen und schnell gemeinsam gute Ergebnisse produzieren. Wie die Technik eines Team Assembly dazu beitragen kann, wie ein beispielhafter Ablauf aussieht und was für die Moderation wichtig ist - das verraten wir euch hier.

Wir bei mindmatters arbeiten am liebsten nach der Methode des Extreme Programming (XP). Daher programmieren wir auch meist im Tandem, also im Pair. Aber das alleinige befolgen von XP-Techniken ist noch kein Garant für eine bessere Team-Kommunikation und Wissensverteilung.

Lasst uns das mal an folgendem Beispiel veranschaulichen. Vielleicht kennt ihr das ja auch:

Pair A trifft eine Entscheidung. Zum Beispiel die, eine neue Library einzubauen, die das Leben aller Anderen ebenfalls erleichtern könnte. Pair B bekommt davon aber nichts mit, obwohl es ähnliches Aufgaben zu lösen hat. In beiden Pairs stellen sich also ähnliche oder sogar dieselben Fragen, die unterschiedlich beantwortet werden - im Zweifel an manchen Stellen zu Lasten der Qualität. Auch die jeweils zugehörigen Teams sind so nicht auf dem gleichen Wissensstand. Was in solchen Fällen fehlt, ist nicht der Wille zur Kommunikation, sondern die Gelegenheit.

Um hier systematisch Kommunikations-Lücken vorzubeugen, gibt es bei uns in vielen Teams das so genannte Team Assembly.

Das Team Assembly - was es ist und welche Vorteile es hat

Das Team Assembly ist ein täglicher Meetingslot für alle Entwickler*innen eines agilen Teams. Jede Teilnehmerin und jeder Teilnehmer kann wichtige Themen mitbringen, die im Team diskutiert werden sollen. Dabei sollten die Themen projektbezogen sein. Mit der Einführung des Team Assembly kommt aber nicht nur einfach ein neues Meeting hinzu. Vielmehr hat die Institution des Team Assembly verschiedene konkrete Vorteile:

  • das Entwicklungsteam wird offener
  • Themen werden schon proaktiv besprochen und
  • jede*r übernimmt mehr Verantwortung für das Produkt

Themen könnten beispielsweise sein:

  • Wie implementieren wir was?
  • Ein gemeinsamer Code Review
  • Fragen zur Architektur oder Technologie
  • Wie kommunizieren wir etwas?
  • Sollten noch Meinungen des restlichen Teams zu konkreten Punkten eingeholt werden?
  • Was gibt es Organisatorisches zu besprechen?

Die wichtigste Voraussetzung: Das Team muss es brauchen und wollen

Die Einführung eines Team Assembly muss eine Team-Entscheidung sein. Ein weiteres Meeting ohne Akzeptanz ist reine Zeitverschwendung. Es muss ein Problembewusstsein existieren und klar sein, warum dieses Meeting Probleme löst oder dabei hilft, potentielle Probleme von Anfang an zu vermeiden.

Themen in kleinere Pakete schneiden

Die im Team Assembly besprochenen und evt. größeren Themen sollten möglichst mit konkreten und kleinen nächsten Schritten abgeschlossen werden. Dabei sollte klar sein, wer was zu tun hat:

Eine beispielhafte Kette sieht etwa so aus:

  • Felix erstellt eine Story
  • Meike spricht mit der/dem Product Owner*in darüber
  • Timo organisiert ein Meeting mit den Devs und der/dem Agile Coach

Diese Schritte werden idealerweise zwischen dem aktuellen und dem nächsten Team Assembly erledigt. Betrifft das Thema auch andere Personen, sollte darauf geachtet werden, dass diese nicht übergangen werden. Ein nächster Schritt kann auch sein, eine andere Person oder Gruppe über die Entscheidungen zu informieren.

Auch in Team Assemblies kann delegiert werden – in andere Meetings, Gruppen oder Aufgaben

Das Team Assembly soll nicht alle Probleme lösen. Stößt das Team auf ein größeres Thema, sollte es entscheiden, ob das Team Assembly der geeignete Ort dafür ist, oder ob es an anderer Stelle oder mit anderen Teilnehmern besprochen werden muss. Geeignete andere Orte oder Aufgaben können beispielsweise sein:

  • eigenes themenbezogenes Meeting
  • eine neue Aufgabe im normalen Entwicklungsprozess
  • ein Spiking
  • eine Retro

Die Moderation des Team Assembly

Für ein effizientes und effektives Meeting sorgt ein*e Moderator*in. Diese Rolle wird durch ein Teammitglied ausgefüllt. Dabei kann es sinnvoll sein, dass rotiert wird.

Die moderierende Person führt durch die Agenda und achtet auf das Einhalten der Timeboxen. Außerdem achtet sie darauf, dass es bei den Themen eine konkrete Zielsetzung gibt und das Meeting nicht abschweift.

Warum ist der Termin täglich? Reicht nicht einmal im Sprint?

Es gibt immer wieder Themen, die nicht warten können:

Pair A arbeitet an einem Thema und möchte so bald wie möglich Input vom Team
Wir müssen uns über Thema X heute einigen und nicht erst in drei Tagen.

In der Praxis dauert das Team Assembly selten die ganze Stunde, da es bedarfsgesteuert ist. Wenn aber ein Thema dringend geklärt werden muss, können wir das innerhalb eines Tages machen.
Aber natürlich ist hier nichts in Stein gemeißelt. Für manche Teams mag es ausreichen, sich zweimal die Woche zu treffen. Wenn es dann zu Themenstaus kommt, sollte man allerdings über mehr Termine nachdenken.

Wann brauche ich das Team Assembly nicht?

Für Teams, die bereits über alles miteinander kommunizieren, ist das Team Assembly möglicherweise unnötig. Andererseits könnte diese offene Kommunikation durch viele Unterbrechungen im Arbeitsalltag erkauft worden sein. In diesem Fall könnte man mit dem Team Assembly eine höhere Fokussierung erreichen.
Meiner Erfahrung nach lohnt sich ein Team Assembly erst ab drei Entwickler*innen.

Das ist es im Prinzip auch schon: Das Team-Assembly ist wie ein täglicher Marktplatz, bei dem jede*r mit ihren/seinen Themen und Anliegen zu Wort kommen kann.

Im Folgenden nochmal ein ganz detaillierter beispielhafter Ablauf für euch.

Vielleicht hilft er euch ja, damit ihr direkt loslegen könnt.

Ein beispielhafter Ablauf eines Team Assembly

Themensammlung und Priorisierung

Die moderierende Person teilt den Bildschirm, indem das Agendadokument geöffnet und bearbeitet wird. Sie erstellt einen neuen Dokumentationsblock mit dem aktuellen Datum und sammelt Themen. Einige davon könnten schon im Bereich Nächstes Team Assembly aufgelistet sein, andere können die Teammitglieder jetzt anbringen.
Sobald die Sammlung abgeschlossen ist, wird priorisiert. Da das Meeting eine Timebox hat, kann es sein, das nicht alle Themen besprochen werden können.

Nun leitet die moderierende Person von Thema zu Thema. Dabei nennt sie den Titel des Themas und übergibt an das Teammitglied, welches das Anliegen mitgebracht hat. Während diese Person nun ihr Anliegen vorstellt, achtet die moderierende Person darauf, dass die Timebox pro Thema nicht überschritten wird.

Besprechung eines Themas

Bei der Besprechung der Themen ist darauf zu achten, dass das Team fokussiert bleibt und nicht abschweift. Jedes Teammitglied sollte bei seinem aktuellen Wissensstand abgeholt werden. Wenn möglich, sollte die Besprechung des Themas mit einem konkreten nächsten Schritt abgeschlossen werden. Dieser wird von der moderierenden Person im Agendadokument festgehalten.

Eine beispielhafte Agenda eines Team Assembly

Damit jeder das Team Assembly moderieren kann und nichts vergessen wird, enthält das Agendadokument eine Liste, die beschreibt, wie der Ablauf ist. Es gibt einen Block mit Themen für das nächste Team Assembly, in den jedes Teammitglied vor dem Termin Themen eintragen kann. Weiterhin gibt es für jeden stattgefundenen Termin einen Block mit der Liste abgearbeiteter Themen. Hier können auch die nächsten Schritte und genauere Infos zu den Themen dokumentiert werden.

Agenda

  1. Frage: Welche Themen gibt es? Welche Themen haben Priorität?
  2. Jedes Thema durchgehen. Anmoderiert von der Person in Klammern. Timebox auf 15 Minuten pro Thema.

Themen

Nächstes Team Assembly

  • Impediment Board aktualisieren (Felix)
  • Wer merged in develop? (Milena)

27.08.2018

  • Kümmern wir uns wirklich noch um den IE11? (Torben)
    -> PO sagt ja
  • Release (Felix)
    -> Axel schreibt eine E-Mail
  • E-Mail von Joachim
    -> Geht klar.

21.08.2018

  • Customer-Service Erfahrungen
  • Machen wir morgen ein Release?

14.08.2018

  • Union Types für Redux-Actions (Meike)
  • Neue Layout-Struktur (Chris)