Mark Rehberg 21. April 2015

Agile Moves in der Praxis

Scrum: Agile Moves führen zu besserer Zusammenarbeit und fördern individuelle Skills. © depositphotos.com / TAlexey

Ein guter Anfang braucht Begeisterung, ein gutes Ende Disziplin

Seit ein paar Jahren setze ich in meiner Freizeit zusammen mit Freunden diverse Projekte in den unterschiedlichsten Bereichen um. Wir sind eine bunte Mischung aus Musikern, Psychologen, Lehrern und agilen Coaches. Alle wohnen in unterschiedlichen Locations, was die Zusammenarbeit nicht immer einfach macht und wodurch das Teamspiel zu einer ganz eigenen Herausforderung wird. So entwickelten und probierten wir Workflows aus, die uns das Zusammenspiel erleichtern sollten. Was sich zunächst als gute Idee zeigte, scheiterte dann jedoch oft daran, dass wir in der Gruppe nicht die allerbesten Teamspieler waren. Den meisten von uns fehlten dazu schlicht und ergreifend die notwendigen Skills.

Ich persönlich kann nicht unbedingt behaupten, dass mir die Fähigkeiten eines Teamspielers in die Wiege gelegt wurden. Trotzdem hat mich der Gedanke, Teil eines funktionierenden Teams zu sein, immer begeistert. Mit einfacher Willenskraft war da für mich aber meist nicht viel auszurichten. Ich lief regelmäßig und immer wieder gegen Wände, was mich nach und nach immer mehr verzweifeln ließ.

Vor etwas über zwei Jahren kam Wolfgang Brandhuber dann mit der Idee um die Ecke, dass man Teamspiel genauso trainieren kann, wie das Zusammenspiel einer Fußballmannschaft auf dem Rasen. Diese Idee hat mich von Anfang an begeistert und tut es bis heute. Mittlerweile ist aus der Idee, Teamspiel zu trainieren, mehr geworden als nur eine Idee. Es ist ein Konzept, das sich innerhalb unserer Gruppe so sehr bewährt hat, dass sie sogar in agilen Großprojekten erfolgreich eingesetzt wird, und wir dabei sind, Teamspiel in eine Open-Source-Software zu gießen, mit der Teams sich gegenseitig zu Teamspielern zertifizieren können.

Wenn ich jemandem von Trainingsmethoden erzähle, die in einem agilen Team zu besserer Zusammenarbeit führen, individuelle Skills fördern und ähnlich aufeinander aufbauen wie die einer Fußballmannschaft, löst das in den meisten Fällen erst Verwunderung aus und schlägt dann in Begeisterung um. Wenn das Training dann läuft, merkt man sehr schnell, wie schwer es ist, so einen Trainingsplan auf lange Sicht zu verfolgen. Mir selbst ging und geht es mit den Agile Moves und den immer härter werdenden Trainingsplänen immer noch so. Aber genau wie sich Schweiß und Tränen auf dem Fußballplatz rentieren, trägt ausdauerndes und hartes Training mit den Agile Moves in der ein oder anderen Hinsicht dazu bei, ein besserer Teamspieler zu werden. Das ist für uns ein guter Grund, das Konzept der Agile Moves in die Welt zu tragen.

Was sind Agile Moves?

In vielen mir bekannten agilen Teams mangelt es nicht daran, zusammen arbeiten zu wollen, sondern vielmehr an der Struktur, der Ordnung und daran, nicht zu wissen, wie Teamspiel überhaupt funktioniert. Jeder bringt seine individuellen Erfahrungen mit. Muster und Gewohnheiten, die über Jahre für den Einzelnen funktioniert haben, führen im Team plötzlich zu Verwirrungen und werden vom anderen oder von einem selbst in Frage gestellt. In einem Team von sechs Personen kann ich sicher sein, dass es in jedem Bereich der Zusammenarbeit sechs verschiedene Vorgehensweisen und Meinungen gibt. Von meinem eigenen Standpunkt aus herauszufinden, wie die anderen im Team ticken und wie ein optimales Zusammenspiel stattfinden kann? Gar nicht so einfach.

Hier kommen die Agile Moves ins Spiel:

