Über unsMediaKontaktImpressum
Dr. Wolfgang Brandhuber 01. Dezember 2014

Agile Moves: Agilität trainieren

Um Agilität nicht nur als Regelwerk zu verstehen muss man eine eigene Trainingsphilosophie entwickeln. © depositphotos.com / kjpargeter
Um Agilität nicht nur als Regelwerk zu verstehen muss man eine eigene Trainingsphilosophie entwickeln. © depositphotos.com / kjpargeter

Agile Entwicklung, so wie sie mir beigebracht wurde, hatte ein großes Problem: Es war ein Regelwerk und kein Trainingsplan. Egal ob in Büchern, Seminaren oder in Diskussionen im Projektalltag – überall wurden Regeln vermittelt, wie z.B. Scrum zu spielen war, aber nie der Weg, um Teams oder Projekte dort hinzubringen.

Als begeisterter Fußballer und Jugend-Trainer wäre ich vermutlich nie auf die Idee gekommen, mit Kindern und Jugendlichen von Punktspiel zu Punktspiel zu fahren und ihnen zwischen den Spielen Fußball als Sammlung von Regeln näher zu bringen. Ohne Trainingseinheiten, ohne die kontinuierliche Verbesserung der eigenen Fähigkeiten, ohne mehr in die Mannschaft und ihre Taktik hineinzuwachsen, würde Fußball viel von seinem Reiz verlieren. Als ich vor einiger Zeit Übungseinheiten für das nächste Fußballtraining im Kopf durchging, kam mir die Idee, dass es genau solche Übungseinheiten auch für agile Teams geben sollte. Trainingspläne, um die eigenen agilen Fähigkeiten und das Teamspiel kontinuierlich zu verbessern.

Unter dem Namen „Agile Moves“ habe ich mir zusammen mit anderen agilen Coaches viele Dutzend Trainingseinheiten ausgedacht, gesammelt und in verschiedenen Projekten über mehr als zwei Jahre ausprobiert. Wie beim Tanzen oder im Kampfsport werden zuerst einfache „Moves“ trainiert, die mit zunehmender Fertigkeit erweitert und später zu komplexeren Choreographien zusammengesetzt werden.

Die beiden Seiten der Produktivitäts-Medaille

So wie man alles, was im Fußball passiert, grundsätzlich in Offensiv- und Defensiv-Spiel einteilen kann, also in das Spiel mit und ohne Ball, lässt sich die Produktivität eines Teams immer aufteilen in Ideen und Zeit:

  • Je besser die Ideen, die ich habe, wie etwas umgesetzt werden kann, um so schneller komme ich voran.
  • Je mehr Zeit ich investiere, um so mehr werde ich produzieren.

Zeit zu investieren ohne gute Ideen wird mich meinem Ziel genauso wenig näher bringen wie tolle Ideen zu haben, aber keine Zeit sie umzusetzen. Um also meine Produktivität und die des Teams zu steigern, brauche ich zuallererst Trainingspläne für diese beiden Bereiche.

Ideen Moves

  • Ein möglicher erster Schritt, um mehr und bessere Ideen zu generieren, wäre, meine eigenen Ideen konsequent aufzuschreiben: Ideenbuch, Kärtchen, Post-Its. Je mehr Ideen ich aufschreibe, um so mehr Platz schaffe ich in mir für neue Ideen und um so mehr neue Ideen kommen nach.
  • Wenn ich meine Ideen in einem nächsten Schritt in ein geeignetes Teamtool (z.B. ein Blog) schreibe, um den Ideenfluss im Team zu verbessern, kann jedes Team-Mitglied meine Ideen kommentieren.
  • Ein weiterer Trainingsschritt könnte sein, dass jeder im Team alle Ideen in ein Team-Blog schreibt und jeder andere im Team zusätzlich zum Kommentar die Idee mit 1 bis 5 Sternen bewerten kann. Aus der kumulierten Anzahl der Sterne ergibt sich automatisch eine Liste der besten Ideen im Team.
  • Eine Übungseinheit, die darauf aufbaut, könnte sein, dass sich das Team einmal pro Woche zusammensetzt, die Ideen mit den meisten Sternen diskutiert und damit ein "Idea Board" befüllt, in dem alle geplanten Veränderungen, die aus diesen Ideen hervorgehen, genauso priorisiert aufgelistet werden wie UserStorys in einem Product Backlog in Scrum.
  • In Projekten mit mehr als einem Team können zusätzlich alle teamübergreifenden Ideen aus allen Idea Boards im Scrum of Scrums Meeting [1] in einem Project Idea Board konsolidiert werden.

