Über unsMediaKontaktImpressum
Regina Brandhuber, Dr. Wolfgang Brandhuber & Milenko Bugueno 22. September 2015

Agile Moves trainieren mit dem Teamtool

Teams sollen Spaß an ihrer Weiterentwicklung finden. © depositphotos.com / Kzenon
© depositphotos.com / Kzenon

Das Teamtool ist ein Open Source-Projekt um Teamspiel zu trainieren und messbar zu machen. Es ist ein Werkzeug für Teams, die ihre Agilität und Selbstorganisation weiterentwickeln wollen [1]. Seit Anfang 2013 arbeiten wir daran, das Agile Moves-Framework [2] in eine Software zu gießen. Dabei geht es nicht darum, einen Kontrollmechanismus für das Management zu etablieren, sondern Teams dabei zu unterstützen, Spaß an ihrer Weiterentwicklung zu finden.

Gnadenlos messen!

Nach dem Motto "Gnadenlos messen!" werden mit dem Teamtool verschiedene Aspekte der Zusammenarbeit für alle Teammitglieder transparent gemacht. Wie ein Fußball-Trainingsplatz ist das Teamtool ein Ort, an dem das Team zusammenkommt, gemeinsam trainiert und Trainingspartnerschaften entstehen. Dort werden Ideen und Freude an der Bewegung entwickelt, Individual- und Teamfähigkeiten geübt und im gegenseitigen Austausch weiterentwickelt. So kann Arbeiten einen sportlich-spaßigen Effekt bekommen. Wichtiger jedoch ist es, dem Team ein maßgeschneidertes Training zu geben, um den Anforderungen des Produkts immer besser Rechnung tragen zu können.

Wie kann das funktionieren?

Abb.1: Trainieren mit dem Teamtool. © Milenko Bugueno
Abb.1: Trainieren mit dem Teamtool. © Milenko Bugueno

Wir ordnen dem Teamspiel verschiedene Facetten zu, die alle einzeln trainierbar sind. Zum Beispiel: Wie fließen die Ideen innerhalb des Teams? Wer hat die besten Ideen und wie viele davon? Wie ist der Informationsfluss im Team? Wer arbeitet wie oft im Pärchen? Wer dokumentiert so offen, dass es für jeden anderen im Team einsichtig ist?

Jede einzelne Frage kann mit einem Agile Move beantwortet, im Teamtool abgebildet und somit messbar gemacht werden. Das Tool zeigt dem Team in kurzen Feedbackzyklen, wo es hängt, da das "Spiel" durch den regelmäßigen Abgleich und die ständig generierten neuen Informationen besser zu lesen ist. Das hilft dem Team, Sackgassen vorzubeugen, weil jeder sieht‚ wo welche Hindernisse etwas ins Stocken bringen.

Maßgeschneidertes Training holt jeden ab, wo er ist.

Abb.2: Beispiel für eine Trainingskarte. © Regina Brandhuber
Abb.2: Beispiel für eine Trainingskarte. © Regina Brandhuber

Für die Entwicklung des Teamtools verwenden wir ebenfalls das Agile Moves-Framework und erproben damit zugleich die Moves, die wir dort abbilden. So gewinnen wir Erfahrung und wissen besser, wie wir die Software umsetzen können. Wir sind also Macher und Endnutzer zugleich.

Neben der Aneignung von Domain-Wissen und dem Training von Teamspiel wollen wir uns gemeinsam so weiterentwickeln, dass mehr Spaß im Arbeitsalltag entsteht. Umso besser, wenn eine launige Software das unterstützt.

Aber wie soll jemand wissen, welchen Move er gerade braucht? Jeder im Teamtool-Team hat unterschiedlichste Hintergründe. Einige haben keine technische Ausbildung, geschweige denn Erfahrung in einem IT-Projekt. Wir haben eine große Palette an Trainingskarten entwickelt, die jeden abholen, wo er steht. Ist Pair Programming für jemanden völlig neu? Kein Problem. Es gibt eine Trainingskarte, um genau das zu trainieren. Versteht jemand nur Bahnhof bei dem Begriff "Gherkin"? Kein Thema. Es steht alles einfach erklärt mit einem Trainingsvorschlag für Anfänger auf einer Karte. Möchte jemand etwas lernen, was in keiner Trainingskarte steht? Auch kein Ding. Die Karten sind frei verfügbar, können jederzeit erweitert werden und jeder kann neue erstellen, wann immer er will.

