Warum agile Transformationen scheitern

Warum agile Transformationen scheitern - und wie wir es anders machen

Wer Scrum einführt und alle schult, wird agil. Rollen besetzen, Zeremonien ansetzen, das mittlere Management zertifizieren, für die erste Zeit Coaches dazuholen. Nach zwei Jahren arbeitet die Organisation anders.

An diesem Satz stimmt mehr, als seine Kritiker zugeben. Scrum ist eine gute Methode. Sie macht in kurzen Abständen sichtbar, woran gearbeitet wird und was davon fertig ist, und sie zwingt eine Organisation, in Wochen zu denken statt in Quartalen. Sie lässt sich unterrichten, und zwar wirklich: Nach zwei Tagen können Menschen die Rollen benennen, das Verfahren erklären und ein Board führen. Auch die Einführung selbst ist ehrliche Arbeit. Sie kostet Geld, Zeit und Aufmerksamkeit, und niemand nimmt das aus Eitelkeit auf sich.

Sie beantwortet nur eine Frage, die niemand gestellt hat.

Zwei Fragen, die nicht zueinanderfinden

Vor jeder Einführung steht eine Unzufriedenheit. Meistens klingt sie ungefähr so: Warum dauert es bei uns so lange von der Entscheidung bis zur Auslieferung. Oder: Warum merken wir erst beim Kunden, dass wir das Falsche gebaut haben. Das sind Fragen über das Geschäft. Sie haben mit Verfahren zu tun, aber sie sind keine Verfahrensfragen.

Die Einführung beantwortet eine andere. Sie beantwortet, wie Scrum funktioniert. Auch das ist eine sinnvolle Frage, und die Antwort darauf ist gut dokumentiert und gut vermittelbar. Beide Fragen haben also Antworten. Nur verbinden sie sich nicht von selbst. Damit sie es tun, muss jemand aufschreiben, welches Problem die Methode kleiner machen soll, und zwar so, dass man in einem halben Jahr nachsehen kann, ob es kleiner geworden ist. Das ist der Satz, der in den meisten Einführungen fehlt.

Er fehlt nicht aus Nachlässigkeit. Er fehlt, weil er unbequem ist. Wer aufschreibt, dass sich die Zeit von der Idee bis zum ersten zahlenden Kunden halbieren soll, hat sich festgelegt und kann in einem Jahr widerlegt werden. Wer stattdessen aufschreibt, dass die Organisation agiler werden soll, kann das nicht. Der zweite Satz ist bequemer, und deshalb steht er in fast jeder Programmvorlage.

Warum das Ritual gewinnt

Eine Organisation ohne Erfolgsmaß misst, was sie sehen kann. Sichtbar ist, ob die Zeremonien stattfinden, ob die Boards gepflegt sind, wie hoch die Schulungsquote ist, wie viele Zertifikate im Haus sind. Das ist kein Zynismus, das ist die einzige verfügbare Auskunft. Wenn niemand sagen kann, was besser werden soll, bleibt als Fortschritt nur, das Verfahren korrekter auszuführen als im Quartal davor.

Daraus folgt fast alles, was danach als Widerstand beschrieben wird. Das Daily wird zum Statusbericht, und das ist keine Verfehlung des Teams. Wenn nicht gesagt ist, was schneller gehen soll, ist ein Statusbericht eine vernünftige Verwendung dieser fünfzehn Minuten. Die Retrospektive bleibt ohne Folge, weil das, was folgen müsste, außerhalb der Reichweite des Teams liegt. Der Product Owner verwaltet Tickets, weil er kein Mandat hat, keine Zeit und keinen Zugang zu den Menschen, für die er entscheiden soll. Die Entscheidung fällt weiterhin drei Ebenen höher, und niemand erlebt das als Widerspruch. Für ein Ziel, das nie benannt wurde, gibt niemand Zuständigkeit ab.

Auch die Schulung der Führungsebene läuft in diese Lücke. Sie vermittelt ein Verfahren. Was sie nicht vermitteln kann, ist ein Auftrag. Wer am Montag weitermacht wie vorher, hat nicht schlecht zugehört. Ihm hat nur niemand gesagt, welche seiner Entscheidungen ab jetzt anders ausfallen soll und woran er merkt, dass er es richtig gemacht hat.

Der Preis, den niemand einplant

Das Teuerste an einer Einführung ohne benanntes Problem sind nicht die Honorare und nicht die Schulungstage. Es ist, was die Leute dabei lernen. Sie führen über Monate korrekt aus, was von ihnen verlangt wird, und sehen, dass sich nichts ändert. Dass die Stimmung danach schlechter ist als vorher, ist keine Undankbarkeit. Es ist ein zutreffender Schluss aus dem, was sie beobachtet haben: dass Anstrengung hier nichts bewegt.

Diese Erfahrung überlebt jedes Verfahren. Sie steht in keinem Abschlussbericht, aber sie ist im Haus, und die nächste Veränderung trifft auf Leute, die schon zu wissen glauben, wie das ausgeht. Das ist der eigentliche Grund, warum zweite und dritte Anläufe schwerer sind als der erste. Nicht die Methode hat sich verbraucht, sondern die Bereitschaft, sie ernst zu nehmen.

Was sich morgen aufschreiben lässt

Was hilft, ist kein anderes Rahmenwerk. Es ist ein Satz, der Namen und Datum verträgt. Was soll in einem halben Jahr anders sein, woran wird man es sehen, und wer außerhalb des Projekts merkt es. Wenn es die Lieferzeit ist, steht dort die heutige und die angestrebte. Wenn es die Trefferquote ist, steht dort, wie oft eine Funktion heute beim Kunden ankommt, bevor jemand widerspricht. Der Satz muss nicht klug sein. Er muss überprüfbar sein.

Wenn niemand im Raum diesen Satz schreiben kann, ist die Einführung nicht zu früh. Sie hat keinen Adressaten. Dann lohnt sich die unbequemere Vorarbeit, nämlich herauszufinden, welches Problem eigentlich gemeint war, als zum ersten Mal jemand sagte, wir müssten agiler werden. Diese Frage kostet ein paar Wochen. Sie kostet weniger als zwei Jahre gut gepflegte Boards.

Agilität ist kein Zustand, den eine Organisation erreicht. Sie ist eine Behauptung darüber, was schneller gehen soll und für wen. Wer die Behauptung nicht aufschreibt, kann sie auch nicht widerlegen. Übrig bleibt dann nur die Frage, ob das Verfahren korrekt ausgeführt wurde. Und die lässt sich immer mit Ja beantworten.