Die Aufgaben und Werkzeuge eines Scrum Masters laut Lehrbuch kennt sicher jeder aus Seminaren zum agilen Projektmanagement, von der bekannten Zertifizierung oder aus Artikeln in Fachmagazinen. Soweit die Theorie, aber wie sieht es in der Realität aus?
In diesem Beitrag möchte ich den Scrum Master in der Praxis betrachten. Dazu habe ich mit Entwicklern aus verschiedenen Projekten gesprochen und mir ihre Erlebnisse schildern lassen. Zudem fließen auch meine persönlichen Erfahrungen aus meiner aktiven Zeit als Scrum Master ein. Des Weiteren finden Techniken und Tools Erwähnung, die immer wieder Anwendung in agilen Projekten finden.

Scrum Master in der Theorie

Laut Scrum Prozess, so wie er auf der offiziellen Webseite beschrieben ist, hat der Scrum Master weder Weisungsbefugnis und gibt damit keine Arbeitsanweisungen, noch ist er disziplinarischer Vorgesetzter des
Developer Teams. Er soll den Scrum Prozess bestärken und Hindernisse für die Entwickler aus dem Weg räumen (Impediment Backlog), damit diese ihrer täglichen Arbeit nachkommen können.
Die im Folgenden beschriebenen Ereignisse sind auf keinen Fall als Empfehlung zu verstehen, sondern spiegeln die Realität in einigen Projekten wider, und zeigen, wie Scrum wirklich gelebt wird.

Von weniger zu mehr

Viele Unternehmen haben in der Vergangenheit über agile Projekte, ihre Effizienz und Kostenersparnis bei der Entwicklung, gehört und wollen dies jetzt auch einführen. Dabei wird sich häufig für Scrum entschieden. Meiner Beobachtung nach sind es vor allen Dingen die „alten Hasen", die sich häufig mit dem neuen Vorgehen schwer tun, da sie mit klassischem Projektmanagement aufgewachsen sind und sich ungern auf den neuen Prozess einlassen. Deshalb besteht die Möglichkeit, sich Schritt für Schritt heranzutasten, und am Anfang nur einzelne Teile einzuführen und „auszuprobieren". So werden sehr oft z. B. Dailys und Retrospektiven eingeführt, während die bestehenden Plannings meistens weitergeführt werden. Hier wird also häufig das Beste oder Einfachste herausgepickt und in bestehende Abläufe eingeführt bzw. ausprobiert.
Auf Dauer sollte das Ziel immer sein, Scrum mit allen Rollen, Artefakten und Prozessen komplett eingeführt zu haben.
Auch Umbenennungen von etablierten Elementen sind oft zu finden. Iterationen werden zu Sprints, Projektleiter in Product Owner und Teamleiter in SCRUM Master umbenannt und das Meeting zum Iterationsstart heißt plötzlich Sprint Planning.
Das alles hat allerdings nicht viel mit SCRUM zu tun, außer vielleicht die Bezeichnungen. Vom frisch ernannten Scrum Master wird in dem Zuge weiter die Teamführung erwartet, mitsamt Monitoring der Entwickler und Delegierung von Aufgaben. Auch der Product Owner mischt sich in die Entwicklung ein und gibt Anweisungen direkt am Scrum Master vorbei an das Team.

Meetings und Timeboxen