In unserem Projekt entscheiden alle Teammitglieder beim Sprintstart selbst, anhand der eigenen Prioritäten, welche Trainingskarten er oder sie für diesen Sprint machen möchte. Es gibt auch Team-Moves, die alle betreffen und nur funktionieren, wenn eine konzertierte Mannschaftsleistung erbracht wird, wie zum Beispiel das asynchrone DailyAgile Moves trainieren mit dem Teamtool.

Und genauso wie in der agilen Entwicklung User Stories mit dem größten Kundenwert als erstes umgesetzt werden, kann jeder für sich selbst und das Team gemeinsam entscheiden, welche Trainingskarte den meisten Wert für die Teamarbeit hat. So wird genau dort trainiert, wo der Schuh drückt.

Wir gehen sogar so weit, dass alle Prozessschritte, die wir entwerfen und neu einführen, mit der Ausformulierung einer Karte und dem entsprechenden Training begleitet werden. So stellen wir sicher, dass alle abgeholt werden, weil wir uns die Zeit nehmen, jede Umstellung einzuüben. Dabei achten wir darauf, einen Schritt nach dem anderen zu gehen und den Prozess in einer Geschwindigkeit zu erweitern, die für jeden einfach mitzugehen ist, um den Fokus auf das Produkt nicht zu verlieren.

Während der Entwicklung wird zertifiziert

Abb.3: Beispiel für eine Teamzertifizierung. © Tobias Grosser
Abb.3: Beispiel für eine Teamzertifizierung. © Tobias Grosser

Und jetzt kommt der Clou: Jede Trainingskarte kann zertifiziert werden. Als "Training on the job" ist es möglich, sich zu qualifizieren und sein Fähigkeitenprofil mit verschiedenen Agile Moves-Zertifizierungen aufzupeppen. Und wie sollte eine authentische Teamspiel-Zertifizierung anders ablaufen, als dass das Team die Zertifizierungen ausstellt? Ebenso wie wir Vorlagen für Trainingskarten frei zur Verfügung stellen, gibt es eine Zertifizierung zum Ausdrucken [3], die nur gültig ist, wenn mindestens zwei aus dem eigenen Team unterschrieben haben. Und natürlich gilt: Je mehr Unterschriften desto besser, weil dadurch sichtbar wird, wie ernsthaft die Auseinandersetzung mit einem Team war.

Und der Clou vom Clou? Als Open Source-Projekt stellen wir nicht nur vorgefertigte Trainingskarten und deren Zertifizierungen bereit, sondern auch gleich die Plattform und das Team, das Zertifizierungen begleiten kann. Man kann einfach hinzukommen, wenn man Teamzertifizierungen machen möchte, aber zur Zeit kein Zertifizierungsteam zur Verfügung hat.

So wie im Fußballverein kann man unverbindlich zum Probetraining kommen und eine Schnupperstunde machen, indem man sich virtuell – zum Bespiel über Skype – in eine geplanten Pairing-Sessions oder ein Team-Meeting einklinkt und entweder einfach mal Mäuschen spielt oder gleich von der ersten Tomate [4] an vollwertig mittrainiert.

Open Process

Zusammengezählt:

  • Der Code ist Open Source,
  • die Trainingskarten sind frei verfügbar,
  • samt professioneller Layout-Schablone und
  • den Zertifizierungen zum Ausdrucken.
  • Das Team und die Tools sind für jeden offen und jeder kann immer einsteigen – egal mit welchem Vorwissen.
  • Der gesamte Prozess, wie wir ihn derzeit leben, ist öffentlich.

Hinzukommen soll die Vision des Prozesses, wie wir am liebsten zusammenarbeiten wollen, wenn wir besser trainiert sind. Das gesamte Agile Moves-Framework steht frei zur Verfügung und ist übertragbar auf jedes andere Open Source-Projekt, aber davon später mehr...

Wir pflegen einen Kalender. Alle Termine darin finden in verteilten Teams übers Internet statt und die Teilnahme ist nach kurzer vorheriger Kontaktaufnahme offen für jeden. Ebenso versuchen wir lückenlos zu dokumentieren. Alle Treffen und Arbeitstermine haben ein Ergebnisprotokoll, das öffentlich in Confluence steht [5]. Man kann sich zu jeder Zeit ein Bild über den aktuellen Stand der Diskussionen verschaffen. Die User Stories bilden wir über ein Scrumboard in JIRA ab, das ebenso öffentlich einzusehen ist.

