Böses, böses Scrum – vor lauter Agilität gescheitert

Veröffentlicht am von

Als ich das erste Mal mit den Ideen der agilen Methoden – allen voran mit dem Framework SCRUM – in Berührung kam, stand ich diesen skeptisch, regelrecht ablehnend gegenüber. Denn naturgemäß versprechen die Macher der Frameworks und deren Vertreter, die Coaches, den Anbruch einer neuen Ära. Allen voran, das glückliche Zusammenarbeiten an sinnstiftenden Aufgaben und die Gewissheit am Ende eines jeden Sprints etwas Neues zu veröffentlichen. Alle Mitglieder eines Teams dürfen mitreden, die Ziele und Erwartungen eines Sprints bestimmen, Aufgaben auch mal ablehnen, oder zumindest hinterfragen, und so weiter und so fort.

Meine größten Sorgen galten der Umsetzung im Alltag und vor allem der zu erwartenden Qualität des Outputs.

Das agile Manifest

  • Individuen und Interaktionen wiegen mehr als Prozesse und Werkzeuge
  • Funktionierende Software wiegt mehr als umfassende Dokumentation
  • Zusammenarbeit mit dem Kunden wiegt mehr als Vertragsverhandlung
  • Reagieren auf Veränderung wiegt mehr als das Befolgen eines Plans

Manifest für agile Softwareentwicklung (https://agilemanifesto.org/iso/de/manifesto.html)

SCRUM ist nicht einfach nur der neueste große Hype

Ich gehe soweit zu behaupten, dass es oft sogar der vermeintliche Rettungsanker ist, an welchen sich verzweifelt geklammert wird, um in der schnelllebigen Zeit mithalten zu können. Die vielgepriesenen Vorteile – schnellere Ergebnisse, gemeinsame Entscheidungen, Mitbestimmung und mehr Identifikation – klingen ja auch verlockend. Allerdings sieht es in der Realität völlig anders aus. Mit höchstem Eifer werden Teams gebildet, Productowner ernannt und die “Definition of Done” festgelegt. Die Aufbruchsstimmung ist so perfekt, dass vor lauter Enthusiasmus vergessen wird, dass es eben nicht ausreicht sich einfach nur mit neuen Titeln zu schmücken.

Oft läuft es wie folgt ab: Abteilungsleiter werden einfach in Productowner umbenannt, das Projektmanagement wird verkleinert, aus der Entwicklungsabteilung wird das Scrumteam und alle anderen sind jetzt die Stakeholder. Die Ergebnisse werden jetzt zyklisch, meist im zwei Wochen Rhythmus präsentiert und danach die nächsten, vom Productowner fertig ausgearbeiteten Aufgaben dem Team aufgezwängt. Aufgaben, welche vom Productowner vergessen worden sind als dringend bestimmt werden, kommen als Hotfix noch zusätzlich in den Sprint. In vielen Fällen schrubbt das Team Überstunden, um die Aufgaben überhaupt zu schaffen, nimmt Fehler bewusst in Kauf, in der Hoffnung sie im nächsten Sprint beseitigen zu können. Ein Kreislauf welcher irgendwann zusammenbrechen wird. Der Schuldige ist dann schnell gefunden: SCRUM.

Was ist passiert?

Um es kurz zu machen: sämtliche Prinzipien von SCRUM wurden missachtet, ja regelrecht misshandelt. Im Grunde genommen hat sich auch nichts geändert: der Productowner ist weiterhin der Lakai Überbringer der Wünsche Anderer und schreibt fleißig Tickets, jetzt allerdings in “Als … möchte ich … um …”-Form und die neue “Freiheit” der Entwicklungsabteilung besteht lediglich darin, zu bestimmen wieviele Punkte ein Ticket hat. Alles Weitere ist geblieben. Die viel gepriesene Selbstbestimmung hatte in einem solchen Umfeld keinerlei Chance sich zu entwickeln.

Agil zu arbeiten bedeutet eben nicht, sich “agil” wie eine Fahne im Wind mit der Meinung der Stakeholder zu drehen.

Ich glaube an SCRUM

Meine Skepsis bezüglich agiler Methoden ist dennoch gewichen. Die Vorteile – wenn richtig angewandt – überwiegen einfach. Die wichtigste Voraussetzung für das Gelingen von SCRUM ist das Mindset Shift auf globaler Ebene. Ein jeder muss sich bewusst sein, dass das gesamte Unternehmen den Transformationsprozess durchlaufen muss. SCRUM stoppt eben nicht an der Bürotür der IT! Schlüsselpositionen wie Productowner und Scrummaster müssen nach Fähigkeiten besetzt werden, keinesfalls dürfen alte Hierarchien einfach nur in die neuen Strukturen übertragen werden. Auch Stakeholder müssen richtig erkannt und ggf. ernannt werden.

Doch die wichtigsten Punkte sind Transparenz und Vertrauen. Nur wenn alle Beteiligten eines Produktes in die Entscheidungsprozesse eingebunden werden, können sie Leidenschaft hierfür entwickeln und den Sinn ihrer Arbeit erkennen. Umso intensiver sich die Teammitglieder mit ihrem “eigenem” Produkt auseinandersetzen umso höher ist auch der Wert ihrer Arbeit. Identifikation ist das Ziel. Aufgaben werden als Team erarbeitet, der Mehrwert für den Nutzer und nicht der Wunsch der Geschäftsführung steht hierbei im Vordergrund.

Produkte werden für Nutzer und nicht für Geschäftsführer geschaffen!

Es erfordert viel Mut von der Geschäftsführung die Verantwortung für ein Produkt auf den Productowner und das Team zu übertragen. Ebenso die gefällten Entscheidungen zu akzeptieren und auf das Team zu vertrauen. Der Productowner muss sich als eigenständig handelnd begreifen und seine Rolle als Sprachrohr der Stakeholder verstehen, um die gestellten Wünsche und Anforderungen mit dem Team besprechen zu können. Auf Teamebene muss sich auf Gleichberechtigung geeinigt werden, Egotrips und Hierarchiedenken sind hier völlig fehl am Platz. Alle müssen zu ihren gemeinsam erarbeiteten Ideen und Aufgaben stehen.

Das ist die Basis. Der Rest ist, salopp gesagt, klassisches Projektmanagement, nur eben im Zwei-Wochen-Takt.

-2