Eines der wichtigsten Dinge im Zusammenhang mit Meetings ist die Einhaltung von Start- und Endzeitpunkt eines Treffens, denn Zeit ist schließlich Geld und neben den ganzen Zusammenkünften möchten und müssen die Entwickler auch ihrer Haupttätigkeit – dem Entwickeln – nachkommen, frei nach dem Motto „von nichts kommt nichts". Dafür gibt es die so genannte Timebox, die eine Dauer oder aber Start- und Endzeitpunkt eines Meetings „hart" begrenzt.
Laut Scrum Guide dauert das tägliche Stand-Up-Meeting „Daily" nicht länger als 15 Minuten. Dabei ist nicht definiert, wann das Daily stattfinden sollte. Nach Ablauf einer Timebox wird das Meeting beendet und alle gehen zurück an ihre Arbeit. Das hat den Vorteil, dass sich die Teilnehmer kurzhalten und sich im gemeinsamen Gespräch auf das Wesentliche fokussieren müssen.
Das funktioniert nicht immer oder nicht immer sofort. Eine Herausforderung ist es, wenn die Teams zu groß sind. Damit jeder zu Wort kommt, dauern viele Meetings länger als geplant (und damit ist nicht zwingend das Daily gemeint). Auch redselige Kollegen, das Abschweifen von der Kernfrage, oder aber zu viele Tagesordnungspunkte können solche Treffen in die Länge ziehen. Die Einhaltung dieser Timeboxen muss ein Scrum Master im Blick haben und dafür auch ein Gespür entwickeln, damit auch alle wichtigen Themen ausgetauscht werden. Schwierig ist die Unterbrechung von Diskussionen zu „brennenden" Themen oder aber die Informationen von Stakeholdern, die nicht regelmäßig anwesend sind.
Solche zeitlichen Entgleisungen lassen sich aber auch gut in einer Retro besprechen und für folgende Sprints anpassen, um sich so der Einhaltung von Timeboxen immer mehr zu nähern. Auch das ist ein agiler Prozess, der häufig nicht von heute auf morgen gelingt.

Konflikte in Meetings und im Team

Bei meinen Gesprächen wurden immer wieder Probleme und Konflikte in den Projekten angesprochen, die größtenteils auf die Art und Durchführung von Meetings zurück zu führen sind.
Ein Kollege berichtete vom häufigen Wechsel des Scrum Masters, der in einem Jahr sogar dreimal ausgetauscht wurde. So musste sich das Team immer wieder an neue Ansprechpartner, andere Vorgehensweisen oder den Einsatz von neuen Tools gewöhnen. Auch die neuen Scrum Master benötigen immer wieder Zeit, um die Abläufe und Ansprechpartner im neuen Projekt kennen zu lernen. Bis dann Ruhe und ein gleichmäßiges Arbeiten möglich ist, vergehen einige Wochen oder gar Monate. Solange kann die Velocity des Teams stark einbrechen.
Durch den falschen Teilnehmerkreis diverser Meetings im Prozess können auch keine oder aber falsche Ergebnisse erzielt werden. Dies gilt auch frei nach dem Motto „Zu viele Köche verderben den Brei" für zu viele Teilnehmer, wie bereits oben schon exemplarisch für das Daily angesprochen. Mehr Teilnehmer bedeutet fast immer mehr Themen und längere Diskussionen.
Aber auch das Gegenteil, nämlich das Fehlen wichtiger Teilnehmer, kann zum Problem werden. So entstehen Wissenslücken im Entwicklerteam oder aber wichtige Argumente können nicht beigesteuert werden. Infolgedessen kommt es dann zu falschen Entscheidungen.
Wird dem Team keine Zeit gegeben, sich auf die jeweiligen Meetings vorzubereiten, ist auch dies ein Grund für längeres Zusammensitzen und manchmal sogar schlechtere Ergebnisse bei der Planung.
Die falsche Verwendung von Meetings wird auch hin und wieder angemerkt. So wird zum Beispiel das Refinement zweckentfremdet, indem dort der aktuelle Sprint nach-justiert wird, anstatt Punkte aus dem Product Backlog zu verfeinern – denn das ist die eigentliche Aufgabe und das Ziel dieser Veranstaltung.
Spannungsfelder zwischen einzelnen Personen werden immer wieder als Grund für Unzufriedenheit genannt und dabei meine ich nicht die zwischen einzelnen Entwicklern. Wenn das Team nicht harmoniert und gemeinsam an einem Strang zieht, kann sich dies auf die Inkremente, also die Ergebnisse eines Sprints, negativ auswirken. Auf dieses Thema möchte ich aber hier nicht näher eingehen, denn um die Behebung solcher Konflikte sollte sich der SCRUM Master kümmern.

Sprachliche Barrieren

In Zeiten von verteilten Teams, internationalen Projekten und Offshore-Entwicklung kommt es häufig vor, dass nicht das gesamte Team die gleiche Sprache spricht und meistens Englisch als gemeinsamer Nenner herangezogen wird.
Erschwert werden Meetings dann durch die englische Sprache, denn nicht jeder ist dieser mächtig oder kann sich präzise genug ausdrücken und so werden Dinge entweder erst gar nicht angesprochen oder man redet aneinander vorbei. Dies verkompliziert den Austausch und hat dann manchmal negative Auswirkungen auf den weiteren Projektverlauf.
Eine Lösung wäre hier z.B. die Bildung von sprachlich homogenen Teams oder aber die gezielte fremdsprachliche Schulung einzelner Mitarbeiter. Auch kann in Meetings vorübergehend auf die deutsche Sprache gewechselt werden, solange keine fremdsprachigen Kollegen dabei sind.