Jeder einzelne „Move“ braucht Zeit, nach meiner Erfahrung zumindest zwei Wochen, um nicht mehr nur mechanisch Vorgaben abzuarbeiten, sondern um ein Gefühl dafür zu entwickeln, was genau jeder Move im Projektalltag verändert. Wenn das Team in Sprints arbeitet, bietet es sich an, jeden Move über einen Sprint einzuüben, in der Retro über die Veränderungen zu diskutieren und für den neuen Sprint neue Moves festzulegen. Der sicherste Weg, um ein Projekt so effizient wie möglich zu führen, ist, als Entscheidungsgrundlage immer die besten Ideen aller Projektteilnehmer vorliegen zu haben. Im Grunde eine Binsenweisheit, aber für die meisten Projekte, mit denen ich bisher in Kontakt gekommen bin, noch nicht mal ein Ziel am Horizont.

Tomaten Moves

Eine hervorragende Technik zum Zeitmanagement ist die Pomodoro- oder Tomatentechnik von Francesco Cirillo [2]. Die Grundidee dieser Technik ist, die eigene Arbeit in vorher festgelegte Zeiteinheiten, sogenannte Tomaten, aufzuteilen und zwischen diesen Zeitblöcken Pausen einzuplanen.

  • Als erste Trainingseinheit hat sich bewährt, eine Wahrnehmung dafür zu entwickeln, wieviel ich z.B. in 10 oder 25 Minuten schaffe.
  • Im zweiten Schritt – wenn ich schon ein Gefühl für meine Kapazität entwickelt habe – nehme ich mir vor Beginn einer Tomate ein Ziel vor, das ich versuche innerhalb eines vorgegebenen zeitlichen Rahmens zu erreichen.
  • Wenn ich vor Beginn einer Tomate mein festgelegtes Ziel und am Ende das erreichte Ergebnis team-intern blogge, können alle Teammitglieder jederzeit nachlesen, woran ich gerade arbeite, was aktuell gut läuft und wo meine Schwierigkeiten liegen.
  • Ein weiterer Trainingsschritt wäre, mich am Vorabend oder am Anfang des Tages hinzusetzen und sowohl die Anzahl meiner Zeitblöcke zu planen, die ich an diesem Arbeitstag zur Verfügung haben werde, als auch die Ziele jeder einzelnen Tomate festzulegen.
  • Wenn ich mich mit Tomaten-Tagseplänen sicher fühle, kann ich auf Wochenpläne erhöhen.
  • Um das Teamspiel zu stärken, kann ich meine Tomatenpläne vorab bloggen und bewerten lassen. Dadurch weiß jeder im Team woran ich vorhabe zu arbeiten und wann etwas voraussichtlich fertig wird. Teammitglieder können Tipps geben, was aus ihrer Erfahrung bei bestimmten Arbeiten zu beachten ist. Sackgassen können erkannt werden, bevor jemand Arbeit investiert und die Aufgaben im Team lassen sich leichter aufeinander abstimmen.

Auch für einen Tomatentrainingsplan gilt: Training braucht Zeit.

