👋 Schön, dass Du hier bist! Bitte beachte, dass dieser Artikel bereits einige Jahre auf seinem Buckel hat. Seitdem haben sich nicht nur die Welt, sondern auch meine Wissenslücken, Erfahrungen und Ansichten geändert. Dennoch stehe ich hinter den Aussagen, die ich damals getätigt habe. Selbst dann, wenn ich sie mittlerweile anders tätigen würde. Bitte behalte dies beim Lesen im Hinterkopf. Danke. Und viel Vergnügen!
Wenn Rituale wichtiger werden, als die zu erledigende Arbeit.
Die Definition #
Ich gebe zu, ich belächle ja gerne diejenigen, die Scrum beinahe schon wie eine Religion betrachten. Aber eigentlich sind diese Personen ein ziemliches Problem für die Organisation, in der sie sitzen.
Aber zuerst, wen meine ich eigentlich genau?
Scrum-Apologeten sind für mich die Personen, die versuchen, alle Antworten auf alle Fragen im Scrum Guide zu finden. Wenn ein Teammitglied etwas benötigt: lass uns im Scrum Guide nachlesen, dort finden wir sicher die Antwort. Wenn der Product Owner eine Frage hat: lass uns im Scrum Guide nachlesen, dort finden wir sicher die Antwort. Wenn etwas nicht so läuft, wie es im Scrum Guide beschrieben ist: lass uns im Scrum Guide nachlesen, dort finden wir sicher die Antwort.
Die Analyse #
Fangen wir ganz vorne an, bei der Analyse. Warum betrachtet jemand den Scrum Guide als den ultimativen Heilsbringer? Ich glaube ja, da dahinter steckt oft eine gewisse Unsicherheit. Ich habe dieses Verhalten meist bei Personen beobachtet, die die Rolle des Scrum Masters, Agile Coaches, Kanban Senseis, Was-auch-immer-toll-nach-Agilität-klingt ohne Vorbereitung umgehängt bekommen haben.
Ihr kennt das sicher, oder? Da beschließt jemand, wir machen jetzt alle Agile. Und dann kommt ein Consultant ins Haus. Frisch von der Uni, gerade bei MBB begonnen. Der liest den Wikipedia-Artikel zu Scrum und lässt über Nacht auf allen Türschildern das Wort Projektleiter durch Scrum Master ersetzen (oder noch schlimmer: Personen ohne Projektmanagementwissen und -erfahrung werden zu Scrum Mastern ernannt). Und die Teamleads heißen ab sofort Product Owner. Dann noch ein schönes Whiteboard aufgehängt und wir sind agil.
Und nun müssen die armen Neo-Scrum Master alle liefern. Ohne zu wissen, wie. Woher denn auch? Ich denke, in so Situationen nimmt man jeden Strohhalm an. Und wenn er auch - anders als das schlaue Buch des Fähnlein Fieselschweifs - weniger als 20 Seiten hat. Wie z.B. die aktuelle Version des Scrum Guides.
Und was ist das Problem? #
Scrum ist ein Projektmanagement-Framework und keine Religion. Steht sogar im Scrum Guide so drinnen. Erste Seite, erster Absatz, viertes Wort: “Scrum is a framework[...]”.
Das bedeutet, Scrum ist nicht mehr und nicht weniger als eine Anleitung, wie ich Projekte erfolgreich abwickeln kann. Eine von vielen. Und genau betrachtet, eigentlich eine ziemlich schlechte. Warum? Weil sie unvollständig ist. Kein Wort zu Risk Management, keine Erwähnung von Critical Paths, keine Phase Gates, kein Initiating, nichts.
Ich weiß schon. Natürlich ist das Absicht. Der Scrum Guide ist bewusst schlank gehalten. Außerdem hat er einen starken Fokus auf die Arbeit während eines Sprints und wie ich die als Team ideal strukturieren und organisieren kann. Das ganze Drumherum wird da drinnen nicht behandelt. Es geht um die Teamebene. Dafür werden viele Regeln aufgestellt und - für jemanden, der noch nie mit agilen PM-Frameworks zu tun hatte - neue Themen behandelt.
Und da kommen wir wieder zum einzigen Strohhalm unserer ins kalte Wasser geschmissenen Scrum Master. Wenn ich nur ein dünnes Heftchen habe und darinnen auch noch von Artefakten die Rede ist, wird mein Verhalten bald dem von religiösen Eiferern ähneln. Und viele legen dieses Verhalten auch nicht mehr ab.
Von Äpfeln und Stämmen #
Jede Scrum Masterin, jeder Scrum Master hat für das Team eine Vorbildwirkung. Sollten wir zumindest haben. Das ist im Normalfall sehr hilfreich. Im konkreten Fall wird das jedoch schnell ziemlich problematisch. Denn dann habe ich nicht nur fanatische Scrum Master, sondern fanatische Teams. Da wird dann schnell - und sowas erlebe ich oft - alles abgelehnt, was nicht im Scrum Guide steht - oder in ihn hineininterpretiert wird. Da werden Regeln und Anleitungen so lange verzerrt und dem eigenen starren Scrumgedanken angepasst, bis jegliche Agilität verschwunden ist. In diesen Teams wird jedes Scrum Meeting prozessiert. In diesen Teams wird jedes Artefakt zelebriert. Und in diesen Teams werden Rituale wichtiger als das eigentliche Ziel: den Kunden zufrieden zu stellen. Und das ist ein Problem. Denn diese Teams sind dann
- nicht produktiv und
- das Gegenteil von dem, was sie vorgeben zu sein - sie sind nicht agil.
Nicht produktive Teams kosten Geld, ohne welches zu verdienen. Unagile Teams bringen in agile Organisationen und Umfelder eine große Unruhe hinein. Das ist beides nicht zufriedenstellend, finde ich.
Woran erkenne ich solche Teams? #
Teams, die Scrum ritualisiert haben, erkennt man oft schon am Türschild. Da hat die Squad dann einen möglichst nerdigen Teamnamen. “Das hat der Coach gesagt, dass das Scrum ist.” Coaches sind auch ein Anhaltspunkt. Jede Religion hat Rollen, deren Aufgabe es ist, die jeweilige heilige Schrift auszulegen und ihren Inhalt zu deuten. Ich schaue auch ganz gerne in Kalender. Da findet man dann fixe Daily Standup-Meetings, viele Refinements, lange Retros, gerne auch mal zwei Retros pro Sprint, viele eingeladene Personen bei Reviews. Generell wird viel Zeit mit Reden verbracht.
Das sind natürlich Punkte, die wir alle einmal mehr oder weniger (durch-)gemacht haben. Und das ist auch alles per se nicht schlecht. (Gut funktionierende, produktive Teams kommunizieren sehr viel. Miteinander und mit anderen Teams. Aber das Reden dient dazu, die Arbeit voran zu bringen. Unproduktive Teams kommunizieren auch viel. Da geht es dann aber mehr um die Auslegung und Richtigkeit von Regeln.)
Diese Punkte werden dann problematisch, wenn es nur mehr um das Wie und nicht mehr um das Was geht. Wenn alles starr und unflexibel ist. Wenn der Customer Value nur mehr gepredigt, aber nicht mehr gelebt wird. Wenn die vielen kleinen und großen Rituale wichtiger geworden sind, als die Arbeit.
Nicht alles Neue ist automatisch gut #
Ja, der Scrum Guide ist toll. Aber nochmal: er hat original 19 Seiten. Davon sind aktuell eine Seite Deckblatt, eine Seite das Inhaltsverzeichnis und eine Seite die Endnote. Bleiben 16 Seiten mit Inhalt. Gutem Inhalt. Aber Ihr glaubt doch nicht wirklich, in diesen 16 Seiten, Antworten auf alle Fragen zu finden, denen Ihr so in Eurem Arbeitsalltag begegnet?
Es gibt Teams, die setzen Scrum sehr streng nach den Regeln um und es läuft gut. Weil die vielen Regeln und Abläufe, die im Team so entstehen und gelebt werden, zufällig mit den neuen Regeln harmonieren. Aber ich habe auch genug Teams erlebt, wo die gewachsenen mit den neuen Richtlinien komplett über Kreuz gelegen haben. Da ist es dann manchmal gut, fünfe gerade sein zu lassen und sich erst mal auf die wichtigsten Grundpfeiler zu einigen.
Nicht alles Alte ist automatisch schlecht #
Bloß, weil ein windiger Coach das behauptet hat, ist Wasserfall - wie das klassische PM dann gerne verächtlich genannt wird - nichts schlechtes. Ganz im Gegenteil! Es hängt halt - wie so oft im Leben - davon ab, was ich machen möchte. Und Scrum ist nunmal ein “unkomplettes” Framework. Also bin ich vielleicht gut beraten, nicht alle alten Zöpfe gleich abzuschneiden, sondern behutsam vorzugehen. Im Projektmanagement muss ich nicht das klassische töten, um das agile zu bekommen. Ganz im Gegenteil, die beiden harmonieren in vielen Punkten recht gut miteinander. Das sollte ich zumindest einmal in Erwägung ziehen. Dann laufe ich auch nicht Gefahr, Scrum mit einer Religion zu verwechseln.
#scrum #agilität
Vielen Dank für Deine Zeit! Du kannst den Artikel gerne teilen. Und ich freue mich immer, von Euch zu lesen. Bilder von freestocks.org auf Unsplash.
← Vorheriger Artikel: Warum wir nicht richtig kommunizieren
→ Nächster Artikel: Modernes Projektmanagement - der methodische Teil
Veröffentlicht am