Warum ein Scrum-Master Prozesse einfordern muss

Natürlich, wer kennt es nicht: Das (Produkt-) Management macht budgetäre und/oder zeitliche Zielvorgaben für die Produktentwicklung und “das Entwickler-Team hat die Ziele wieder einmal verfehlt”. Ärgerlich! Noch ärgerlicher dabei ist, dass die Entwickler zusätzlich feststellen, dass man aufgrund des engen Zeitplans technische Schulden aufgebaut oder sogar nicht mal das Testing sauber aufsetzen konnte. Woran liegt das? Wurde doch dieses mal extra ein Puffer in der Zeitplanung eingerechnet!

Herausforderungen als Scrum-Master

Unabhängig von möglichen Vorgehensweisen und Ansätzen, um solche Probleme von vornherein zu vermeiden (siehe Artikel: Schätzungen im Projektalltag) ist eine der wichtigsten Aufgaben eines Scrum-Masters sicherzustellen, dass ein Team Zielvorgaben erreichen kann.

Der Scrum-Guide beschreibt dazu nicht unbedingt praxisnah, welche Herausforderungen im täglichen Doing auf einen Scrum-Master zukommen – und die haben es in sich. Nachfolgend sind die Top-3 an Problemen aufgelistet, die ich bisher häufig in Unternehmen oder Projekten vorgefunden habe:

1.) Wasserfallartiges Vorgehen vs. Agilität

2.) Trennung zwischen “Produktmanagement” und “Delivery Unit”

3.) (Zu) viele Personen im Unternehmen nehmen Einfluss auf die Entwicklung des Produkts

Häufig werde ich gefragt, wie man mit den genannten Problemen als Scrum-Master umgehen soll und die Antworten darauf sind nicht zwingend einfach umzusetzen:

An die Werte des agilen Manifests erinnern

Kluge und erfahrene Menschen haben sich bereits vor über 20 Jahren Gedanken dazu gemacht, was Agilität bedeutet:

• Individuen und Interaktionen sind wichtiger als Prozesse und Werkzeuge
• Funktionierende Software ist wichtiger als umfassende Dokumentation
• Zusammenarbeit mit dem Kunden ist wichtiger als Vertragsverhandlung
• Reagieren auf Veränderung ist wichtiger als das Befolgen eines Plans

Quelle: Manifest für Agile Softwareentwicklung

Aus diesen Werten lassen sich sehr viele Lösungsansätze für die oben genannten Probleme ableiten.
Beispiel: Das Produktmanagement gibt vor, dass ein Feature oder ein ganzes Produkt bis zu einem bestimmten Zeitpunkt umgesetzt sein muss. Dabei wird keine Rücksicht darauf genommen, dass Schätzungen vom Entwickler-Team gemacht werden müssen. Stattdessen soll der Product Owner grobe Schätzungen liefern. Die Umsetzung zur Vorgabe passt nicht, das Projekt scheitert.

Lösung: Das Produktmanagement benötigt Schätzungen. Da in der Vergangenheit bisher grobe Schätzungen ausgereicht haben, wurde das Scrum-Team im Prozess übergangen. Ein anderer Prozess muss etabliert werden. Der Scrum-Master sollte bereits dann einschreiten, wenn Schätzungen vom PO abverlangt werden und gemeinsam mit dem Team überlegen, wie der Prozess angepasst werden kann. Das Produktmanagement muss über die Schätzmethoden und Möglichkeiten aufgeklärt werden. Statt eines eingefahrenen Prozesses und Aussagen wie “Ich brauche nur eine grobe, ungefähre Zahl” muss ein gemeinsamer neuer Prozess erarbeitet werden. Ebenfalls sollte der Scrum-Master einfordern, dass der PO in Abstimmung mit dem Produktmanagement die wichtigen Features priorisiert. Entsprechend kann der PO und das Entwickler-Team in regelmäßigen Abständen, bspw. im Sprint-Review über den Fortschritt der Features informieren. Das Produktmanagement kann dann in Abstimmung mit dem PO die Priorisierung jederzeit anpassen oder durch Feedback aktiv Einfluss nehmen auf das zu entwickelnde Produkt.

An diesem Beispiel lässt sich feststellen, wie wichtig die Grundlagen des agilen Manifests sind und welche Relevanz sie tatsächlich für den Alltag in einem Unternehmen haben. Zusätzlich zeigt sich deutlich, dass eine neutrale Person die Probleme erkennt und daraus ableitet, entweder neue Prozesse einzuführen oder an bestehende Prozesse zu erinnern und diese einzufordern.

Transparent die Vor- & Nachteile von agiler Arbeitsweise aufzeigen

