Wie wir ohne retro 7 mal schneller wurden

Zwei Perspektiven auf neun Punkte

Eines Tages saß ich mit meinem Coachee, einem Scrum Master, zusammen und analysierte die letzte Retroperspektive. Mein Scrum Master war ratlos: Maßnahmen wurden durch das Team nicht umgesetzt und stapelten sich oder führten nicht zum gewünschten Erfolg. Die langen Releasezyklen von 6 Monaten blieben!

Neulich fiel mir zu dieser Situation eines meiner Lieblingsrätsel ein: Verbinde neun Punkte, die in 3 Reihen zu 3 Punkten angeordnet sind mit 4 geraden Linien ohne den Stift abzusetzen. Versucht euch einmal selbst daran bevor ihr weiterlest!

Dieses Rätsel zeigt uns, dass es gar nicht so leicht ist aus bestehenden Denkmustern auszubrechen und neue Perspektiven einzunehmen. Wir schöpfen üblicherweise aus dem uns bekannten Möglichkeitsraum.

Genau dies ist der Grund, warum es in der folgenden Geschichte ein großer Erfolg war die Retro auszusetzen! Lest gerne weiter, wenn ihr wissen wollt, wie es meinem Scrum Master dadurch gelang die Releasezyklen um das 7-Fache zu verkürzen.

Von der blauen und roten Welt

Zurück zu unseren 9 Punkten. Viele versuchen die Punkte innerhalb des Quadrats der neun Punkte zu verbinden, weil sie aufgrund ihrer Erfahrung in dieser Art und Weise denken. Allerdings führen nur Linien zum Ziel, die länger sind als das durch die Punkte gebildete Quadrat! Ähnlich verhält es sich in der Art und Weise, wie wir Probleme in der Arbeitswelt lösen. Häufig hilft es erst, eine andere Perspektive einzunehmen.

Komplizierte Probleme werden durch Wissen gelöst. Das Ergebnis ist ein Plan.

Unsere Art zu Denken ist durch den Taylorismus geprägt. Frederik Winslow Taylor war ein US-amerikanischer Ingenieur, der zu seiner Zeit sehr erfolgreich mit einer Perspektive auf Unternehmensführung wurde, die „Scientific Management“ genannt wurde. Diese Perspektive basierte darauf, dass es zu Taylors Zeiten Anfang des 20. Jahrhunderts sehr erfolgreich war, Probleme mit vorhandenem Wissen planerisch zu lösen.

Ein Zeitgenosse Taylors, Henry Ford, hatte sein Auto „Model T“ jahrzehntelang in der gleichen Art und Weise auf Grundlage des „Scientific Managements“ gebaut und verkauft. „Der Kunde kann das Auto in jeder Farbe haben, solange es Schwarz ist“ soll er einmal sinngemäß gesagt haben.

Komplizierte Probleme sind genau durch diesen geringen Grad an Veränderung gekennzeichnet. So lassen sie sich durch Wissen lösen. Das Ergebnis ist ein detaillierter Plan. Die Frage ist also nach dem dem Wie? Wir nennen das die blauen Probleme. Mit dieser Perspektive werden noch heute Probleme gelöst, allerdings auch die, die schon längst nicht mehr mit Wissen und einem Plan gelöst werden können.

Komplexe Probleme werden durch Ideen gelöst. Das Ergebnis ist Vorbereitung.

Heutzutage werden Autos nicht mehr drei Jahrzehnte lang in der gleichen Art und Weise gebaut. Moderne Modellpflegezyklen sind maximal ein halbes Jahr lang! Diese Probleme sind komplex. Komplexe Probleme zeichnen sich durch einen hohen Grad an Überraschungen aus. Sie brauchen auch kein Wissen, sondern Ideen, die auf Erfahrung beruhen. Denn da der Grad der Überraschungen hoch ist, kann es gar kein Wissen für die Lösung geben! Das Ergebnis ist gute Vorbereitung, um mit den Überraschungen umgehen zu können. Es braucht also einen Mensch mit Ideen. Die Frage ist also nach dem Wer?

Lösungen aus der blauen Welt

Zurück zur Retro: Das Team meines Scrum Masters hatte ebenfalls ein Problem. Mein Scrum Master schilderte mir, dass das Team Releasezyklen von 6 Monaten hatte. Etwas verzweifelt gestand er mir, dass der Kunde sich eher 4 Wochen wünschte! Das Team hatte auch eine Retro, in der dieses Problem immer wieder zur Sprache kam. Die abgestimmten Maßnahmen waren z. B.

Die Einführung eines Wikis, um schneller durch die Wiederverwendung von Wissen zu werden.
Die Etablierung von Continuous Delivery, um durch die Automatisierung von Tests und Deployments schneller zu werden
Und das Refactoring der Codebasis, um durch Synergieffekte ebenfalls an Geschwindigkeit zu gewinnen.

Ich begann zu bemwerken, dass aus der Perspektive des Teams dies sicher sinnvolle Maßnahmen waren. Ich erklärte meinem Scrum Master, dass sie allerdings auf einem tayloristischen Glaubenssatz basierten: Durch Wissen wie z. B. den Aufbau eines Wikis und der Konservierung dieses Wissens in Prozesse und Pläne, wie z. B. im Rahmen eines festgelegten Coninuous Delivery oder einer homogenen Codebasis, kann ich schneller werden!

Lösungen aus der roten Welt