klar umrissene Übungseinheiten,
mit einem definierten Ziel,
die iterativ „on the job“ eingesetzt werden können,
um jeweils bestimmte Facetten der Zusammenarbeit im Team zu trainieren und
so das Teamspiel und damit die Produktivität insgesamt verbessern.

Dabei gibt es Moves, die

die individuellen Fertigkeiten oder das ganze Team trainieren,
über einen längeren Zeitraum oder zeitlich begrenzt eingesetzt werden und
aufeinander aufbauen oder eigenständig angewandt werden können.

Welcher Move zu welchem Zeitpunkt für welches Team oder Teammitglied der passende ist, hängt immer von der aktuellen Situation ab. Wie bei jedem sinnvollen Sporttraining auch, muss allen Beteiligten der Sinn und das Ziel jeder Übung klar sein und niemand darf über- oder unterfordert werden.

Mit Synchronisation zur Synergie

So, wie ein Fußballspieler im richtigen Moment den Ball abspielen oder einfordern muss, so ist es in einem agilen Team notwendig, die richtigen Informationen zur richtigen Zeit weiterzugeben oder sich zu holen. Aber wie stelle ich das an?

Wenn ich vom Optimalfall ausgehe, dass ein agiles Team gemeinsam in einem Teamraum sitzt, könnte ich neu gewonnene Informationen laut ausrufen und hoffen, dass sie jeder im Team mitbekommt. "Hey Leute, ich hab diesen schlimmen Bug, der uns schon seit Wochen plagt, endlich gefixt!" Tolles Erfolgserlebnis. Vielleicht wird das Team befreit aufspringen, dem Helden zujubeln und ihm lobend auf die Schulter klopfen. Doch was, wenn andere Teammitglieder gerade tief in einer Konzentrationsphase stecken und eigentlich gerade ihren Kopf ganz woanders haben? Reiße ich jemanden aus seiner Konzentrationsphase, weil ich weiß, er beißt sich gerade in einer Aufgabe fest und benötigt meine neu gewonnene Information oder störe ich vielleicht nur?

Tomaten-Tango

Um konzentriert fokussiert über einen bestimmten Zeitraum an einer Sache zu arbeiten, hat sich für mich persönlich die Pomodoro-Technik von Francesco Cirillo [1] bewährt. Zeitscheiben eignen sich aus meiner Erfahrung auch hervorragend für ein konzentriertes Arbeiten im Team.

Das Team blockt sich einen möglichst langen Zeitabschnitt des Arbeitstages, der nicht durch Meetings unterbrochen wird, um gemeinsam im Teamraum zu trainieren.
Außerhalb des Teamraums wird gekennzeichnet, dass das Team gerade nicht gestört werden möchte.
Paare werden gebildet, die gemeinsam an einer klar definierten Aufgabe arbeiten wollen.
Die Paare setzen sich ein Ziel, welches sie in 50 Minuten erreicht haben wollen und teilen dies in einem kurzen StandUp-Meeting allen im Team mit.
Über einen TimeTimer [2], der für alle im Teamraum sichtbar sein sollte, wird die erste Hälfte des Tangos (25 Minuten) gestartet und die Paare legen mit der Arbeit los.
Kommunikation findet in diesen 25 Minuten nur innerhalb der Paare statt.
Nach Ablauf der 25 Minuten erfolgt ein kurzer fünfminütiger "Boxenstopp" während dem sich die Paare untereinander austauschen, ob sie noch "On Track" sind oder ihnen Informationen fehlen, bzw. ob sie neue Erkenntnisse gewonnen haben, die für andere nützlich sein könnten.
Anschließend wird der TimeTimer wieder auf 25 Minuten gestellt und die Teams arbeiten weiter in ihren Paaren.
Nach erneutem Ablauf der Zeit tauschen sich die Paare wieder untereinander aus, ob und wie sie ihre Ziele erreicht haben oder nicht. Auch dies sollte wiederum nicht länger als fünf Minuten dauern.
Anschließend hat sich eine zehn-minütige Pause bewährt, in der sich alle bei Bedarf weiter austauschen können und auch schon über weitere Ziele gesprochen wird.
Nach Ablauf der Pause geht der Tango wieder von vorne los.

