Reliable Ultimate Secure Bullshit Scrum

Stellen wir uns kurz die folgende Situation vor: jemand hat noch nie in seinem Leben ein Messer benutzt und beginnt es zu erlernen. Mangels Erfahrung geht er es falsch an, nimmt die Klinge in die Hand, setzt den Griff auf ein Stück Brot und legt los. Das Ergebnis ist verheerend: die Hand ist verletzt, das Brot nicht geschnitten, der Mensch frustriert. Was sollte jetzt getan werden?

1. man sollte ihm beibringen das Messer richtig zu benutzen oder 
2. man sollte versuchen, für ihn ein Messer so zu modifizieren, dass der Griff schneidet und von der Klinge keine Verletzungsgefahr ausgeht.

Die Antwort ist so naheliegend, dass sie nicht verraten werden muss.

Stellen wir uns kurz eine andere Situation vor: ein Unternehmen hat noch nie agil gearbeitet und führt Scrum ein. Mangels Erfahrung geht es in den Stories nur um funktionale Anforderungen, nichtfunktionale Anforderungen wie Sicherheit oder Performance werden vergessen. Wenn das (zu spät) entdeckt wird brechen Hektik und Streit aus, Sicherheit und Lastfähigkeit werden unter Hochdruck und mit Überstunden in die Anwendung gepresst, darunter leiden Qualität und Dokumentation, das Ergebnis ist unbefriedigend. Was sollte jetzt getan werden?

1. man sollte dem Unternehmen beibringen, dass auch nichtfunktionale Anforderungen durch die Product Owner identifiziert, als User Stories formuliert, im Backlog priorisiert und in Sprints umgesetzt werden können
2. man sollte für dieses Unternehmen Scrum so modifizieren, dass die nichtfunktionalen Anforderungen durch zusätzliche, redundante Prozesse eingeführt und durch bürokratisches Controlling verifiziert werden

Die Anwort ist auch hier naheliegend, zumindest für jeden der größere Unternehmen von innen kennt: Option B ist richtig - mehr Prozesse und mehr Bürokratie sind eine bessere Lösung als das Anwenden der Methode so wie sie eigentlich gedacht ist (um Irritationen zu vermeiden, das war gerade Ironie).

Diese Modifikationen von Scrum haben Namen: Reliable Scrum, Ultimate Scrum oder Secure Scrum sind Beispiele, wenn es um die Skalierung geht könnte man auch weitere nennen, wie z.B. Autoscrum. Ihnen allen ist gemeinsam, dass sie auf eine falsche Verortung der Probleme zurückgehen - nicht die gestiegene technische Komplexität, die schnelleren Evolutionszyklen der IT oder die hohen und ständig wachsenden Benchmarks der Konkurrenzprodukte werden als die Ursache für sich ständig ändernde Anforderungen gesehen, stattdessen sieht man den Grund in zu geringer langfristiger Planung, zu wenig Aufgabenteilung, zu wenig Kontrolle und zu wenigen Qualitäty Gates. Verkürzt gesagt - man sieht das Problem darin, dass Scrum nicht wie die Wasserfall-Methodik ist. Es folgt die Umkehr des sinnvollen Vorgehens: statt für das Problem (gestiegene Komplexität und Änderungs-Häufigkeit) die passende Lösung (Agilität) zu finden nimmt man die neue Lösung, entkernt sie, füllt die Leerräume mit den altbekannten aber leider nur bedingt funktionierenden Methoden (Bürokratie, Kontrolle, Hierarchie, etc.) und erwartet, dass das Problem allein durch das Anbringen eines Agile-Label auf den "bewährten" Vorgehensweisen verschwindet.

Leicht verstört könnte man sich jetzt fragen, wie irgendjemand auf die Idee kommt, dass das bloße Umbenennen ineffektiver Methoden zu besseren Ergebnissen führen soll. Die Auflösung: hinter derartigen Vorgängen stecken fast immer zwei Gruppen - zum einen altgediente Mitarbeiter, die Komplexität und Agilität für vorbeigehende Moden halten, denen man durch Etikettenschwindel und "Überwinterung" entgehen kann, zum anderen Unternehmensberater, die die Sehnsüchte dieser Menschen ausnutzen indem sie ihnen vorgaukeln, ihr "verbessertes Agile" biete die Lösung aller Probleme, ohne die Notwendigkeit etwas anderes als ein paar Bezeichnungen für Meetings und Rollen ändern zu müssen.

Leider werden oftmals auf diese Weise genau die Ansätze als Lösung eingeführt, die die Probleme erst richtig befeuern: Planen für die Papiertonne, Ersticken der Produktivität in Dokumentations- und Reporting-Overhead und Verschieben der Arbeit an echten Lösungen in die Zukunft. Das Fatale - bedingt durch (z.T. verordnete) Anfangseuphorie und die Einstellung, dass man dem "neuen" Vorgehen erstmal etwas Zeit geben müsste ("bis es von allen verstanden worden ist") und so lange "die guten Seiten hervorheben sollte" häufen sich zunächst die Erfolgs- und Jubelmeldungen. Wer auf die negativen langfristigen Folgen hinweist gilt als Pessimist, Miesepeter und Blockierer. Wenn die Probleme sich dann türmen werden sie möglichst lange kleingeredet, in der Hoffnung, dass der versprochene Erfolg diese "Kinderkrankheiten" ausgleichen wird. Irgendwann geht auch das nicht mehr, es gibt einen großen Knall und der Offenbarungseid steht an - ohne Projektstop und langwierige Renovierungsarbeiten an Prozess und Produkt kann das Ergebnis der letzten Jahre nur noch weggeworfen werden.

Gut, dass für einen solchen Fall ein Plan B in der Schublade liegt: Man muss nur beim Management deutlich machen, dass man "dieses Agile" von Anfang an für obskur gehalten hat. Nur dadurch, dass man möglichst viel des guten, alten Wasserfall-Vorgehens in die neue Methode gerettet hat konnte überhaupt sichergestellt werden, dass es nur schlimm wurde, und nicht ganz schlimm. Wenn man es schafft damit gehört zu werden, steht dem großen Endziel nichts mehr im Weg - der triumphalen Rückkehr in den gemütlichen alten Betonsarg der Routinen "die wir schon immer so gemacht haben". Dann gilt es nur noch Insolvenz und Standortschließungen so lange herauszuzögern bis die Rente da ist. Und was danach mit dem Unternehmen passiert - ist das Problem anderer Leute.