Workshop mit einem Scrum Team - vom Setup bis zur Retro

1. Setup
2. Festlegung der Workshopinhalte
3. Auswahl geeigneter Aktivitäten
4. Testlauf
5. Durchführung
6. Nachbereitung

Ob es um einen Workshop zu einem bestimmten Thema geht oder um eine Retrospektive mit einem Team, ein solcher Termin ist vorzugsweise auf dessen Zweck und ggf. auch auf die Teilnehmer abgestimmt, um einen hohen Nutzen daraus zu erhalten.

Am Anfang wird das geplante Ziel des Termins definiert. Hier kann es Vorgaben von außen geben oder eigene Beobachtungen aus der Arbeit mit dem Team können eine Notwendigkeit für einen Workshop initiieren. Wenn beispielsweise Themen erkannt werden, welche die Gruppe beschäftigen, in denen das Team oder der Scrum Master Verbesserungspotential sehen. Oder es gibt Störfaktoren, welche ermittelt werden sollen. Ganz konkret könnten mögliche Ziele sein, die Zusammenarbeit im Team zu fördern, diese zu korrigieren oder gar zunächst erst einmal überhaupt eine Plattform dafür zu schaffen. Vielleicht arbeiten die Teammitglieder nebeneinander her oder vertrauen sich noch nicht. Ob für den Workshop ein Thema fokussiert betrachtet werden soll oder ob man es ganz bewusst eher offen halten möchte, kann essentiell für die weiteren Schritte sein.

Praxisbeispiel: Workshop zur Verbesserung der Zusammenarbeit im Team

Ich möchte gerne Einblick in einen Workshop geben, den wir mit dem Management eines Kunden initiiert haben. Die Teamstabilität war angeschlagen durch einige personelle Veränderungen. Im Team, bestehend aus Namics Entwicklern und Entwicklern des Kunden,  gab es einen kulturellen Unterschied. Die Zusammenarbeit erfolgte remote und in 4 kleinen lokalen Gruppen von 1-4 Personen. Einige kannten das Agile Vorgehen bereits, für andere war das Projekt der erste Berührungspunkt mit der Agilen Softwareentwicklung. Wir beobachteten, dass durch diese verschiedenen Faktoren die Team Performance nachteilig beeinflusst wurde. Diese Ausgangslage bot einen sehr guten Anlass für einen Workshop.

Ist der Zweck des Workshops bekannt, empfehle ich möglichst viel Wissen über die Teilnehmer zu sammeln, um den Workshop optimal auf die einzelnen Charaktere abzustimmen. Auch wenn das nicht immer möglich ist, kann ein solches Wissen durchaus einen großen Unterschied machen. Nehmen bspw. eher beobachtende Charaktere, aktive Hinterfrager, extro- oder eher introvertierte Personen teil, gibt es vielleicht sogar Konflikte zwischen Teilnehmern in der Gruppe, kann das die konstruktive Zusammenarbeit im Workshop beeinträchtigen. Hier ist es wichtig, ein vertrauensvolles und respektvolles Umfeld zu schaffen. Hierauf sollte dann der Fokus bei der Einleitung des Workshops gelegt werden.

So vielfältig die möglichen Konstellationen der Rahmenfaktoren auch sind, je größer der Teilnehmerkreis ist, um so wichtiger ist auch eines: Mut zur Entscheidung, was man mit der Gruppe tun möchte. Man kann daraus eine Wissenschaft machen oder sich einen bis zwei Aspekte herausgreifen und sich in der weiteren Planung auf diese fokussieren. Denn ist der Workshop auch nur in einem einzigen Aspekt erfolgreich, bleibt er bestimmt nicht der letzte.

Praxisbeispiel: Intensives Kennenlernen der Teammitglieder

Meine Beobachtungen des Teams zeigten, dass gerade der kulturelle Unterschied ein entscheidender Faktor in der Team Zusammenarbeit war, welcher einzelne Personen daran hinderten sich intensiver einzubringen. Daher entschied ich mich dafür einen Eisbrecher zum Einstieg zu platzieren, der alle möglichst schnell in einen Komfortbereich führt, um sich entspannt auf Neues einzulassen. Meine Wahl fiel auf das Thema Selbstreflexion mit dem Ziel etwas über sich preis zu geben und etwas über sich selbst zu lernen, kombiniert mit Humor wollte ich eine Atmosphäre des gegenseitigen Wohlwollens erzeugen.

