SDN 01/2019 - Der Scrum Master als Hüter des Frameworks

SMART DEVELOPMENT NEWS 01/2019

Unternehmen, die physische bzw. mechatronische Produkte entwickeln, stehen bei ihren ersten agilen Gehversuchen meist vor großen Herausforderungen: Sie können einige zentrale Voraussetzungen, die in der Theorie an Agile Teams gestellt werden, nicht ohne weiteres erfüllen.

Einen smarten Lösungsweg für die Integration einer größeren Anzahl an Spezialisten, die bei der Entwicklung eines Produkts nur mit einer geringen Kapazität eingebunden sind, durch ein „Extended Team“ haben wir im Newsletter 02/18 vorgestellt.

Sicher ist es eine Herausforderung, solche Spezialisten adäquat zu ihrer Kapazität ins Scrum Team einzubinden und dabei auf die Einhaltung der maximalen Teamgröße von neun Entwicklern zu achten. Aber es gibt noch einen weiteren Aspekt, den es in der Praxis bei neu gestarteten Scrum Teams zu meistern gilt: Bei idealen Scrum Teams unterstellt man, dass jedes Teammitglied über die Skills und Erfahrungen verfügt, die es ihm ermöglichen, jede Aufgabe zu „ziehen“, d. h. aus dem Sprint Backlog zu übernehmen. Dadurch wäre auch jedes Teammitglied in der Lage, die Probleme des anderen bei der Erledigung dieser Aufgabe zu verstehen und bei der Lösung mitzuwirken.

In der Praxis gibt es aber viele Fachbereiche mit unterschiedlichen Spezialisierungen. Diese Spezialisierung führt zu einem klaren Fokus des entsprechenden Teammitglieds. Backlog Items, die auf eine bestimmte fachliche Aufgabe abzielen, kann nur der Spezialist für dieses Fachgebiet ziehen und kein anderes Teammitglied. Viele Teams finden bei ihren ersten Gehversuchen schnell einen pragmatischen Umgang mit dieser Rahmenbedingung. Das Backlog wird so formuliert, dass die Spezialisierungen berücksichtigt werden.

Daraus entsteht aber eine weitere Herausforderung – oft sogar nur unterschwellig – die das Team auf seinem Weg in eine effiziente Agilität meistern muss. Spezialisierungen führen zu Abgrenzungen – mein Zuständigkeitsgebiet und dein Zuständigkeitsgebiet. Wie geht aber ein Teammitglied mit dem Zuständigkeitsgebiet des anderen um? Oft fehlt die Bereitschaft, sich damit auseinanderzusetzen. Und das hat konkrete Auswirkungen auf die Teamarbeit.

„Was nutzt es mir im Daily, wenn ich sehe, wie mein Kollege seine gelben Zettel von einem Status in den anderen umhängt?“ Auf Basis dieser Überlegung entscheidet das Team in der nächsten Retrospektive, dass man wohl effzienter wäre, wenn man nicht mehr jeden Tag ein Daily macht. Außerdem sei es wohl nicht sinnvoll, Sprint Planung und Backlog Refinement gemeinsam, also zusammen mit allen Teammitgliedern zu machen. Hier könne der Product Owner doch bitte eine Agenda erstellen, in der jeder Fachbereich einen eigenen Zeitslot hat.Dies alles sind valide Überlegungen auf Basis der bisher gemachten Erfahrungen, würden aber in eine Sackgasse führen, die dem Team alle Möglichkeiten nimmt, durch Agilität ein neues, deutlich höheres Level an Effizienz und Effektivität zu erreichen.

Um zu verhindern, dass ein neues Scrum Team den Weg in eine derartige Sackgasse einschlägt, braucht es einen gut ausgebildeten Scrum Master mit Erfahrung in Teamentwicklungsprozessen und angenehmer, aber starker Persönlichkeit. Als Hüter des Agilen Frameworks bietet und bildet er einen Korridor für die Selbstorganisation des Teams. Das heißt in ganz konkreten Worten: die Selbstorganisation hat Grenzen. Und diese Grenzen muss der Scrum Master am besten so vorgeben, dass das Team die Grenzen gar nicht wahrnimmt oder sie zumindest ohne Widerwillen einhält. Eine Aufgabe, die es in sich hat und die dafür spricht, Scrum Master auch aus den Reihen der Führungskräfte, beispielsweise der Teamleiter, zu rekrutieren. Soweit solche Scrum Master nicht zur Verfügung stehen, können entweder kollegiale Beratungen durch andere Scrum Master in regelmäßigen Treffen oder die Unterstützung durch einen erfahrenen Agile Coach helfen.

Lohnt sich dieser Aufwand für ein Unternehmen?

Nur wenn die „typischen Anfängerfehler“ vermieden werden hat das Team eine Chance, sich zu einem echten Scrum Team zu entwickeln. Und zu diesen Fehlern gehört mit hoher Wahrscheinlichkeit, dass ein Team, um zeitlichen Aufwand zu vermeiden, die Anzahl der Events reduziert oder sie inhaltlich kürzt. Auf ihrem Weg zu mehr Agilität schaffen es die Teams dann letztlich, dass die Teammitglieder ihren Fokus von der Verrichtung einer fachlichen Spezialfunktion auf die Entwicklung eines Produktes mit hohem Kundennutzen richten. Sie erkennen: eine optimale Verrichtung vieler Spezialistenfunktionen nebeneinander führt noch lange nicht zu einem guten Produkt.

Unternehmen, die diese Früchte ernten wollen, brauchen Geduld. Und gute Scrum Master, die sich von Anfang an als Hüter der Agilität verstehen.