Passend ist, wer Leistung zeigt aber keine Wellen schlägt.

Definition Leistung: Na ja, so recht zufrieden ist der Kunde mit dem Output des Projekts nicht. Output wird zwar erzeugt, aber der könnte besser sein. Besser in Bezug auf Qualität und Quantität.

Das Bauchgefühl vieler Kunden: Jetzt machen wir in “agil”, aber viel mehr kommt dabei auch nicht raus.

Gesucht: Der Scrum Master, der’s richten tut, aber keine Unruhe und keine Unzufriedenheit verursacht.

Die (oftmals vorgefundene) Situation

Das Projekt – ein SAFe-Projekt – läuft schon eine ganze Weile. 12 Teams hat es und natürlich kommt weder SAFe noch Scrum in seiner Reinform zur Anwendung. Ist auch gar nicht weiter schlimm. Muss gar nicht sein, dass man die Theorie buchstabengetreu umsetzt. Viel wichtiger ist, dass das Mindset das Richtige ist. Das man den Geist der Agilität verstanden hat.

Und hieran mangelt es aber oftmals.

Das Daily wird – seinem Namen gerecht werdend – täglich in eintöniger Trägheit vollzogen, aber der eigentliche Zweck dieses Events ist nicht wirklich erreicht worden. (Siehe dazu auch Scrum: The optimized Daily). Lustlos findet sich das Team zusammen, manche stehen, einige sitzen und ein jeder leiert sein Sprüchlein runter. Am Ende wissen die Teammitglieder oftmals nicht, an was der oder die Kollegin gerade arbeitet oder was der Kollege / die Kollegin gerade zum Abschluss gebracht hat.

Das Review wird, gestreng wie es Scrum sagt, am Ende eines jeden Sprints durchgeführt. Ein echter Mehrwert kann aufgrund der Natur der implementierten Issues des vergangenen Sprints gar nicht gezeigt werden, weil man hauptsächlich an einem notwendigen und auch sinnvollen refactoring des Quellcodes gearbeitet hat. Macht nix, Scrum sagt “mache Review am Ende vom Sprint”.

Das große PI Planning hat stattgefunden und gerade fängt die dritte Iteration an. Das Team trifft sich für das Sprint Planning – weil Scrum das so sagt – und was da geplant wird, läuft dem im PI Planning aufgestellten Plan für die dritte Iteration gänzlich entgegen. Scrum sagt, dass ein jeder Sprint mit einem Sprint Planning beginnt. Dass man im Rahmen des PI Plannings alle Sprints – sorry in SAFe sind das Iterationen – geplant und sich dafür vom Management und den Stakeholdern das GO eingeholt hat, interessiert heute nicht mehr.

Ergo:

Das methodische Vorgehen liegt im Argen.

Und nun kommt er, der versierte Scrum Master, der’s gut machen will. Der optimieren möchte. Der dem Team helfen möchte besser zu werden. Der dem Projekt Gutes tun möchte, der …

… optimieren und damit verändern möchte.

Und schon sind sie da, die Wellen

Man möchte kaum glauben, wie träge und resistent so manches Team auf Veränderung reagiert. Den gewohnten Trott zu verändern, scheint bei so manchem Teammitglieder Schmerz zu erzeugen. Die besten Argumente für den einen oder anderen Optimierungsvorschlag haben keine Chance gegen Erwiderungen wie:

• Das haben wir schon immer so gemacht.
• Die anderen Teams arbeiten auch so.
• Aber Scrum sagt …
• Wir sind anders, als andere Unternehmen.
• Bei uns geht das nicht anders.
• …

Wer glaubt, dass gute Argumente und Logik gegen so etwas ankommt, der glaubt auch noch an den Weihnachtsmann.

Und nun, zum Ungemach der Projektleitung

… die es im Agilen eigentlich gar nicht gibt.

Natürlich setzt sich die Projektleitung NICHT aus Externen zusammen. Das sind zumeist Mitarbeiter des mittleren Managements und die wollen keine (internen) Mitarbeiter bei sich auf der Matte stehen haben, die sich über den bösen, bösen Scrum Master beschweren.

Lautstark beschwert man sich darüber, dass der Neue (in der Regel ein Externer) wohl alles Schei.. findet, was man die vergangen Jahre so gemacht hat. So kann man nicht arbeiten. Mit “dem” kann man nicht zusammenarbeiten.

Was für ein Ungemach für die Projektleitung.

Da nehmen wir uns doch lieber einen bequemen Scrum Master.