Neulich hatte ich ein sehr interessantes Gespräch. Dabei stellte ein Kollege folgende These auf:
Als Scrum Master ist es meine Pflicht, mein Team vor äußeren Störungen zu schützen.
So weit, so einfach und so einleuchtend.
Die eigentliche Frage dahinter lautet jedoch:
Würden Sie als interner Scrum Master Ihre Karriere aufs Spiel setzen, um Ihr Team gegenüber Ihrer Führungskraft zu schützen? Wie sieht es mit dem mittleren Management aus? Oder dem CEO? Falls Sie externer Scrum Master sind: Würden Sie Ihr Projekt und Ihre Reputation aufs Spiel setzen?
Das klingt auf einmal nicht mehr so rosig, oder? Plötzlich wird es ungemütlich. Das klingt nach Ärger.
Wenn der Kunde oder die Führung eine andere Meinung hat
Und genau da sind wir beim eigentlichen Kern des Problems. Viele interne und externe Scrum Master scheuen den Konflikt mit der Führung – verständlich, sie wollen ihren Job, ihren Ruf und ihre Tagessätze nicht aufs Spiel setzen wollen.
Allerdings: Als Scrum Master steht explizit in meiner Rollenbeschreibung, dass ich mein Team schütze – auch gegen meinen Auftraggeber, meine Führungskraft, das mittlere Management und den CEO. Es gibt niemand anderes, der das tut. Genau das nennt sich dann Führung.
Wenn der Scrum Master nicht seine Karriere im vollen Vertrauen auf die Leistungsfähigkeit des Teams aufs Spiel setzt – wer dann?
Exkurs: Die gut gemeinten Tipps auf LinkedIn
Wenn ich mir dagegen meinen LinkedIn-Feed anschaue, dann sehe ich massenhaft bunte Infografiken – gespickt mit mehr oder weniger naiven Forderungen, Allgemeinplätzen und vermeintlich einfachen Lösungen, wie ich angeblich aus dieser Situation herauskomme.
Schau ich mir die Herausforderungen und Hindernisse bei meinen Kunden an, dann klafft dort ein riesiger Spalt zwischen den Lösungsvorschlägen und der gelebten Realität.
Ich habe mir die letzten Jahre immer wieder den Spaß gemacht und ein Gedankenexperiment durchgeführt – Wenn ich einen solchen Tipp oder Infografik sehe, dann überlege ich mir:
Und wie hätte das einem meiner Kunden in seiner konkreten Situation helfen können?
Warum die Schaumschlägertipps dennoch funktionieren
Ich glaube, es gibt einen Grund, warum die ganzen Schaumschläger-Tipps funktionieren:
- Sie bieten eine Rechtfertigung, ein wohliges Gefühl und eine trügerische Sicherheit – „Der Führungskraft fehlt einfach das agile Mindset. Da kann man nichts machen.“
- Sie sorgen für bunte, mit Post-its vollgepflasterte Büroräume, teure Design Thinking-Workshops und agile Spielchen. Es ist zwar knuffig, das anzusehen – aber ich kenne niemanden, dem das im Alltag eine Erleuchtung gebracht hat.
Die eigentliche Gefahr des Nichthandelns
Wenn der Scrum Master seine Führungskraft oder einem beliebigen anderen Manager nicht davon abhalten kann, …
- das Team in Ruhe an der wichtigsten Aufgabe arbeiten zu lassen,
- die spezielle Arbeitsweise, die sich für das Team bewährt hat, nicht öffentlich zu hinterfragen oder
- Entwickler X aus dem Team abzuziehen, weil sonst beide Projekte scheitern werden
dann funktioniert Scrum nicht zuverlässig. Und dann ist die Frage der Führung mehr als berechtigt:
„Ist Scrum überhaupt das richtige Vorgehen für unser Team? Ist es nicht zu starr und unflexibel?„
Wenn wir in dieser Situation ehrlich zu uns sind, dann lautet die Antwort:
„Nein, diese Scrum-Interpretation ist nicht das richtige Vorgehen für unser Team. Und ja, diese Scrum-Interpretation ist tatsächlich zu starr und unflexibel.“
Natürlich ist es die Pflicht des Scrum Masters, die Augen offen zu halten, Feedback der Führung und der Partnerteams dankend entgegenzunehmen und dieses dann ins Team einzustreuen. Es geht ja auf allen Ebenen um Zusammenarbeit.
Aber Unternehmen sind oft nicht der Ort des Friedens und der Eintracht. Jeder im Unternehmen hat seine eigene subjektive Sicht, wie Dinge laufen sollten. Manchmal geht es um Machtspielchen, manchmal sind es ehrliche und gut gemeinte Ratschläge, manchmal das Bedürfnis, etwas beizutragen. Das ist wertvoller Input für den Scrum Master, nicht aber für das Team.
Deshalb muss ein Scrum Master diplomatisch vorgehen. Diplomatisch vorgehen heißt, dass ich als Botschafter im Ausland nicht dem jeweiligen Ausland diene, sondern immer die Bedürfnisse meines Landes vertrete – selbst auf die Gefahr hin, in einem autoritären Regime verhaftet oder entführt zu werden.
Wenn ich als Scrum Master nicht den Mut aufbringe, meiner Führungskraft, dem mittleren Management oder meinem CEO Paroli zu bieten, dann bin ich ein Teil des Problems, vermutlich sogar die Ursache dafür, dass mein Team seinen Job nicht machen kann.
Zahlen, Daten, Fakten führen zu Vertrauen
Es gibt ein einfaches Instrument, mit dem Sie als Scrum Master ihr Team schützen können: Zahlen, Daten, Fakten.
Es geht der Führung immer darum, Risiken zu minimieren, unnötige Ausgaben zu reduzieren und die Effizienz des gesamten Unternehmens sicherzustellen. Dafür brauchen sie das Vertrauen, dass das Team zuverlässig Ergebnisse liefert.
Im Gegensatz zum klassischen Projektmanagement ist die agile Arbeit sogar darauf ausgelegt, die passenden Messwerte dafür zu liefern, mit denen sich tagesaktuell Vorhersagen treffen lassen können, wie es weitergeht.
Wie eine Wettervorhersage oder Konjunkturprognosen handelt es sich hierbei auch um empirische Vorgersagen. Das heißt konkret:
- Wir schauen uns das Wetter von gestern an.
- Wir schauen in die Glaskugel, welche Herausforderungen die nächsten Wochen anstehen.
- Daraus berechnen wir einen Vorhersagenkorridor, der dann eine valide Planungsgrundlage bildet.
Dieser Vorhersagenkorridor können Sie dann dafür nutzten, um
- die Führungskräfte davon zu überzeugen, dass Sie sich auf dem richtigen Pfad befinden,
- Zusagen an Partnerteams und den Product Owner zu geben, wann ein bestimmtes Feature fertig ist und
- mit dem Team gemeinsam die vergangenen Experimente und Maßnahmen zu bewerten und neue zu beschließen.
Letzteres ist dann die sogenannte „empirische Prozesssteuerung“.
Die Voraussetzung dafür: Das Sprint-Commitment!
Das Ganze funktioniert nur dann, wenn das Team in jedem Sprint bereit ist, ein Commitment abzugeben – und dieses auch einhält. Dafür muss klar sein, wie hoch die Verfügbarkeit des Teams ist und wie die Velocity des Teams ist.
Erst durch diese Transparenz können die nötigen Messwerte generiert werden, die wiederum für die Vorhersagen herhalten und die dann dafür sorgen, dass das Team in einem geschützten Rahmen arbeiten kann.
Von nichts kommt nichts – Sie müssen es schon auch umsetzen
Ich weiß nicht, wie viele Aha-Effekte Sie bei der Lektüre dieses Artikels hatten. Ich kann mir sehr gut vorstellen, dass Ihnen vieles davon bereits bekannt war. Das Problem in den Teams ist nicht, dass sie Ihre Möglichkeiten nicht kennen. Das Problem, mit dem Sie kämpfen ist, dass diese Teams es nicht umsetzen.
Das Schöne für Sie: Mit vergleichsweise wenig Aufwand können Sie genau da hinkommen, wovon andere träumen – ein funktionierendes Team, das sowohl die Entwicklung, als auch den Betrieb unter einen Hut bekommen.
Ich wünsche Ihnen den Mut, ab heute einfach mal zu machen statt lange zu analysieren. Und wenn Sie dabei Unterstützung möchten, kommen Sie gerne auf uns zu!