Team Management System – Ein Fallbeispiel

Scrum setzt auf funktionierende, sich selbst organisierende Teams. Wer Scrum einsetzt kann viele Probleme und Potentiale im Team erkennen und das Team kontinuierlich verbessern. Allerdings liefert Scrum wenig Modellwissen und Methoden über Abläufe in Teams.

Das Team Management System nach Charles Margerison und Dick McCann ist ein weltweit führendes Modell zur Verbesserung von Team Performance und ist aus meiner Sicht eine hervorragende Unterstützung um mit Scrum „high performance“ Teams zu entwickeln.

Die Grundlagen habe ich hier bereitgestellt.

Das folgende Fallbeispiel beschreibt aus meiner Sicht sehr konkret die Wirkungsweise des Team Management Systems (TMS).

Die Ausgangslage

Mein Kunde hat für ein neues Projekt ein Team zusammengestellt. Scrum ist etabliert. Auf der fachlichen Seite bestanden keine Unsicherheiten – das Team hat alle Kompetenzen, die benötigt werden, um das Projekt erfolgreich abzuschließen. Auf der Seite der Arbeitspräferenzen war man sich unsicher. Außerdem wusste mein Kunde um die Bedeutung der Forming & Storming-Phase und ein TMS-Workshop ist neben der Fragestellung der Teamzusammenstellung ein sehr effektives Teambuilding Element.

Durchführung

1. Team Management Profil erstellen

Dies geschieht im Vorfeld des Workshops.
In einem Ein-Tages-Workshop wird dem Team das TMS und die Ergebnisse des Profils vorgestellt. „Theorie“ und die praktische Anwendung gehen Hand in Hand. Der Workshop läuft wie folgt ab:

2a. Die Arbeitsfunktionen

Das Scrum Team ermittelt wichtige Tätigkeiten für das anstehende Projekt und lernt die Arbeitsfunktionen und das Projekt besser kennen. Unter Arbeitsfunktionen verstehen wir die acht zentral wichtigen Tätigkeitsbereiche, die für langfristigen Team- und Projekterfolg wichtig sind.

2b. Die Arbeitspräferenzen

Danach werden die Arbeitspräferenzen erläutert. Hierzu werden die Präferenzskalen auf dem Boden ausgelegt und die Teammitglieder positionieren sich entsprechend ihrer Profilergebnisse. Das Team reflektiert die verschiedenen Präferenzen mit dem Ziel, den Wert der verschiedenen Präferenzen für das Team zu verstehen.

2c. Die Teamrollen

Im letzten Schritt der „Einführung“ in das Team Management System werden die verschiedenen Teamrollen visualisiert. Aus der Verteilung der Rollen ergeben sich viele Erkenntnisse und Handlungsmöglichkeiten für Teams. In dem konkreten Fall wurde z.B. erkannt, dass der „Kontrollierende Überwacher“ im Team fehlt.

2d. Maßnahmen

Aus den Erkenntnissen wird ein Maßnahmenplan entwickelt. Neben vielen anderen Erkenntnissen wurde in dem Workshop besprochen, wie mit der fehlenden „Kontrollierenden Überwacher“ Rolle umzugehen ist. Völlig ohne weitere Vorgaben beschloss das Team, dass es auf dem Taskboard für Überwachungsaufgaben eine eigene Task-Farbe einführen wird. Dadurch wird schnell sichtbar, wenn einer Story QS-Tasks fehlen. Durch die entstehende Transparenz können die „ungeliebten“ Aufgaben fair im Team verteilt werden.

3. Follow Up

In einem Scrum Team bietet sich die Möglichkeit an, Themen aus dem Workshop regelmäßig in den Retrospektiven aufzugreifen. Der ScrumMaster erhält von mir am Ende des Workshops hierzu konkrete Vorschläge und Anregungen. Auf Wunsch oder in Teams, die keine Retrospektiven haben übernehme ich gerne einen Folgetermin, mit dem Ziel die Erkenntnisse aus dem TMS-Workshop für einen nachhaltigen Verbesserungsprozess zu nutzen.

Fazit

Ich bekomme von ScrumMastern oft die Frage gestellt, wie sie das Team unterstützen können, Software mit hoher Qualität zu erstellen, ohne dabei in die Rolle des Kontrolleurs zu geraten und die Selbstorganisation des Teams negativ zu beeinflussen.

„Der fehlende Kontrollierende Überwacher“ war nur eine von vielen Erkenntnissen des Teams in diesem TMS Workshop. Aber der Umgang des Teams mit dem Thema zeigt sehr eindrucksvoll, wie der Workshop die Selbstorganisation des Teams unterstützt. Zu einem sehr frühen Zeitpunkt erkennt das Team potentielle Risiken und kann frühzeitig entgegensteuern – selbstorganisiert und ohne den ScrumMaster ungewollt in die Rolle des „Kontrollierenden Überwachers“ zu drängen.

Mission accomplished – Scrum Training an der Hochschule Karlsruhe