Ich fragte meinen Scrum Master, wie er das Problem lösen wolle. Sein erster Reflex war darüber nachzudenken, wie er das Team dazu bringen konnte, die Maßnahmen endlich umzusetzen! Ich lud ihn ein einmal von der Annahme auszugehen, dass das Team deshalb die Maßnahmen nicht umsetze, da sie dem Team keinen Erfolg versprachen. Das Team spürte eventuell instinktiv, dass die Maßnahmen nicht auf das Problem passten.
Wir stellten außerdem fest, dass die Retro dazu führte, dass durch die häufige Nennung der Maßnahmen aus dem tayloristischen Glaubenssatz heraus, diese immer mehr in der Kommunikation des Teams an Bedeutung gewannen. Die Retro beschleunigte also nicht die Veränderung, sondern verlangsamte bzw. verhinderte sie sogar und zementierte das tayloristische Lösungsdenken! Was tun?

Rufen wir uns einmal in Erinnerung, welchen Zweck die Retro erfüllen soll. Neben der Betrachtung, was gut gelaufen ist und was nicht gut gelaufen ist, soll die Retro laut der Scrum Guide ebenfalls „Annahmen, die das Team in die Irre geführt haben, identifiziert und ihre Ursprünge erforscht werden.“ Diese Aufgabe der Retro findet in den meisten Umgebungen allerdings kaum Beachtung!

Wie lädt man nun das Team dazu ein, eine dysfunktionale Annahme zu erkennen? Indem man die kognitiven Dissonanzen aufzeigt. Eine kognitive Dissonanz ist z. B. die Lücke zwischen Anspruch und dem tatsächlichen Ergebnis. Mein Scrum Master stellte also drei Dinge da:

Erstens: Die Durchlaufzeiten der Releases lagen seit über 2 Jahren bei 6 Monaten.
Zweitens: Die Maßnahmen, die durchgeführt wurden, hatten keine Verbesserung gebracht.
Drittens: Viele abgestimmte Maßnahmen wurden nicht durchgeführt.

So schaffte der Scrum Master eine Bereitschaft eine grundlegende Veränderung durchzuführen. Das Aussetzen der Retro! Der Interventionsimpuls bestand darin zunächst Aufklärungsarbeit zu betreiben und die unterschiedlichen zwei Annahmen und die Voraussetzungen für ihre Wirksamkeit herauszuarbeiten:

Wissen und Pläne für komplizierte Probleme: Frage nach dem Wie.
Ideen und Vorbereitung für komplexe Probleme: Frage nach dem Wer.

Die Aufklärungsarbeit führte der Scrum Master mit dem Team im Zeitraum der früheren Retro durch, so dass auch das Verhältnis von Arbeit und der Beschäftigung mit der Arbeit nicht weiter anstieg.

Das Ergebnis dieser Arbeit war die Wahl eines Kollegen, den das Team Ideen zutraute, die sowohl die fachliche Komponente des Kundenproblems, als auch die zeitliche Komponente lösten. Es stellte sich also nicht mehr die Frage nach dem Wie inkl. der Anwendung von Wissen und Plänen, sondern die Frage nach dem Wer. Der Kollege führte u. a. folgende Veränderungen ein:

Er nutzte Story Splitting und den Fokus auf den Kundennutzen, um kleinere und trotzdem nutzenorientierte Veränderungen am System zu ermöglichen
Er implementiere eine Priorisierung, die auf die Bedürfnisse des Kunden abgestimmt war

Das Ergebnis dieses Prozesses überraschte dann selbst mich! Vier Wochen nach dem Ergreifen dieser Maßnahme hatte ich meinen regelmäßigen Austausch mit dem Scrum Master. Das Treffen eröffnete er mit den Worten: „Das Team hat gestern nach vier Wochen released“.

Mit der Zeit erkannte das Team die Vorteile dieser neuen Herangehensweise. Sie konnten sich besser auf ihre individuellen Stärken konzentrieren und die Zusammenarbeit mit dem Könner ermöglichte es ihnen, komplexe Probleme des Kunden auf eine effektivere Weise anzugehen.

Mein Scrum Master und ich freuten uns sehr über die positive Entwicklung. Gemeinsam hatte das Team bewiesen, wie wichtig es ist, den Unterschied zwischen komplexen und komplizierten Problemen zu verstehen und die richtige Herangehensweise an beide zu wählen.

Das heißt…

Es gibt keinen starren Ansatz, der für alle Situationen gilt, sondern es ist wichtig, flexibel und anpassungsfähig zu sein, um die besten Lösungen für das vorliegende Probleme zu finden.

Wir sind deshalb erfolgreicher, wenn wir Instrumente nicht als Methoden begreifen, sondern als Werkzeuge, die uns beim Denken helfen. Dabei hilft es enorm darüber nachzudenken, ob

Es sich um ein kompliziertes / blaues oder komplexes / rotes Problem handelt
Bei blauen Problemen das Wie unter Anwendung von Wissen zu entwickeln und bei roten Problemen nach dem Wer zu fragen, der dann Ideen entwickelt

Und ihr? Welche Lösungen haben bei euch funktioniert, wenn Retros nicht den erhofften Erfolg bescherten?

Wenn euch diese Art der differenzierten Betrachtung gefallen hat, dann schreibe ich auch in Zukunft gerne über das eine oder andere (nur) vordergründig eindeutige Instrumente der agilen Organisationsentwicklung. Lasst es mich mit einem Daumen oder in einem Kommentar wissen! In diesem Sinne: Ich wünsche euch eine Woche voller spannender Rätsel und leuchtender Schätze!

Wie wir ohne Retro 7 x schneller wurden