Erfahrungsgemäß braucht das Tomaten-Training deutlich mehr Zeit als die Arbeit mit Ideen. Mit einer Tomate pro Tag zu beginnen und den Rest des Alltags wie gewohnt abzuarbeiten reicht als Übungseinheit für einen Sprint locker aus, wenn ich durch mein Training nicht Gefahr laufen möchte, dass meine Produktivität erst mal sinkt. Jeden Sprint eine Tomate pro Tag mehr hinzuzunehmen ist nach meinen Erfahrungen ein guter Trainingsfortschritt. Vier Tomaten zu 25 Minuten an einem 8-Stunden-Arbeitstag hinzubekommen ist ein guter Wert, sechs wäre spitze. Mehr ist vielleicht an einzelnen Tagen möglich, als Durchschnittswert über mehrere Wochen hinweg aber aus meiner Erfahrung unrealistisch. Austausch mit Kollegen, Meetings und die normalen Gegebenheiten des Projektalltags nehmen in der Regel mehr als die Hälfte meiner Arbeitszeit in Anspruch.

Diese beiden Vorschlagslisten für Ideen- und Tomaten-Trainingspläne sind nur ein kleiner Ausschnitt von vielen Dutzend Trainingseinheiten aus allen Bereichen des Projektalltags, die wir in vielen Projekten selbst ausprobiert haben. Wichtig für die Motivation des Teams ist, dass jeder einzelne Move genau auf die Bedürfnisse des Teams zugeschnitten ist und innerhalb weniger Wochen eine spürbare Verbesserung eintritt.

Meeting Moves

Ein Beispiel für einen Trainingsplan aus einem völlig anderen Bereich des Projektalltags sind die Meeting Moves. Um die Effizienz der Meetings zu verbessern, mehr aus jedem Meeting mitzunehmen und dadurch die Anzahl der Meetings zu reduzieren, könnte z.B. folgender Trainingsplan helfen:

  • Vor jedem Meeting wird eine Agenda an alle Beteiligten verschickt.
  • Die Ergebnisse jedes Meetings werden schriftlich zusammengefasst und an alle Beteiligten geschickt.
  • Um Flurfunk vorzubeugen, werden die Ergebnisse vor Ende jedes Meetings für alle Teilnehmer transparent protokolliert und verschickt, bevor der erste Teilnehmer den Meetingraum verlässt.
  • Meetingergebnisse werden nicht nur an alle Teilnehmer geschickt, sondern projektweit veröffentlicht, um den Informationsfluss zu verbessern und dem Flurfunk den Boden zu entziehen.
  • Auch die "geheimen" Meetings, die es nach wie vor auch in Projekten gibt, die sich den Anspruch "Agil" auf ihre Fahnen schreiben, sollen so transparent wie möglich dokumentiert werden. Wenn sich z.B. die Projektleitung zu Personalfragen trifft, muss im ersten Schritt nicht unbedingt das komplette Meetingprotokoll allen Projektteilnehmern zur Verfügung gestellt werden. Ein Eintrag, dass ein Meeting zu Personalfragen stattgefunden hat, die Länge des Meetings und die teilnehmenden Personen kann schon ein guter Anfang sein. Mit der Zeit und regelmäßigen Diskussionen über Transparenz im Projektalltag trauen sich die Teilnehmer vielleicht mehr über die Inhalte zu veröffentlichen. Auch Transparenz erfordert eine gewisse innere Muskulatur, die von Projektleitern und anderen Entscheidern erst Schritt für Schritt trainiert werden muss.
  • Alle Meetings, die länger als 30 Minuten dauern, werden in Tomaten zu 30 Minuten eingeteilt. Für jede Tomate wird ein Ziel vorab festgelegt und am Ende der Tomate wird protokolliert, ob das gesteckte Ziel erreicht wurde.
  • Alle Meetings werden zentral erfasst. Am Ende einer Woche oder am Ende eines Sprints wird projektweit veröffentlicht, wieviel Prozent der Meetings oder Personen-Stunden, die in Meetings verbracht wurden, öffentlich dokumentiert worden sind.