Die Mission: 4 Tage Scrum den Studenten näher zu bringen.
Die Lage:

  • Die Studenten haben gerade Ihre Prüfungszeit (inkl. der mehrwöchigen Vorbereitung) hinter sich und die Semesterferien vor sich
  • Die Erfahrung mit realen Situationen in Unternehmen fehlt vielen Studenten und damit ein wichtiger Motivationspunkt, sich mit Scrum zu beschäftigen
  • Temperaturen von deutlich über 30 Grad

Nicht gerade die günstigste Ausgangslage. Damit das trotzdem funktioniert (siehe Bild) haben wir in den letzten Jahren unser Konzept für das Training kontinuierlich verbessert.

Im Zentrum steht die Idee Scrum für die Studenten erlebbar zu machen. Bekommen die Studenten (aufgeteilt in mehrere Teams) die Aufgabe in den vier Tagen ein Produkt zu entwickeln. Nach einer kurzen Einführung geht es gleich praktisch zur Sache – mit DesignThinking Methoden soll die Produkt Idee an die Bedürfnisse potentieller Kunden angepasst werden. Im Laufe des ersten Tages entsteht die Product Vision, ein Product Vision Board, Personas und die ersten User Stories. Die Scrum Begriffe werden ganz beiläufig erklärt.

Mit diesem initialen Backlog starten die Teams in Ihren ersten Sprint. Die Entwicklung findet in Form von MockUps statt. In den Sprints lernen die Studenten nach und nach die Rollen, Meetings und Artefakte von Scrum kennen… immer in der konkreten Anwendung. Die ScrumMaster Rolle wechselt nach jedem Sprint. Beim Zeichnen des ersten Burndowns wird auch schnell der Unterschied zwischen Theorie und Praxis klar. Was theoretisch “wohlwollend abgenickt” wurde, führt dann doch zu einigen Fragen…

In den Reviews stellen die Studenten ihr Product Inkrement vor und beantworten die Fragen der kritischen Stakeholder.

Mit diesem Training schafft man auch bei schwieriger Ausgangslage gut Ergebnisse – wir bleiben aber trotzdem in der Diskussion mit den Professoren einen günstigeren Termin für das Training zu finden ;)

Training an der Hochschule Karlsruhe – neu mit Design Thinking


Auch in diesem Semester sind wir wieder an der Hochschule Karlsruhe, um den Studenten in einem 4-Tages Kurs Einblick in die Agilen Methoden zu geben. Das Ziel dieses Kurses ist es, Scrum erlebbar zu machen. Dazu entwickeln die Studenten eine Produkt Vision und setzen diese mit Scrum um (in Form von Mockups und Click Through Dummies).

In den vergangenen Kursen haben wir versucht möglichst schnell mit der Entwicklung zu starten. Das führte oft dazu, dass die Produkt Vision etwas schwach war und den Studenten rel. bald die Ideen für ihr Produkt ausgingen. Aus diesem Grund haben wir in diesem Jahr Design Thinking in den Kurs eingebaut. Design Thinking hat den Vorteil, dass es sich explizit im die Bedürfnisse der Kunden kümmert und diese in den Mittelpunkt der Überlegungen stellt.

Design Thinking ist eine Methode, den den ProductOwner dabei unterstützt:

  • eigene Annahmen zu hinterfragen
  • neue Perspektiven einzunehmen
  • den Kunden besser zu verstehen
  • neue Ideen zu generieren
  • Produkt stärker an den Bedürfnissen des Kunden auszurichten!

Elemente wie striktes Timeboxing, Iterationen und “radikale” Zusammenarbeit, Show – don’t tell, zeigen die “inhaltliche Nähe” zu agilen Methoden. Design Thinking ist aus meiner Sicht eine wertvolle Ergänzung im Agilen Werkzeugkasten und ich empfehle Design Thinking als Teil der Produktentwicklung in Scrum einzusetzen.

Barcamp Karlsruhe 2012 – Diversität pur!

20120716-213320.jpg

Am letzten Wochenende war es wieder so weit. Das zweite Barcamp in Karlsruhe fand in den Räumen der CAS statt. Da ich normalerweise auf themenspezifischen Camps zu finden bin (Agile Coach Camp, Play for Agile, Coach Camp) ist mir bei diesem Barcamp zu ersten mal die Stärke des offenen Konzepts bewusst geworden. Was auf den ersten Blick nach einer ziemlich chaotischen Themenzusammenstellung aussieht (Social Marketing, USB Hacking, User Interface Design, Japan, Abnehmen, Baby Fotos…) führt zu erfrischend anderen Diskussionen als auf themenspezifischen Barcamps. Das liegt sicherlich auch daran, dass die Besucher ein breiteres Spektrum abdecken – Diversität pur also.

Diese Erkenntnis gilt auch für Teams. Leistungsfähige Teams profitieren von Diversität.

Ich freu mich schon auf das nächste Barcamp – vielleicht in Stuttgart. Danke an die Organisatoren und die Sponsoren, die das möglich gemacht haben.