Menschen neigen schnell dazu, komplexe Probleme durch eine augenscheinlich einfache Lösung zu verharmlosen. Agilität ist daher für Viele die lang ersehnte Antwort auf starre Strukturen und die “moderne” Arbeitsumgebung, die sich viele Menschen wünschen. Selten wird dabei kritisch genug hinterfragt, ob sowohl die Philosophie als auch die konkreten Prozesse im Unternehmen mit Agilität konform gehen. Genauso schnell, wie im Unternehmen laut “Wir machen Scrum!” ausgerufen wurde und der ersehnte “frische Spirit” im Unternehmen herbeigesehnt wird, treten die ersten Probleme auf. Scrum ist nicht die Antwort auf alle Probleme, liefert aber im besten Fall für ein Unternehmen mehr Vorteile als Nachteile in der Vorgehensweise. Dabei dürfen bei der Bewertung zu einer Einführung von Scrum die Risiken keinesfalls unter den Tisch gekehrt werden. Ganz im Gegenteil: Je stärker alle Individuen im Unternehmen in den Prozess – und damit dem Unternehmen – eingebunden werden, desto näher kommt man einem gemeinsamen Verständnis was Agilität im Unternehmenskontext bedeutet.

Ein Scrum-Master sollte diesen Prozess kontinuierlich begleiten und darauf bestehen, dass die Organisationsstrukturen außerhalb der “Entwicklungsabteilung” (bspw. Sales, Management) regelmäßig im Scrum-Prozess geschult werden und somit das Verständnis fördern. Er trägt in diesem Moment maßgeblich dazu bei, dass das Entwickler-Team sich darauf fokussieren kann, wozu es da ist: Software zu entwickeln.

Einhalten des Scrum-Prozesses

Der Entwicklungsprozess von Scrum ist im Internet und in diverser Literatur ausführlich erklärt. Dennoch muss der Scrum-Master immer wieder darauf hinweisen und auch aktiv in Gespräche eingreifen, um den Prozess zu verteidigen. Ein häufiges Beispiel ist, dass Personen mit Weisungsbefugnis im Unternehmen (bspw. Geschäftsführer, Produktmanager) den Sprintzyklus unterwandern und gerne Änderungen am Sprintumfang vornehmen möchten. Der Scrum-Master muss hier den Product Owner beratend unterstützen und zur Not das Gespräch mit entsprechenden Personenkreisen suchen. Oftmals reicht es hier bereits aufzuzeigen, dass notwendige Anpassungen zwar vorgenommen werden können, aber hinter der Umsetzung diverse Abhängigkeiten stehen. Änderungen an der Umsetzung müssen häufig im Kontext des Gesamtsystems berücksichtigt werden. Dadurch entsteht ein deutlich höherer Aufwand als ursprünglich über den Daumen gepeilt geschätzt. Gerade hier kann der Scrum-Master in einem klärenden Gespräch die Abhängigkeiten in der Entwicklung deutlich aufzeigen und somit weg von einer emotionalen hin zu einer logischen, aufeinander aufbauenden Argumentation zurückgreifen. Der Scrum-Prozess ist dabei kein unumstößliches Vorgehen, sondern wird von den einzelnen Mitarbeitern erarbeitet und gelebt. Dabei gibt es im Detail unterschiedliche Wünsche und Bedürfnisse, wie der Prozess in die übergreifenden Unternehmensprozesse integriert werden kann. Der Scrum-Master fungiert hier als Moderator und Berater, der den Prozess individuell mit den Menschen in der Organisation an diese und ihre Arbeitsrealität anpasst.

Einwirken auf Unternehmensprozesse

Ein Scrum-Master hat auch die Aufgabe, an Organisationsveränderungen zu arbeiten, um dem Team damit zu helfen. Gemeint ist: Ein erfahrener Scrum-Master sieht Probleme in Prozessen, die bspw. historisch entstanden sind oder durch Umstrukturierungen im Unternehmen neu entstehen. Im Scrum-Guide wird nicht erläutert, wie die Zusammenarbeit mit einem dedizierten Produktmanagement funktioniert. Viele Unternehmen, die Scrum neu einführen, trennen das Produktmanagement historisch bedingt stark vom restlichen Scrum-Kontext. Daraus resultieren mannigfaltige Probleme: Missverständnisse in der Umsetzung, unterschiedliche Vorstellungen von Budget, Zeit und Qualität oder zu große Umfänge von Produktfeatures sind dann häufig an der Tagesordnung. Auf das Scrum-Team wird dann im weiteren Verlauf häufig Druck ausgeübt. Der Umkehrschluss kann oftmals Trotz-Haltung oder aktives gegeneinander Arbeiten gegen das “böse Management” sein. Wer sich hier wiedererkennt, muss dringend handeln, denn die Probleme sind lösbar. Der Scrum-Master sollte hier schlichtend und moderierend eingreifen. Angefangen von klärenden Gesprächen, bis zu Schulungen über die Vorgehensweise sind mögliche Ansätze. Letztlich muss hier jedes Unternehmen seinen eigenen Weg finden. Wichtig dabei ist, dass eine Rolle, die nicht aktiv davon betroffen ist (Scrum-Master), diesen Weg begleitet und die Kommunikation dazu startet.

Welche Möglichkeiten hat man als Scrum-Master Prozesse einzufordern?

1. Dokumentation der Retro-Ergebnisse und Beschlüsse auf einem übersichtlichen Board

