ScrumMaster: Wie setze ich ein gutes Scrum-Team auf?


Derzeit arbeite ich als Agile Coach und unterstütze meinen Kunden in der täglichen Arbeit mit Scrum, d.h.: Rollencoaching der ScrumMaster und Product Owner, Ausbildung der internen agile Coaches und Durchführung eines Intensivcoachingprogramms für neu startende Scrum-Teams. Ähnlich wie in dem Comic oben kommen bei meinen neuen ScrumMastern zwei Fragen auf:

  1. Was mache ich jetzt als ScrumMaster?
  2. Wie setze ich mein Team auf?

Auf die erste Frage möchte ich nur kurz eingehen, denn was ein ScrumMaster machen sollte, ist euch wahrscheinlich hinlänglich bekannt und wird in anderen Quellen ausgiebig behandelt: Der ScrumMaster ist verantwortlich für den reibungslosen organisatorischen Ablauf inner- und außerhalb seines Scrum-Teams. Er löst Impediments und agiert als Coach für seinen Product Owner und sein Development-Team. Zu guter Letzt arbeitet er als Change Agent mit anderen ScrumMastern in seiner Organisation daran, diese bei der Transformation zu einer agilen Organisation zu unterstützen.
Mehr Informationen zu den Aufgaben eines ScrumMasters findest du in diesem Blogbeitrag und Video von Boris Gloger oder in der 5. Auflage von Scrum – Produkte zuverlässig und schnell entwickeln.
Hier und heute ist mir die Antwort auf die zweite Frage besonders wichtig.

Das Team aufsetzen

Idealerweise ist das Scrum-Team crossfunktional aufgesetzt und besteht aus T-Shaped Professionals. Dabei bedeutet Crossfunktionalität, dass ein Team alle Skills besitzt, die es zur Produktentwicklung und –umsetzung benötigt. Ein crossfunktionales Team kann beispielsweise aus zwei bis drei Entwicklern, einem Tester und einem Testautomatisierer, einem Architekten und einem UX-Designer bestehen. Somit sind die Voraussetzungen für eine End-to-End-Entwicklung des Produkts im Team geschaffen.
T-Shaped Professionals besitzen tiefergehende Fähigkeiten in einer Disziplin und sind gleichzeitig in der Lage, sich aus angrenzenden Tätigkeitsbereichen Wissen anzueignen und innerhalb des Teams anzuwenden. Beispielsweise kann ein Tester nicht nur Testfälle schreiben und testen, er versteht auch einfache Codestellen der Entwickler und kann so simple Codefragmente selbst schreiben. Ebenso verhält es sich mit dem Architekten. Die Vision jedes Scrum-Teams sollte es sein, so viel Wissen wie möglich auf die einzelnen Köpfe zu verteilen. In absehbarer Zeit kann beispielsweise die Entwicklung der Architektur vom Dev-Team übernommen und  vorangetrieben werden.
Ein Team sollte nicht mehr als 7 bis 9 Mitglieder haben. Ist das Team größer, sollte man das Team wenn möglich (sinnvoll) teilen.

Und in der Unternehmenspraxis?

