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.

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 Daily.

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.

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.

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.

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.

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.