Bei diesem Move hat es sich bewährt, von den ursprünglichen 25 Minuten einer Tomate abzuweichen und den Zeitraum zu verlängern. Längere Build-Zeiten oder tiefere Codeanalysen haben oft zu Unterbrechungen geführt, als die Paarungen gerade im Flow angekommen waren. Den Zeitraum zu verlängern hat sich ebenfalls als Kontraproduktiv herausgestellt, da es vermehrt zu Konzentrationsproblemen kam und es immer schwieriger wurde, den Fokus geschärft zu halten. Die Kommunikationsregel, dass während der 25 Minuten-Phasen nur innerhalb der Paare gesprochen werden darf, sollte tatsächlich nur in Ausnahmefällen gebrochen werden, da ansonsten die anderen Paare ebenfalls gestört werden und aus dem Flow kommen.

Meine Erfahrung ist, dass ein Team, das über einen längeren Zeitraum mit dem Tomaten-Tango trainiert, unerwartete Synergien entwickelt, dadurch neue Energien freisetzt und diesen Mehrwert sehr schnell erkennt und verinnerlicht.
Empfehlen würde ich, mit einem oder maximal zwei Tomaten-Tangos pro Tag zu beginnen und das Trainingspensum nach und nach auf bis zu vier, maximal fünf Tangos zu erhöhen.

Die größten Herausforderungen für diesen Move, sind nach meiner Erfahrung, Meetings und Störungen von außerhalb, die das Team von einer längeren kontinuierlichen Zusammenarbeit abhalten, so dass entsprechende Vorkehrungen, wahrscheinlich auch im Projektumfeld notwendig sind, um diesen Move erfolgreich zu trainieren.

Schnelligkeit durch Transparenz

Ein weiterer wesentlicher Bestandteil für funktionierendes Teamspiel ist Transparenz. Die Kunst, zu jedem Zeitpunkt des Tages zu wissen, was jeder im Team gerade tut oder wo er sich gerade aufhält.

In einem agilen Team bietet es sich geradezu an, das Teamboard hierfür in den Mittelpunkt zu stellen und es als Transparenzwerkzeug Nummer Eins zu deklarieren. Im Grunde ist es erstmal ganz einfach: Alles, was im Team passiert oder das Team betrifft, wird nicht in irgendwelchen Excel-Sheets oder anderen Dokumenten vergraben, sondern am Teamboard visualisiert. Termine, Fragen, Themen für die Retro, Aufgaben, Störungen, Impediments, und, und, und. Um durch diese "gnadenlose" Transparenz Schnelligkeit zu gewinnen, lassen sich diverse agile Moves perfekt kombinieren. So lassen sich automatisch noch eine ganze Reihe anderer Faktoren trainieren, die sich letztendlich alle auf die Schnelligkeit des Teams auswirken.

Ein Beispiel:

Abb.1: Das Teamboard als Transparenzwerkzeug Nummer Eins. © Milenko Bugueno

Von Daily zu Daily

Alle Tasks am Teamboard [3] repräsentieren eine Aufgabe, die für eine Person oder ein Paar nicht länger als einen Tag dauern darf. Ausschließlich solche Tasks sind am Teamboard erlaubt. Zu große Aufgaben müssen runtergebrochen werden.
Um eine optimale Übersicht über alles, was im Team passiert, zu gewährleisten, sollte das Teamboard überdimensional groß angelegt werden. Aus meiner Erfahrung ist eine komplette Teamwand nicht genug, hat man erst mal den Sinn verinnerlicht und Spaß an der Visualisierung. Der Spaß, mit dem Teamboard zu arbeiten, ist dabei ein wesentlicher Faktor. Ich habe schon viele schlampig angelegte Boards gesehen, mit denen es keinen Spaß gemacht hat, zu arbeiten. Wie bei einer guten Software steht natürlich die Funktionalität im Vordergrund, doch eine nette Benutzeroberfläche mit ansprechenden Farben macht die Benutzung um Einiges angenehmer.
Im Daily Scrum [4] verpflichtet sich eine Person oder ein Paar, diese Aufgabe(n) bis zum nächsten Daily Scrum zu erledigen.
Ist ein Task, für den ein Commitment abgegeben wurde, beim nächsten Daily noch nicht erledigt, sollte es dafür einen guten Grund geben.
Dieser Grund wird auf einen Klebezettel geschrieben und durch eine "Pain Snake" [5] visualisiert.
Diese Gründe werden in einer wöchentlichen Retro thematisiert, die Zettel werden abgenommen und konkrete Maßnahmen beschlossen.
Die "Pain Snake" sollte im Laufe der Zeit immer kürzer werden, so dass das Team sich nach und nach auf die täglichen Verpflichtungen verlassen kann und mehr und mehr an Sicherheit gewinnt.
Eine Kennzahl für den Trainingsfortschritt des Teams könnte die Anzahl der Post-Its in der "Pain Snake" pro Woche sein. Wenn sich das Team verbessert, sollte diese Anzahl zunächst über einige Wochen sinken und sich dann auf niedrigem Niveau stabilisieren.