In den meisten Unternehmen, die mit Scrum starten, ist es nicht möglich, die ersten Scrum-Teams von Anfang an crossfunktional und t-shaped aufzusetzen. Das liegt meistens daran, dass einerseits die Mitarbeiter in mehreren Projekten gleichzeitig eingesetzt sind und ihnen die Zeit fehlt, sich bewusst und engagiert im Team einzubringen. Andererseits wird erst mit der Einführung von Scrum aufgedeckt, welche Skillprofile das Unternehmen wirklich braucht. Meistens müssen die passenden Mitarbeiter erst am Markt gefunden werden. Scrum startet allerdings nur selten auf der grünen Wiese. Daher sollte man zunächst einmal mit den vorhandenen Ressourcen und gegebenen Constraints arbeiten. Das Management sollte von Anfang an einbezogen werden, etwa in kurzen Meetings, in denen der ScrumMaster immer wieder die beschriebenen Impediments transparent aufzeigt. Mit der notwendigen Portion Geduld wird sich stückweise etwas ändern und das Team wird sich zu einem High-Performance-Team entwickeln. Immer wieder werden faule Kompromisse eingegangen, zum Beispiel wird ein Tester für drei Scrum-Teams eingesetzt. Für die fokussierte Arbeit in einem Team ist das nicht förderlich, trotzdem ist es gängige Praxis. Auch hier gilt wieder: Das Management einbinden und gemeinsam nach Lösungen suchen.
Hat eine Organisation einen höheren agilen Reifegrad erreicht, startet ein erfahrener ScrumMaster erst dann mit seinem Team, wenn ein Großteil der Mitglieder mindestens zu 60-70 % für das Scrum-Team verfügbar ist. Außerdem wird er darauf achten, so bald wie möglich einen Tester zu 100 % im Team zu integrieren. Innerhalb des Scrum-Teams fördert er den Wissenstransfer, damit auf eine End-to-End-Entwicklung hingearbeitet wird. Entweder braucht das Scrum-Team im Idealfall keinen eigenen Architekten mehr oder das Dev-Team ist in der Lage, mit dem Architekten gemeinsam die Softwarearchitektur weiterzuentwickeln.
Ein weiteres gängiges Modell aus der Praxis sind verteilte Teams. Die Teammitglieder befinden sich nicht an einem, sondern an mehreren Standorten. Manche Unternehmen sind in dieser Situation besonders kreativ, wie ein Beispiel aus meiner eigenen Erfahrung zeigt:

  • ScrumMaster an Standort A, Product Owner an Standort B, zwei Entwickler und der Tester an Standort C und ein weiterer Entwickler an Standort D.
  • Im ersten Schritt haben wir erreicht, dass alle Entwickler und der Tester an einem Standort sitzen können.
  • Im nächsten Schritt arbeiteten wir daran, dass auch der ScrumMaster regelmäßig beim Team vor Ort sein kann, indem er beispielsweise an 1-2 fixen Tagen zum Team fährt.

Es ist möglich, auch als verteiltes Team gute Ergebnisse zu erzielen. Dazu braucht es einen ScrumMaster, der vor allem in der Anfangsphase darauf achtet, dass das Team mindestens 3 Tage pro Woche gemeinsam vor Ort verbringt und entwickelt. Nur so können sich die Teammitglieder gegenseitig kennenlernen und ein Wir-Gefühl entwickeln. Die Sprintwechsel werden selbstverständlich auch gemeinsam durchgeführt. Hierbei empfehle ich, den Sprintwechsel auf zwei Tage zu legen. Am ersten Tag Anreise, Review und Retro, abends kann das Sprintende mit allen gefeiert werden. Am nächsten Tag finden im Laufe des Vormittages Sprint Planning I & II statt. Anschließend kann das Team gemeinsam starten, bevor sich alle wieder auf den Weg nach Hause machen. Bei einem Kunden beispielsweise legten die auf vier Standorte verteilten Teammitglieder in Summe 600 km pro Woche zurück, um die Meetings und den Sprintwechsel gemeinsam an einem Ort durchzuführen.

 
Wende dich als ScrumMaster beim Aufsetzen deines Teams beispielsweise an den unternehmenseigenen Agile Coach oder an andere ScrumMaster und bitte das Management sowie HR um Unterstützung. Oder wende dich an uns 🙂
 

Geschrieben von

Ellen Thonfeld Ellen Thonfeld Ellen Thonfeld hat über 7 Jahre Erfahrung in der Entwicklung von Produkten mit agilen Methoden. Angefangen mit Kanban im Maschinenbau entschloss sich die Wirtschaftspädagogin und Bankkauffrau, die Digitalisierung im Banken und Finanzbereich eben mit diesen Methoden voranzubringen. Seit vier Jahren ist sie nun eine unserer Spezialistinnen in diesem Bereich und begleitet vorrangig große Digitalisierungsprojekte im Großbankensektor. Ein spezieller Fokus liegt bei ihr im Bereich interne Revision.

Team member profile

TEILE DIESEN BEITRAG

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.