Eine gute Möglichkeit Übersicht zu schaffen ist (sowohl für das bestehende Scrum-Team als auch für neue Mitglieder), die gemeinsamen Beschlüsse und Verpflichtungen aus den Retrospektiven auf einem separaten Board zu sammeln. Ergebnisse von Retrospektiven werden häufig in Dokumentations-Tools (bspw. Confluence) in separaten Seiten abgebildet. Die Beschlüsse gehen dann im Laufe der Zeit verloren. Eine gute Basis für Zusammenarbeit ist ein Board, kumuliert mit allen Beschlüssen, das auch regelmäßig vom Team in Retrospektiven überprüft wird. Sind die Regeln noch aktuell? Sind die Regeln noch passend und stimmen mit der Vorgehensweise des Teams überein? Müssen die Regeln abgewandelt oder verworfen werden? Der Scrum-Master sollte dabei regelmäßig mit dem Team prüfen, ob die definierten Prozesse in dieser Form zum Unternehmen passen.

Dieses Board dient auch als Vorlage, die ein Scrum-Master nutzen kann, um Personen in der Organisation außerhalb des Teams zu erklären, wie das Team arbeitet und worauf es Wert legt.

2. Beobachtungen in der Retrospektive schildern

Ein Scrum-Master soll in Retrospektiven lediglich als Moderator fungieren und nicht aktiv als Teilnehmer wahrgenommen werden. Je nachdem wie die Team-Mitglieder untereinander sprechen ist es dennoch manchmal notwendig, dass ein Scrum-Master Themen anbringt. Selbstverständlich muss hier eine neutrale Position eingenommen werden, um Beobachtungen zu schildern und die daraus resultierenden Probleme analytisch und klar vorzustellen. Dadurch kann anschließend gemeinsam im Team eine Lösung dazu gefunden werden. Warum Retrospektiven benötigt werden, was in Retrospektiven beachtet werden muss und wie sie ein erfolgreicher und motivierender Faktor für das Team werden, beschreiben wir in einem nachfolgenden Blog-Artikel.

3. Auf Team-Mitglieder im Vertrauensgespräch zugehen

Oftmals haben Menschen unterschiedliche Vorstellungen oder auch Probleme mit einem Vorgehen, das gemeinsam definiert wurde – trauen sich aber nicht ihre Bedenken in die Diskussion einzubringen. Dies kann sich darin äußern, dass einzelne Team-Mitglieder sich nicht entsprechend dem gemeinsamen Prozess verhalten oder sogar aktiv dagegen vorgehen. Hier hilft ein Vertrauensgespräch in dem der Scrum-Master herausfinden muss, welche Ängste hinter dem Verhalten stehen. Der Scrum-Master muss viel Fingerspitzengefühl mitbringen, um der Person ihre Ängste und Bedenken nehmen zu können. Eventuell ist es auch sinnvoll, ein Gespräch mit dem Team anzustreben, sollten die Bedenken dieses betreffen.

Fazit

Bezugnehmend auf die Überschrift dieses Artikels ziehe ich folgendes Fazit: anhand der aufgezeigten Erfahrungen im Projektalltag zeigt sich deutlich die Wichtigkeit der Rolle eines aktiven Scrum-Masters. Dieser muss von Personen außerhalb des Scrum-Teams, egal in welcher Position diese agieren, die Einhaltung von definierten Prozessen und Vorgehensweisen in der Softwareentwicklung einfordern und sie verteidigen. Anders ausgedrückt: Ist diese Rolle nicht besetzt oder wird der Scrum-Master lediglich als ein Verwalter des Teams gesehen, der Termine anlegt und moderiert, fehlt dem Unternehmen die neutrale Rolle, die dafür sorgt, dass unterschiedliche Menschen miteinander erfolgreich arbeiten können. Missverständnisse, fehlerhafte Kommunikation und ein Gegeneinander statt einem Miteinander ist dann oftmals die Regel. Ebenfalls ist es wichtig, dass Scrum-Master argumentativ, sachlich und ruhig in diesen Prozess eingreifen, da emotionale Haltungen zumeist schon von Team-Mitgliedern eingenommen werden. Der Scrum-Master sollte hier die Stimme der Vernunft darstellen, die analytisch begründet ist. Am wichtigsten ist jedoch, dass eine solche Rolle immer wieder auf das Scrum-Framework hinweist und nicht müde wird, die Menschen im Unternehmen konsequent an die Spielregeln zu erinnern. Nur dann ist es möglich, dass Scrum im Unternehmen wirklich gelebt wird und nicht nur eine Wunschvorstellung von agilen Idealisten bleibt. Ein Unternehmen kann nur so gut sein, wie seine Mitarbeiter, die in effizienten Prozessen miteinander statt gegeneinander arbeiten – und das muss zumindest eine Person einfordern: der Scrum-Master.

Hast Du oder Dein Unternehmen Dich in Teilen wiedererkannt? Melde Dich gerne bei uns, wenn Du Unterstützung benötigst. Wir können Dir helfen, die Prozesse wieder zum Laufen zu bringen.