Nähere Beobachtungen des Teams zeigten, dass nur wenige konstruktive Diskussionen stattfanden und die Kollegen sich somit nicht wirklich gegenseitig herausforderten. Entscheidungen des anderen wurden hingenommen, manchmal mit einem Zähneknirschen. Konstruktive Diskussionen über Lösungsideen fanden kaum noch statt. Es gab sogar eine aufkommende Tendenz zum “Finger Pointing”. Der unterschiedliche Erfahrungsstand um die agilen Prinzipien und deren Hilfsmittel aus der Agile Softwareentwicklung war ein Aspekt, der hier als mögliche Ursache der Probleme heraus stach. Eine weitere Ursache für die ausbleibenden, aber wichtigen Diskussionen zeigten sich darin, dass die unterschiedlichen Kompetenzen wenig von der Arbeit der anderen wussten. Für Außenstehende mögen die Unterschiede zwischen DevOps-, Backend und Frontend Engineers unscheinbar erscheinen, sie können sich aber aus der Nähe betrachtet so unterschiedlich wie Tag und Nacht ausprägen. Durch die gestiegene remote Zusammenarbeit schien das Wissen um die Motivation der anderen Kompetenzen verloren gegangen zu sein, was in der Arbeit im gleichen Büro zuvor eher unterbewusst vermittelt wurde. Jeder Menschen befindet sich in einem anderen Kontext, in dem sie oder er Informationen aufnimmt, verarbeitet und speichert bzw. weiterentwickelt. Diese diversen Ansichten können wichtig sein, um auf ganzheitliche Lösungen zu kommen, um Menschen in ihrer Entwicklung zu fördern und sollten generell bestärkt werden. Sie können aber auch zu Konflikten führen, wenn sich scheinbare Inkompatibilitäten daraus ergeben. Mit gegenseitigem Verständnis kann daraus aber auch eine hochwertige Teamarbeit entstehen. Aus eigener Erfahrung sind das die ganzheitlichen Softwarelösungen, von denen ich noch Jahre später beim Erzählen einen verklärten Blick und freudige Gänsehaut bekomme.

Gesamtziel des Workshops sollte also sein, die Motivation der Teammitglieder untereinander wieder sichtbar zu machen und das Wissen um die agilen Werte auf zu frischen.

Als Scrum Master oder Agile Coach stehen wir vor der Herausforderung, einen Workshop Termin sinnvoll zu moderieren. Wir haben die Möglichkeit, auf ein breites Portfolio an Methoden und Tools zurückzugreifen, z.B. auf Fachliteratur, Online-Tools oder den persönlichen Austausch mit Gleichgesinnten. Je gefüllter unser Werkzeugkasten und je lebendiger unser Netzwerk desto besser. Aber man muss natürlich das Rad nicht jedes mal neu erfinden. Wichtig ist sich bewusst zu machen, dass die Methoden nur das Mittel zum Zweck sind, nämlich das Ziel des Workshops in den Fokus zu bringen und alle Beteiligten darauf hinarbeiten zu lassen. Aber mit der Vorbereitung alleine ist es noch nicht getan. Auch während des Workshops kann ein spontaner Strategiewechsel notwendig sein. Wenn Unvorhergesehenes passiert, geplante Methoden sich vom Workshop Ziel weg entwickeln, müssen wir entscheiden, ob dies eine willkommene Entwicklung ist und wir das gewählte Vorgehens revidieren oder ob wir uns mit dem Team auf das gesetzte Ziel zurück besinnen. Hier ist der/die Moderator/in stark gefordert um die Gruppe kontinuierlich zu beobachten und es ist empfehlenswert eine alternative Methode im Ärmel zu haben, die etwas allgemeiner einsetzbar ist. Der Kreativität sind keine Grenzen gesetzt. Unterstützend gibt es natürlich jede Menge Fachliteratur, deren Lektüre wir auch unbedingt empfehlen möchten.

Wer ganz neu in dem Umfeld ist, dem sei das Buch Agile Retrospectives: Making Good Teams Great (Pragmatic Programmers) empfohlen.Hier werden viele Grundlagen vermittelt, inkl. praktischer ready-to-use Beispiele. Auch der Retromat ist immer wieder gerne ein Ideengeber für Experimente.