Werden Störungen nicht regelmäßig thematisiert und im Team besprochen, werden sie für Teams irgendwann als "normal" angesehen. Das Team lernt, mit den Schmerzen zu leben und vorhandene Blocker rein aus Gewohnheit zu umschiffen. Dies hat unmittelbare und langfristige Auswirkungen auf Geschwindigkeit und Motivation. Die Wahrnehmung dafür zu schärfen und diese Punkte nicht im allgemeinen Projekttrubel untergehen zu lassen, ist ein wesentlicher Faktor bei der Optimierung des Teamspiels.

Eine weitere Trainingsmöglichkeit um durch Transparenz Geschwindigkeit zu gewinnen:

Abb.2: Avatar + Work in Progress. © Milenko Bugueno

Avatar + Work in Progress

Diese Move-Kombo ist angelehnt an diverse Kanban-Techniken [6]

Jedes Teammitglied bastelt sich einen persönlichen Avatar, den es am Teamboard gut sichtbar befestigt.
Es liegt an dem Team, sich gleich ein Motto oder einen Namen zu geben, so dass die Avatare in einem einheitliche Kontext stehen. Nach meiner Erfahrung gibt es ein runderes Bild, wenn man z. B. nur Peanuts oder Simpsons-Charaktere verwendet und es macht außerdem ein Heidenspaß, wenn die Charaktere verteilt werden und Gemeinsamkeiten mit den Teammitgliedern auffallen.
Die Avatare repräsentieren zu jedem Zeitpunkt die jeweilige Aufgabe, an der sich jemand befindet und werden bei Taskwechsel von der zugehörigen Person umgehängt.
Auf dem Teamboard werden für den Bereich "In Arbeit" Felder visualisiert, auf die die Aufgabenzettel geklebt werden können. Dabei ist zu beachten, dass es unbedingt weniger Felder sein müssen als Teammitglieder im Team.
Bewährt hat sich
   - 7 Teammitglieder = 4 Taskbereiche
   - 5 & 6 Personen = 3 Taskbereiche
   - 4 Personen = 2 Taskbereiche
Immer mit der Option, ein weiteres Zusatzfeld "aufzumachen", um zu verhindern, dass es bei Sonderfällen zu Verzögerungen kommt.
Diese Felder repräsentieren das WIP (Work in Progress)-Limit.
Es darf im Team nur an Tasks gearbeitet werden, wenn sich die Aufgabe in einem der Bereiche mit mindestens einem Avatar befindet.
Ziel ist es, Aufgaben immer in Paaren zu erledigen, um Synergien auszunutzen und den Wissensaustausch zu fördern.
Alle Paare arbeiten im Modus des oben beschriebenen Tomaten-Tangos oder wenn das Team noch nicht so eingespielt ist empfiehlt es sich, eine sogenannte Pairprogramming-Matrix zu verwenden – eine einfache Tabelle, in der man vermerkt, wer im Team mit wem wie oft Pair-Programming gemacht hat.

Mit dieser Move-Kombo gelingt es, dass jeder im Team zu jedem Zeitpunkt weiß, was im Team aktuell passiert. Dies schafft zum einen Sicherheit, aber es vermeidet auch, dass ständig die berühmte Frage im Raum steht: "Was machst du gerade?" Ein Blick auf das Teamboard reicht aus, um sich an bestehende Paare im wahrsten Sinne des Wortes dranzuhängen und mitzuarbeiten.