Agile Moves umsetzen

Abb.4: Agile Moves umsetzen. © Mark Rehberg
Abb.4: Agile Moves umsetzen. © Mark Rehberg

Um uns die Arbeit nach unseren Fähigkeiten und Vorlieben entsprechend aufzuteilen, haben wir uns entschieden, das Team in drei Gruppen aufzuteilen: Die Prozess-Gruppe, die Produkt-Gruppe und die Entwickler-Gruppe. Dabei geht es uns nicht darum, die Prozessschritte auseinanderzureißen. Innerhalb der Kleingruppe werden jeweils bestimmte Aspekte des Prozesses und des Zusammenspiels übernommen und vor allem trainiert.

Wie bei einer Registerprobe im Orchester, in der sich z. B. alle Streicher alleine zurückziehen um zu proben, können innerhalb der Fachgruppe spezielle Fähigkeiten trainiert werden, die für diese Gruppe besonders relevant sind. Hinzu kommt, dass jeder, der zum Open Source-Projekt dazustößt, von einer kompletten Gruppe aufgefangen werden kann. Das Know-how sitzt nicht bei einer Person fest, sondern ist in ständigem Fluss. Viele Personen mit Fachwissen garantieren eine höhere Anzahl an Anknüpfungspunkten für Einsteiger, aber auch innerhalb des Teams fruchtbare Diskussionen.

An regelmäßigen Synchronisationspunkten spielen dann die einzelnen Gruppen wieder zusammen. Genauso wie es für jedes Register in einem Orchester nach der Probe im stillen Kämmerlein wichtig ist, das Erlernte in der Gesamtprobe zu integrieren, ist es für alle drei Gruppen wichtig, alle Erfahrung ins gesamte Team zurückzuführen. Dies geschieht im wöchentlichen Tomatenmeeting, aber auch durch die teamübergreifenden Ideen- und Tomatenmoves. Jeder im Team kann Ideen zu jedem Bereich mit den anderen teilen. Das Tool wird also nicht allein von der Produkt-Gruppe entworfen oder der Prozess nicht allein von der Prozess-Gruppe. Genauso fließen Ideen von Entwicklern in die Produktvision ein oder Ideen von Spezifizierern in den Prozess. Eine Sternebewertung priorisiert dabei die besten Ideen, die als erstes umgesetzt werden.

Mit der Dokumentation jeder Tomate und dem asynchronen Daily wollen wir den Informationsfluss anregen. Im asynchronen Daily hat jeder eine einfache Übersicht, was heute fürs Tool gemacht wurde. Man kann bei Bedarf genau nachvollziehen, welchen Inhalt welche Tomate hatte, weil im Tomatenmove eine Dokumentation, die wenige präzise Sätze umfasst, inbegriffen ist.

Innerhalb des Teams gibt es keine Sonderrollen. Für die Gruppen untereinander besteht Augenhöhe sowie auch innerhalb jeder Gruppe. Jede Gruppe trägt ihren Teil zum Teamtool bei und ist dabei durch die besondere Perspektive, die jede Gruppe einnimmt, spezialisiert. Für jeden gibt es Diskussionspartner und alles wird versucht, einstimmig zu entscheiden. Es geschieht im Abgleich mit den anderen, wenngleich jede Gruppe ihre eigenen Trainingsschwerpunkte hat.

Trainingsschwerpunkte

In der Produkt-Gruppe geht es um die Pflege der Produktvision, die Spezifikation der User Stories für die Entwickler und Behavior Driven Development (BDD) mit Gherkin [6].

Die Prozess-Gruppe erstellt die Trainingskarten, bildet die Prozessvision visuell in einem "Big Picture" ab, aktualisiert sie regelmäßig und kommuniziert sie ins gesamte Team. Sie kümmert sich um Impediments und ist Trainingsvorbild für die Einstudierung neuer Prozesse.

Die Entwickler-Gruppe arbeitet bevorzugt mit dem Pair Programming Move. Sie schreibt die automatisierten Tests und anschließend den Code.