Praxisbeispiel zur Auswahl von Methoden

Check-In für ein vertrauensvolles gegenseitiges Wohlwollen

Auch wenn es diverse Klischees bedient, für unseren Teamworkshop boten sich Figuren aus Comics, Film & Fernsehen an, da dazu die meisten Teilnehmer direkt ein konkretes Bild vor Augen haben dürften. Jeder  Teilnehmer inkl. mir sollte die Frage beantworten “Wenn ich eine Comic-/Film- oder Serienfigur wäre, welche wäre ich dann und warum?”. Jeder Teilnehmer erhielt seine Figur für den Rest des Workshop Tages als Avatar ausgedruckt an den Platz gelegt. Die Antworten sorgen in der Regel für Heiterkeit, Überraschungen und gegenseitiges Verständnis. Also eine gute Grundlage für die weitere gute Zusammenarbeit im Workshop.

Alignment des agiles Mindsets

Um die gemeinsame Basis für Agile Softwareentwicklung zu schaffen, beschloss ich die Agilen Werte und Prinzipien als Theorieteil in den Workshop mit auf zu nehmen. Diese lassen sich im Arbeitsalltag der Softwareentwickler/innen sehr gut jederzeit referenzieren, wenn etwas nicht ganz rund laufen sollte und man den Eindruck hat, man kommt vom gemeinsamen Weg ab. Auch können die Teilnehmer Insights über einander schaffen, wenn sich jeder im Team einen Favoriten aussuchen kann, hinter dem er oder sie ganz besonders stark steht. Die Prinzipien eignen sich für einen Workshop bzw. eine Retrospektive auch sehr gut um einzelne Prinzipien besonders hervorheben, die man vielleicht noch nicht erfüllt sieht oder die man einfach wieder ins Gedächtnis hervorrufen möchte.

Zusammenarbeit stärken durch die Kenntnis der Motivationen

Nach einem Brainstorming mit einem anderen Scrum Master über mögliche Methoden kam die Erkenntnis recht schnell: Verständnis erlange ich nur, wenn die Teammitglieder die Motivation hinter einer Entscheidung kennen. Dazu boten sich die “Moving Motivators” gut an. Bei dieser Methode geht es darum, für sich selbst Motivatoren ausfindig zu machen und heraus zu finden, wo man zum aktuellen Zeitpunkt diese Motivatoren auch gut genug umsorgt. Die Methode ist initial als one-on-one Methode angedacht, sie eignet sich aber auch sehr gut für die Anwendung für sich selbst oder im Team. Die konkreten Motivatoren sind Anerkennung, Wissbegierde, Freiheit, Status, Sinnerfüllung, Ehre, Perfektionierung, Ordnung, Einfluss, Verbundenheit.

Nun, die Theorie ist immer schön und gut. Ich rate jedoch davon ab, eine ganz neue Methode das erste Mal erst im direkten Praxisbetrieb aus zu probieren. Ein Testlauf kann am einfachsten aufzeigen, ob die ausgesuchte Methode vielleicht ungeeignet ist oder aber der Testlauf zeigt auf, dass man die Methode vorher doch noch nicht ganz verstanden hatte und man sich in eine Sackgasse begeben hat. Er ermöglicht zudem sehr gut einen Abgleich der gefundenen Methode mit den äußeren Gegebenheiten, wie Teilnehmeranzahl und den Räumlichkeiten. Somit ist ein Dry Run immer ein Gewinn an Sicherheit und warum nicht unbeteiligte Kollegen hinzuziehen und Ideen durchspielen? Dabei können neue sowie bekannte Methoden hinterfragt werden oder Anstöße für Abwandlungen abgeholt werden.

Praxisbeispiel: Wie der Testlauf das Format revolutionierte

Ein Test an mir selbst und einer mit einem unabhängigen und experimentierfreudigen Kollegen zeigte einige wichtige Erkenntnisse. Zum einen deckte er auf, dass ich gut daran tat, die Erklärung der Moving Motivators vorher noch einmal zu üben. Weiterhin zeigte er, dass noch “etwas störte” – anfangs nicht ganz greifbar, aber im Austausch mit einem weiteren Kollegen konnten wir es benennen. Ein paar grundlegende Dinge würden die Entwickler mit diesen sehr allgemeinen Motivatoren nicht voneinander lernen: nämlich welche software- und qualitätsbezogen Motivatoren sie antreiben. Schließlich war es ja das gesetzte Ziel sie betont dabei zu unterstützen, ihre Beweggründe für Entscheidungen und ihre Stärken miteinander auszutauschen, die ihnen bei der täglichen Arbeit begegnen.     