Auch der Workflow der Zusammenarbeit wird durch die Begrenzung des WIP deutlich verbessert, da die einzelnen Teammitglieder geradezu zur Zusammenarbeit "gezwungen" werden. Außerdem wird es immer klarer, wie sehr es das Team behindert, wenn eine Aufgabe zu groß geschnitten ist und tagelang einen WIP-Bereich blockiert. Ich empfehle immer, mit einem möglichst niedrigen WIP-Limit zu beginnen, um genau solche Probleme sichtbar zu machen und nach Lösungen dafür suchen zu müssen.

Mit weiteren Ausbaustufen, wie einen Terminbereich am Board zu visualisieren, so dass immer klar ist, wo sich die Teammitglieder am Tag befinden, wenn sie sich mal länger nicht im Teamraum aufhalten, habe ich ebenfalls sehr gute Erfahrungen gemacht.

Weitere Möglichkeiten wären z. B.:

WIP-Eingrenzung für die Reviewspalte.
Verpflichtungsspalte für die Aufgaben, die bis zum nächsten Daily Scrum noch erfüllt sein sollen.
Wartespalte für Aufgaben, die derzeit nicht erledigt werden können.

Die Königsdisziplin der agilen Zusammenarbeit

Beim Training täglich dran zu bleiben, kann hart sein. Ohne Disziplin ist das beste Training nach ein paar Wochen wieder hinfällig und man muss im Grunde wieder von vorne beginnen. Wie beim Ausdauertraining bauen sich Muskeln und Kondition bei längerem Nichtstun schnell wieder ab. Beim Training mit den Agile Moves ist es nicht viel anders.

Um tiefgreifenden Erfolg zu haben, hilft es aus meiner Sicht, die Moves immer wieder ein wenig anzupassen und neue Elemente in die Kombinationen hineinzubringen. Wie beim Fußballtraining macht es auch einfach mehr Spaß, wenn Übungen abwechslungsreich gestaltet sind. Wichtig dabei ist, dass die Ziele nicht aus den Augen verloren werden und bei neuen Kombinationen der Sinn des eigentlichen Moves nicht verloren geht.

Kein Fußballspieler fängt an, Passspiel mit einem Fallrückzieher zu trainieren

Lang anhaltende Trainingserfolge zu erzielen benötigt Zeit. Einen Move langsam, mit schaffbaren, scheinbar einfachen Schritten zu beginnen, ist aus meiner Sicht unbedingt notwendig. Kein Fußballspieler fängt an, Passspiel mit einem Fallrückzieher zu trainieren. Die Kunst als Coach ist es, ein angemessenes Maß für das Team zu finden.

Hat eine Mannschaft erstmal den Mehrwert erkannt und sich nach und nach an ständig wechselnde Trainingskombinationen gewöhnt, sind die weiteren Trainingsmöglichkeiten aus meiner Sicht unbegrenzt. Irgendwann gemeinsam mit dem Team an Übe-Möglichkeiten zu feilen und nach neuen Moves zu suchen, die dann alle gemeinsam mit dem Trainer durchgeführt werden, ist für mich die Königsdisziplin der agilen Zusammenarbeit. Im letzten Team, wo ich die Agile Moves verwendet habe, ist die Velocity (Geschwindigkeit) in Storypoints von durchschnittlich 20 nach bereits 4 Sprints auf 30, dann 35 und danach auf über 40 Punkte gestiegen. Und die Tendenz zeigt noch weiter nach oben.

Ausblick

So wie die Agile Moves während des Trainings in ständiger Bewegung sind, so steht die Weiterentwicklung dieses Konzeptes ebenfalls nicht still und es entstehen täglich immer neue Ideen und Anwendungsmöglichkeiten.

In unserer Gruppe arbeiten wir gerade an Folgendem:

Entwicklung eines Teamtools, um die Zusammenarbeit in Teams über eine Software zu tracken.
Lernkarten
   - zum Trainieren von Augenhöhe im Team,
   - zum Erlernen der Tomatentechnik und
   - um Meetings effizienter zu gestalten.
Darüber hinaus adaptieren wir die Agile Moves in der Musik für instrumentales Üben und um neue Wege in der Grundschulpädagogik einzuschlagen.

Ich freue mich schon darauf, die Agile Moves in weitere Teams zu tragen und jeden Tag aufs Neue von ihnen überrascht zu werden und damit neue Dinge über Teamspiel zu lernen.