Eingesetzte Standardwerkzeuge

Im offiziellen Scrum Guide sind keine speziellen Tools vorgegeben, die vom Team zwingend benutzt werden müssen. Daher stellt sich häufig am Anfang die Frage, welche Werkzeuge am besten benutzt werden sollen. Natürlich gibt es in der Zwischenzeit genügend Erfahrungen mit agilen Projekten und somit auch jede Menge Empfehlungen und speziell für diese Zwecke entwickelte Programme.
Je nachdem wie viel Zeit und Budget für das Aufsetzen des Projektes zur Verfügung steht, werden bestehende Tools im Unternehmen einfach weiterverwendet.
Dabei denke ich z.B. an die Microsoft Office Suite, die nahezu überall eingesetzt wird. User Stories und Meetings werden dann in Word dokumentiert und auf dem Sharepoint abgelegt und Excel hält für die Sprintplanung und die Backlogs (Product Backlog und Sprint Backlog) her.
Wesentlich komfortabler und übersichtlicher ist der Einsatz des Team Foundation
Servers von Microsoft, der den nötigen Werkzeugkasten für die agile Softwareentwicklung mitbringt. Dazu gehören dann Funktionalitäten wie Teamplanung, Sprints, Backlogs, Auswertungen wie Burndown Charts und Kanban Boards.
Die Firma Atlassian bietet auch diese Funktionalitäten und gehört mit ihren Programmen Jira und Confluence zur Standardsoftware in vielen Firmen. Mit Jira werden die Aufgaben erfasst und getrackt, komfortabel zu Sprints zugeordnet, und so in Backlogs [siehe Bild 1] priorisiert aufbewahrt. Auch hier gibt es die Möglichkeit, Kanban Boards zu verwenden und Auswertungen zu tätigen. In Confluence werden dagegen die User Stories und Protokolle der Meetings erfasst.
Eine dritte und letzte Möglichkeit, die ich im Rahmen dieses Beitrags vorstellen möchte, ist Gitlab. Auch hier werden in einer Software gleich mehrere Funktionalitäten gebündelt. Neben dem Erfassen von Product Backlog Items, der Zusammenfassung zu Sprints und der Benutzung eines Wikis zu Dokumentationszwecken möchte ich noch das sogenannte Issue Board erwähnen, das wahlweise als SCRUM- oder Kanban Board verwendet werden kann.
Neben diesen Standard-Tools gibt es eine Reihe von zusätzlichen Werkzeugen für unterschiedliche Gelegenheiten, die immer wieder in agilen Projekten Verwendung finden, und die man sich auf jeden Fall einmal angesehen haben sollte.
Die vorgestellten Programme bieten gegenüber den erwähnten Funktionen noch wesentlich mehr, sollen hier aber nicht weiter beleuchtet werden. Jedes für sich ist ein richtiges Kraftpaket und kann durch Erweiterungen in Umfang und Funktionalität erweitert werden.

Weitere Tools und Techniken