Ideen, um die Meetingkultur innerhalb eines Projekts zu verbessern, gibt es viele. Oft scheitern gute Ideen allerdings daran, dass zu viele Neuerungen auf einmal eingekippt und die Trainingsfortschritte nicht gemessen und bewertet werden. Wenn nur wenige oder nur ein Trainingsschritt pro Sprint verpflichtend für alle Mitarbeiter eingeführt und nicht von oben herab bestimmt wird, was sinnvoll ist, sondern die Projektmitarbeiter befragt werden, welcher Trainingsschritt aus ihrer Sicht der nächstwichtigste ist, habe ich hoffentlich eine Mehrheit der Projektmitarbeiter im Boot, bevor der nächste Trainingsschritt beginnt.

Trainingsfortschritte nicht nur während des Sprints zu messen, in dem damit begonnen wurde, sondern über drei, vier oder fünf Sprints nachzuverfolgen, hilft, die Trainingserfolge nachhaltig zu sichern. Auch dafür, wann eine Trainingseinheit soweit verinnerlicht wurde, dass sie als Teil des normalen Projektalltags wahrgenommen wird und keine weitere Nachverfolgung mehr notwendig ist, muss man sich über die Zeit hinweg erst ein Gefühl erarbeiten. Eine "Definition of Done", wie sie für User Stories in Scrum oft verwendet wird, kann auch bei Trainingseinheiten und Trainingsplänen helfen, zu verstehen, wann eine Veränderung tatsächlich im Projektalltag angekommen ist.

Selbstzertifizierung

Wesentlich mehr Spaß machen Moves mit Teamzertifizierungen. Ein oder mehrere Teammitglieder kündigen im Team an, dass sie einen bestimmten Move machen möchten und dafür vom Team zertifiziert werden wollen. Für viele der gängigen Moves haben wir bereits Zertifizierungsziele festgelegt, für Varianten oder neue Moves lassen sich im Team-Konsens schnell ähnliche Ziele formulieren.

Das Zertifizierungsziel für den ersten Tomaten-Move „Wieviel schaffe ich in einer Tomate“ ist beispielsweise: „Mache innerhalb von zwei Wochen mindestens zwölf 25-Minuten-Tomaten. Verteile Deine Tomaten auf mindestens acht verschiedene Tage und notiere Dir nach jeder Tomate, was genau Du geschafft hast.“ Wenn dieses Ziel erreicht und für alle im Team transparent dokumentiert wurde, stellt das Team eine Urkunde aus, auf der alle Teammitglieder unterschreiben. Dadurch ist zum einen für alle ersichtlich, wer bereits welche Moves trainiert hat, zum anderen wird dadurch ein team-interner Wettkampf gefördert, der viel Positives bewirken kann, solange er seinen spielerischen Charakter nicht verliert. Sollte der Wettkampf in negativen Druck umkippen, ist es wichtig, zeitnah gegenzusteuern oder die Teamzertifizierung für einige Zeit vielleicht ganz ruhen zu lassen.
Wir zertifizieren jeden Move in drei Stufen: Apprentice, Journeyman und Master oder auch Lehrling, Geselle und Meister.

  • Wer die Stufe Apprentice oder Lehrling abgeschlossen hat, weiß, was sich hinter einem Move verbirgt. Er hat erste Erfahrungen in diesem Move gesammelt und ein Gefühl dafür entwickelt, wie ihm dieser Move in seinem Arbeitsalltag weiterhelfen kann.
  • Die Zertifizierung Journeyman oder Geselle bedeutet, dass man sich in diesem Move sicher fühlt und genug Erfahrungen gesammelt hat, um andere in diesem Move anleiten zu können.
  • Für Master oder Meister ist der spezielle Move bereits so sehr Teil des Arbeitsalltags geworden, dass eine weitere Nachverfolgung keinen Sinn mehr hat. Er hat den Nutzen und die Grenzen dieses Moves verstanden und setzt ihn nach Belieben ein.