So viel die Entscheidung, nach den allgemeinen “Moving Motivators” ein Motivator Format einzusetzen, was auf die Teilnehmer noch besser passt und ihnen ihre täglichen Entscheidungsgrundlage bewusster macht. Der klassische Software Qualitäts ISO Standard kennt sieben Faktoren: Änderbarkeit/Wartbarkeit, Benutzbarkeit, Effizienz, Funktionalität, Übertragbarkeit, Zuverlässigkeit. Ein paar Bastelarbeiten später ist ein kleines eigenes  “Software Quality Motivators” Kartendeck entstanden.

Für den Workshop selbst sollte man als Moderator/in genug Freiraum haben um die Gruppe beobachten zu können. Hierfür kann man Teilnehmer bitten kleine Handgriffe zu übernehmen oder zeitfressende Nebentätigkeiten vollständig abgeben. Auch das Timeboxing der einzelnen Aktivitäten benötigt Aufmerksamkeit. Es wäre zu schade, wenn geplante Schlüsselaktivitäten zu kurz kommen, weil das Check-in in den Workshop zwar erheiternd ist, aber ein Drittel der Zeit beansprucht hat. Ich notiere mir gerne auch die geplante vs. die benötigte Zeit für Methoden um für spätere Workshops eine bessere Einschätzung machen zu können. Auch helfen Notizen, wo es Abweichungen zur Planung gab um für die Nachbereitung eine gute Grundlage zu schaffen.

Praxisbeispiel: Der Motivator Workshop

Durch Schwierigkeiten bei der Anreise verzögerte sich der Workshop ein wenig. Um Hektik aufkommen zu lassen, kürzte ich etwas im Theorieteil. Der Workshop selbst lief daraufhin im Timekeeping wie geplant. Für die Motivatoren Aktivitäten hatte ich meine eigenen Ergebnisse aus dem Testlauf festgehalten und als Beispiel für die Erklärung verwendet. Wir hatten zum Schluss sogar noch Zeit aus den Software Quality Motivatoren, die manche Teilnehmer als wichtig aber noch nicht erfüllt angesehen wurden, Aktivitäten für das Team und das Leader Team zu definieren, welche sie im Nachgang als Action Items direkt angehen konnten. Nicht zuletzt wurde aber auch viel gelacht und der persönliche Austausch und die Gespräche an unserer Kaffeemaschine zelebriert.

Ein wirkungsvoller Workshop hat eigentlich immer Ergebnisse, auf die man weiter aufbauen kann. Seien es neue Erkenntnisse über die Gruppe, von Teilnehmern übereinander wie Stärken und Potentiale oder einfach weitere konkrete Handlungsfelder und Action Items. Auch ob Aktivitäten den Effekt erzielt haben, der angedacht war und ob die dafür veranschlagte Zeit ausreichend ist, gemäß der Teilnehmerzahl. Kamen Diskussionen auf, die unnötig waren, weil vielleicht ein Verständnisproblem vorlag oder wäre es sinnvoll gewesen einer nötigen Diskussion mehr Freiraum zu geben? Diese und weitere Erkenntnisse sind eine gute Basis für die weitere Arbeit mit dem Team und geben im nächsten Workshop mehr Sicherheit für uns Scrum Master/innen.

Praxisbeispiel: Gemeinsame Erkenntnisse

Als Ergebnis unseres Workshops konnten wir sehen, welche Stärken, Gemeinsamkeiten und Unterschiede der Teilnehmer hervor stachen. Unsere Erkenntnisse schärften das Bild über die Vorteile dieser Gruppenkonstellation. Ebenso konnten wir den gefundenen  Handlungsbedarf für die Gruppe entsprechend weiterleiten bzw. im Nachgang im Team bearbeiten. Sowohl die Software Quality Motivators, als auch die Moving Motivators sind in meine Toolbox gewandert und warten auf den nächsten passenden Einsatz. Sie haben mir in der persönlichen Anwendung aber auch weiter geholfen meine nächsten Ziele klarer vor Augen zu haben.