Hier möchte ich noch weitere Tools und Techniken vorstellen, die mir in meinen Gesprächen mit den Kollegen immer wieder genannt wurden.
Das Planning Poker oder auch Scrum Poker genannte Verfahren ist das spielerische Schätzen der Komplexität von User Stories und Product Backlog Items im Refinement. Dabei gibt jeder Entwickler seine Meinung mithilfe von Karten ab, auf denen häufig die Fibonacci-Zahlen abgebildet sind, wie hoch er die Komplexität für die Umsetzung der jeweiligen Punkte sieht. Bewusst wird nicht nach Arbeitsaufwand geschätzt, da dieser je nach Erfahrung der jeweiligen Person unterschiedlich ist. Die Pokerrunden werden so lange fortgesetzt, bis sich alle einig sind.
Auch um die Retrospektive etwas abwechslungsreicher zu gestalten gibt es diverse Möglichkeiten. Eine davon ist die Nutzung der Webseite Retromat. Dort kann eine Retrospektive sogar online vorbereitet und per Link geteilt werden oder ganz klassisch ausgedruckt und im Team verteilt werden.
Eine zweite Webseite für eine Retrospektive ist Echometerapp. Dieses Tool ist ausschließlich online verwendbar und unterstützt mit psychologischem Know-how die lebhafte und ergebnisorientierte Durchführung. Anhand von Umfragen, die entweder vorgegeben sind oder aber selbst angepasst werden können [Bild 2 und 3]. So kann jedem noch so stillen Mitarbeiter ein Feedback entlockt werden. Eine gute Idee, um ein Meeting zu beginnen, wäre zum Einstieg die Frage „Wie war dein Tag?". Auch offene Fragen mit Freitextfeldern wie „Was nehme ich mir heute vor?" oder passend zum Sprint „Was war gut, was war schlecht?" lassen sich leicht einbauen. Anhand der Antworten können dann passende Maßnahmen [Bild 4] abgeleitet werden.
Eine weitere Methode, die Retrospektive ein wenig abwechslungsreicher und lebhafter zu gestalten, ist die „Appreciation" (engl. für Wertschätzung). Dabei loben sich die Kollegen gegenseitig, bauen sich auf und verteilen ein paar liebe Worte. Wer über wen spricht kann z. B. vorher per Zufall ausgewürfelt werden. Zum Einsatz kommt zum Beispiel Excel, aber mittlerweile gibt es auch einige Scrum-Webseiten, die diesen Baustein online zur Verfügung stellen. Eine davon ist die eben schon erwähnte Webseite Retromat.

Kommunikation für verteilte Teams

Nicht nur in der aktuellen Situation mit der Pandemie, in der viele im Home-Office
arbeiten, sondern auch in verteilten Teams über mehrere Standorte hinweg, ist eine gute Kommunikation Pflicht. Auch für diesen Zweck gibt es eine Menge Möglichkeiten mit Audio oder sogar Video, was das Ganze ein wenig persönlicher macht, sich zusammenzuschalten und auszutauschen.
Neben der klassischen Telefonkonferenz denke ich da sofort an Programme wie Skype und Teams von Microsoft oder auch Webex von Cisco. Natürlich ist dort ganz besonders Disziplin von Nöten, damit alle zu Wort kommen, alles Wichtige gesagt werden kann, und trotzdem das Ziel und die angesetzte Zeit (Stichwort „Timebox") nicht aus den Augen verloren wird.

Veränderungen durch Trennung 

Ein Nachteil bei verteilt sitzenden Teams ist, dass die Zusammenarbeit erschwert wird oder sich für diejenigen verändert, die bisher noch nie in solchen Projekten gearbeitet haben. Es gibt keine persönlichen Treffen und auch jemanden „mal eben" etwas Fragen oder aber über die Schulter schauen dauert länger, denn dafür muss man den Umweg über E-Mail, Telefon oder aber über die gerade angesprochenen Kommunikationsmöglichkeiten gehen.
Kanban-Boards, beschriebene Whiteboards oder Grafiken und Poster, die in gemeinsam genutzten Büros an den Wänden hängen, sind nicht digital verfügbar und müssen in Wikis umgezogen oder per Screenshot digital abgelegt werden.

Zusammenfassung

Die Macher von Scrum sind der Meinung, dass man Scrum entweder in seiner Gesamtheit mit allen Techniken, Methodiken und Praktiken nach Lehrbuch anwendet oder aber man nicht nach SCRUM arbeitet. Dies betonen sie in ihrer End Note des Scrum Guides explizit.
Geht man danach, dann kenne ich wirklich niemanden, der Scrum „richtig" einsetzt, sondern nur Projekte, die versuchen den Scrum-Prozess auf ihre Tätigkeiten zu pressen, einfach die Rollen und Ereignisse des klassischen Projektmanagement umbenennen, oder aber man pickt sich die besten Dinge des Prozesses aus und baut sie in sein agiles Projekt ein.
Dies ist sicherlich nicht im Sinne der Erfinder, aber so ergibt sich die Möglichkeit, sich Schritt für Schritt vom klassischen Projektmanagement an Scrum heranzutasten.
Bei den Tools und Techniken hingegen kann nach Lust und Laune ausgewählt werden. Der Markt ist voll und bietet reichlich Abwechslung für jeden Geldbeutel. Da ist bestimmt für jeden etwas dabei.