Die Art der Zertifizierung kann nicht nur das Teamgefühl stärken, sondern gibt dem einzelnen Projektmitarbeiter die volle Verantwortung für seine eigene Entwicklung in die Hand.

Um die gegenseitige Unterstützung im Team hochzuhalten und die Trainingsmotivation zu stärken, können sich auch ganze Teams für bestimmte Moves zertifizieren. Dabei entspricht das Team-Level immer dem niedrigsten Grad, den ein Teammitglied in diesem Move hat. Durch den spielerischen Wettbewerb zwischen mehreren Teams kann sich die Stimmung im Projektalltag von der Abarbeitung täglicher Routinen hin zu einer Trainingsbegeisterung konkurrierender Sportmannschaften entwickeln. Noch mehr Spaß macht das Training, wenn sich auch das Projektmanagement diesem Wettkampf stellt.

Training statt Controlling

Um Agilität nicht nur als Regelwerk zu verstehen sondern in der Tiefe zu begreifen, ist es aus meiner Sicht unumgänglich, sich vom klassischen Controlling zu emanzipieren und eine eigene Trainingsphilosophie zu entwickeln, wie dies für Sportmannschaften seit vielen Jahrzehnten gang und gäbe ist. Im klassischen Controlling werden bestimmte Messwerte definiert und in regelmäßigen Abständen Zahlen dazu erhoben, ob Vorgaben eingehalten wurden. Für die Projektmitglieder, für die das vor allem Druck bedeutet, ist diese Form der Projektsteuerung wenig motivierend. Aus meiner Sicht viel schlimmer ist aber, dass durch diese Kennzahlen eingefahrene Wege festbetoniert werden. Jede größere Änderung der Projektabläufe bedeutet immer, auch neue Kennzahlen definieren zu müssen und neue Mechanismen zu etablieren, um diese Kennzahlen zu erheben, aber am allerschlimmsten ist für das Controlling, die Vergleichbarkeit mit früheren Kennzahlen zu verlieren.

Für professionelle Sportmannschaften würde ein Controlling dieser Art den sicheren Abstieg bedeuten. Trainingseinheiten und Spiele immer nach gleichem Muster ablaufen zu lassen, würden eine Mannschaft nicht nur berechenbar machen und jeden Trainingsreiz im Keim ersticken, es würde vor allem die Motivation, von der jede Mannschaft lebt, gegen Null sinken lassen.
Geeignete Kennzahlen zu erheben ist im modernen Sport zwar unerlässlich, viel wichtiger aber ist die Fähigkeit des Trainerstabs, ein Spiel lesen zu können um daraus die richten Schlüsse für das nächste Training und die Weiterentwicklung des Teams zu ziehen.

So wenig diese Fähigkeit in unserer heutigen Arbeitswelt von Managern und Coaches verlangt wird, so sehr wird sie hoffentlich in einigen Jahren zur zentralen Fähigkeit jeder Führungskraft im agilen Bereich werden. Die Agile Moves sind meiner Meinung nach nur der Anfang, das Verständnis der Zusammenarbeit in Teams zu trainieren, um jeden Tag Teams ein bisschen besser zu verstehen und ihre Arbeitsabläufe lesen zu lernen.

IT-Tage 2017 - Agile Entwicklung

Quellen

[1] Scrum of Scrums Meeting
[2] Pomodorotechnik s. Wikipedia

Autor

Dr. Wolfgang Brandhuber

Dr. Wolfgang Brandhuber ist als IT-Berater tätig. Neben der Leitung agiler Projekte war er Entwickler, Product Owner, Scrum Master und Chief Scrum Master.
>> Weiterlesen
botMessage_toctoc_comments_929