Wir programmieren eine Single Page Applikation [7], die sich auf verschiedene Frameworks stützt: Als Frontend Framework benutzen wir AngularJS, als Backend Framework Express. Für unsere Testumgebung benutzen wir Protractor in Kombination mit Cucumber. Programmiert wird das Ganze in Javascript, HTML und CSS.

Teamtool v1.0

Abb.5: Teamtool v1.0. © Milenko Bugueno
Abb.5: Teamtool v1.0. © Milenko Bugueno

Unser Bild für eine brauchbare erste Version des Teamtools umfasst im Moment die Umsetzung des Ideen- und des Tomatenmoves [2]. Beide benötigen eine Dokumentations- und Bewertungsfunktion. Eine Sternebewertung erzeugt ein automatisch priorisiertes Ideen-Backlog, wobei die Ideen als Erstes umgesetzt werden, die am höchsten bewertet wurden.

Der Kalender ist eine weitere Ansicht in unserer Single Page Applikation. Er zeigt, wer wann welche Tomaten gemacht hat oder machen möchte. Tomaten können per drag-and-drop auf dem Tagesplan schnell und bequem angelegt werden. Ein integrierter Timer zählt die Zeit einer Tomate herunter und klingelt, wenn sie abgelaufen ist. Danach fordert das Tool zur Dokumentation auf.

Gleichzeitig sollen die Moves bereits innerhalb des Tools zertifiziert werden können. Dafür gibt es die Möglichkeit, Teams und somit ein Umfeld anzulegen, um sich gegenseitig bei den Moves zu begleiten. Für eine Zertifizierung braucht jeder mindestens zwei Teammitglieder, die ihm die einzelnen Wiederholungen mit einer Daumenbewertung absegnen oder ablehnen. Das Teamtool zeigt für jeden transparent, wieviel Zeit man selbst oder ein Kollege für die Durchführung der Moves noch hat und wie viele Wiederholungen dafür noch ausstehen. Es zählt alle durchgewunkenen Einzelmoves mit, die bei Vollständigkeit zur Zertifizierung führen.

Das Teamtool ist ein Werkzeug, das im ersten Schritt die Prozessvision abbildet und soll damit ein Gegenstück zu Scrum- oder Kanbanboards wie JIRA oder TFS werden, die entwickelt wurden, um die Produktivision abzubilden.

Übertrag auf andere Open Source-Projekte

Besonders für Open Source-Projekte könnte das Teamtool und sein gesamter Entwicklungsprozess eine Schablone sein, um sich selbst besser zu organisieren und die Einstiegshürde zur Mitarbeit wesentlich zu reduzieren. Durch den Tomatenmove ist es auch möglich, geringe Kapazitäten ins Projekt fließen zu lassen und trotzdem voranzukommen. Der Ideenmove gibt die Möglichkeit, bei jeder Entscheidungsfindung dabei zu sein. Das stärkt die Anbindung ans Projekt, weil man merkt, dass die eigene Stimme zählt und gehört wird.

Ein weiterer Vorteil ist die hohe Flexibilität, die durch das Agile Moves-Framework zur Verfügung steht, denn es erlaubt, den Prozess individuell anzupassen. Frameworks wie Scrum scheiden für Open Source-Projekte ja leider oft aus, weil schlichtweg die Strukturen fehlen, um alle Spielregeln, die Scrum vorgibt, einhalten zu können.

Derzeit arbeiten zwei Entwickler, vier Spezifizierer und zwei in der Prozess-Gruppe mit. Jede und jeder Einzelne von ihnen würde sich freuen, wenn jemand Lust bekommen würde, mitzumachen, um noch mehr Perspektiven ins Teamtool und seinen Entwicklungsprozess mit einfließen zu lassen.

nach Oben
Autoren

Milenko Bugueno

Milenko Bugueno ist Dipl.-Ing. Mechatronik. Er leitet Engineering Software-Projekte in der Prozess- und Fertigungsautomatisierung. Er ist zertifizierter Scrum Master (scrum.org & IAPM) und Product Owner (scrum.org). Außerdem ist...
>> Weiterlesen

Regina Brandhuber

Regina Brandhuber ist Diplomsängerin und Diplommusikpädagogin. Derzeit promoviert sie an der Hochschule für Musik Nürnberg und hat dort einen Lehrauftrag inne. In ihrer Dissertation bereitet sie Scrum und andere agile Methoden für...
>> Weiterlesen

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