Da Scrum in aller Munde ist, passiert es nicht selten, daß Projekte in Schieflage (ein Hurra auf den Festpreis) mit Scrum etwas aufgepeppt werden sollen. Das soll dem sowieso längst nicht mehr zu haltenden Termin wieder eine Chance geben. Nette Idee, aber genauso unrealistisch wie die Planung, die solch einer Idee meist vorausgegangen ist.
Nun kann man der Idee nicht grundsätzlich allen Charme absprechen. Scrum, wenn einigermaßen aufgesetzt und vernünftig begleitet, kann etwas verbessern. Wenn das Team nicht sowieso schon völlig zermürbt dasteht, nachdem es verzweifelt versucht hat, zu retten was noch zu retten ist, besteht die Möglichkeit, durch mehr Verantwortung und eigenständiges Handeln verschüttete Effizienzpotentiale zu heben. Die vorangegangenen Erfahrungen haben meist zusammengeschweißt und die meisten Team-Mitglieder spüren immer noch ein Verlangen, die Sache voranzubringen. Wie gut, wenn jemand da ist, der Behinderungen aus dem Weg räumt, die dies bisher nicht möglich gemacht haben.
Ein guter Scrum Master, der es versteht, Impediments zu identifizieren und zu beseitigen, kann diesen Effekt verstärken. Dazu muß er allerdings besonderes Spitzengefühl an den Tag legen. Verstörte Teams, die noch immer versuchen, die Quadratur des Kreises zu erreichen, in dem sie Zeit einzusparen versuchen wo es nur geht, damit der Termin doch noch gehalten werden kann, müssen erst mal aus ihrem Dornröschenschlaf aufgeweckt werden. Die Erkenntnis, daß man zwar besser werden kann, aber die Realität nicht zu überlisten ist, ist schwer zu verdauen.
Meist haben sich unstrukturierte Vorgehensweisen eingeschlichen, die sich in der Vergangenheit einmal als Lösung für aufgetretene Problem bewährt hatten. Dieses Verhalten steht dem von Scrum meist entgegen. Unterbrechungsfreies Arbeiten muß erst einmal wieder neu erlernt werden. Die Bewertung beider Verhaltensweisen ist meist vertauscht. Aus der Situation heraus getriebenes Arbeiten wird als effizient betrachtet und die von Scrum vorgegebene Taktung als eine Art Korsett. Leider wird dabei übersehen, daß die ständigen Unterbrechungen den Arbeitsfluss derart stören, daß an effizientes Arbeiten nicht mehr gedacht werden kann.
Im Prinzip wird dieses Vorgehen tatsächlich als belastend empfunden, aber gleichzeitig als alternativlos bewertet. Alles andere wird als schlechte Lösung betrachtet. Hierbei kann es zu einem mühsamen Unterfangen für den Scrum Master werden, die "paar" Scrum Regeln zu etablieren. Ohne Management-Support ist das kaum zu erreichen.
Allerdings ist ein Commitment des Managements erst mal als vorläufig einzustufen. Man läßt Scrum in diesen Projektsituationen selten aus Überzeugung einführen. Schon eher wird den Erfolgsgeschichten Glauben geschenkt, die man über Scrum gehört und gelesen hat, und leitet für das eigene Projekt eine ebensolche Erfolgchance ab. Der Irrtum ist natürlich vorprogrammiert.
Jeder Scrum Master, der in solch einem Umfeld tätig wird, sollte zunächst dem Management klar machen, daß Scrum nicht die Lösung für die vorhandenen Probleme sein kann. Ein Projektverzug kann allenfalls gemildert, aber niemals gelöst werden. Letzendlich kann nur das Neuverhandeln mit dem Kunden die Problematik bereinigen.
Scrum kann für die Zukunft eine Verbesserung herbeiführen, so daß derartige Verzögerungen mit geringerer Wahrscheinlichkeit auftreten. Man kann allerdings nicht erwarten, daß keine Probleme mehr auftreten, solange nur die Möglichkeit besteht einen ScrumBut zu etablieren. Es ist ein langer Weg, bis das Management erkennt, daß agile Vorgehensweisen effizienter sind. Erst dann kann man versuchen Scrum vollständig umzusetzen. Aber erst einmal muß es überhaupt soweit kommen.
In Krisenprojekten bleibt kaum Zeit etwas so Grundlegendes wie den Wechsel vom klassischen zum agilen Vorgehen zu etablieren. Es ist sehr herausfordernd für den Scrum Master, in vielen Gesprächen die Vorteile von Scrum hervorzuheben und gleichzeitig in einer derart angespannten Lage die zunächst auftretende Langsamkeit zu rechtfertigen. Wenn das Management nicht die Geduld aufbringen kann, also zu schwache Nerven besitzt, dann kann dies im schlimmsten Fall zu einem vollständigen Zurückrudern führen. Das wird dem Team natürlich den Rest geben und die Motivation ist dahin.
Scrum Master sollten sich gut überlegen, wie groß die Gefahr ist, ein derartiges Ergebnis zu erzielen. Im Zweifel sollten sie die Einführung von Scrum nicht unterstützen. Es ist allemal besser, ein Team in seiner Ineffizienz zu belassen, als es seiner Motivation vollständig zu berauben.