Im + am System arbeiten: nicht nur Symptome reparieren, sondern Spielregeln ändern

"Unser Umsatz ist gesunken" könnte Veränderung auslösen, aber auch die Feststellung "die Fehlerquote ist gestiegen", womöglich ist auch eine erhöhte Fluktuationsrate Anlass.

Die Beteiligten fragen sich: ""Wie können wir das Phänomen verändern?". Häufig stellt sich die Frage, wie das bestehende System verbessert oder geändert werden kann. Die Beteiligten suchen also nach einer Lösung im System. Die Frage, ob das System als Solches noch passt, wird seltener gestellt. Das ist eine Lösung am System.

UserStorys + Anforderungsaufnahmen weisen häufig ins + aufs System

In vielen agilen Teams ist zu beobachten, dass diese auf unvollständige Abnahmen reagieren, in dem sie versuchen, die UserStorys näher zu detaillieren + noch genauer zu beschreiben.

Dabei verlieren die Beteiligten leicht aus dem Blick, dass die UserStory den Zweck für die Nutzer*innengruppe beschreibt + Abnahmekriterien beschreibt. Zug um Zug, Retrospektive für Retrospektive mutieren die UserStorys zu Featurebeschreibungen. Wenn die Beteiligten nun weiter die UserStorys optimieren und zum Beispiel "Vorstudien" und "Sprint Zeros" für klare Abnahmekriterien aufführen, bleiben sie im System.

Am System arbeiten hieße, sich die Frage zu stellen, warum die Abnahmen scheitern + was an dem Vorgang der Anforderungserfassung + der Weitergabe ins umsetzende Team eigentlich schief läuft. Dann sind Fragen am System zu stellen:

• Braucht das Team UserStorys mit Zwecken oder Featurebeschreibungen für eine klare + zügige Umsetzung?

• Stimmt die Iterationslänge?

• Braucht es eine andere Taktung?

• Braucht es eine Rückkopplung mit den Stakeholder*innen und/oder Kund*innen?

• Können die Beteiligten äußern, wenn sie eine Fehlentwicklung bemerken?

Auf das System zu sehen ist anstrengender

Wenn die Beteiligten Lernzyklus für Lernzyklus im System optimieren, obwohl das System als Solches einen Fehler in sich trägt, wird Demotivation + Frust wachsen. Auch können die Beteiligten so sehr leise in eine echte Krise schliddern: weil am Ende einfach nichts mehr stimmt + das System nicht mehr trägt.

Dieser Blick ist anstrengender, weil schon die Frage eine Ansage an die Komfortzone ist. Am System zu arbeiten, heißt Selbstverständlichkeiten, "so macht man das hier" + "so wie beim letzten Mal" in Frage zu stellen.

Mit drei Formaten den Blick auf das System wagen

Ein Blick auf das System kann in einem Team-Highlight oder anlässlich von Jahresrückblicken oder strategischen Meetings erfolgen.

System-Check im Retrospektivenformat

Der System-Check findet außerhalb der üblichen Iteration statt. Die Teilnehmer*innen fragen nicht nur nach Verbesserungen innerhalb des Teams (im Sinne des zwölften Prinzips hinter dem agilen Manifest), sondern sie suchen im Stile einer Retrospektiven (also einer Länge von 90 Minuten) mit einem Blick auf das System. Die übergeordnete Frage lautet: Was zwingt Euch immer wieder, dieselben Probleme zu reparieren?"

Der System-Check wird explizit als Unterbrechung üblichen Ablaufs (also Systems) initiiert.

Während Gather Data suchen die Beteiligten nach wiederkehrenden Mustern, üblichen Kommunikationsabläufen + sich wiederholenden Interaktionen. Diese Muster werden sauber im Ist aufgenommen, nicht bewertet.

Während Generate Insights fragen sich die Teilnehmer*innen, welche Systemannahmen hinter diesen Mustern + Wiederholungen stecken: "Was tut Ihr, weil man das so tut? Was fordert der Prozess?" Schließlich werden die Teilnehmer*innen gefragt: "Wenn Ihr auf Euer Ziel guckt, wie würdet Ihr das auf der grünen Wiese neu machen?" oder "Wie lösen andere Organisationen diese Zielstellung?"

In Decide What to Do entwickeln die Teilnehmer*innen Handlungsalternativen. Es empfiehlt sich, diese in einem Raster nach "leichter Umsetzbarkeit" und "Hebelstärke" zu einzusortieren. So können die Teilnehmer*innen gut wählen. Sie vereinbaren einen Zeitpunkt in einem üblichen Iterationswechsel, in dem sie die Wirkung der Maßnahmen prüfen werden.

2. Wertstrom-Analyse

Mit einer Wertstromanalyse (Value Stream Mapping) können die Beteiligten ermitteln, an welchen Stellen große Wertverluste, Störungen und/oder negative Rückkopplungen entstehen. So können die Beteiligten erkennen, wo sie grundsätzlich andere Lösungen benötigen.

3. Paradox experimentieren

Paradoxe Experimente können Ergebnisse von Retrospektiven, strategischen Meetings oder anderen Formaten sein. Die Beteiligten beschließen, bei Bedarf auch mit den Stakeholder*innen, für eine begrenzten Zeitraum, anders zu handeln + bewusst bestehende Vereinbarungen zu ignorieren: "Für die nächsten zwei Wochen werden wir alle Tickets ohne Freigabe durch Business-Owner*innen bearbeiten." So können die Beteiligten ausprobieren, was passiert, wenn sie Muster brechen oder ignorieren. Auf diesem Wege können die Beteiligten Systemlogiken identifizieren + verändern.

Warum sich der Blick aufs System lohnt

Auf das System zu schauen, ist anstrengend. Nicht, weil es komplizierter wäre als operative Optimierung, sondern weil es unbequemer ist. Schon die Frage, ob das bestehende System noch passt, ist eine Ansage an die Komfortzone. Sie stellt Routinen infrage, die Sicherheit geben.

Gleichzeitig liegt genau dort der Hebel. Solange Beteiligte Lernzyklus für Lernzyklus im System optimieren, reagieren sie auf Symptome. Sie werden besser im Reparieren – und zugleich müder. Denn wenn das System selbst einen Fehler in sich trägt, hilft kein Optimieren, Detaillieren oder das Ergänzen von neuen Regeln.

Der Blick aufs System verschiebt Verantwortung. Weg vom Einzelnen, hin zu den Bedingungen, unter denen gearbeitet wird. Muster werden nicht länger personalisiert, sondern als Wirkung des Systems verstanden. Das schafft keine schnellen Lösungen, aber neue Handlungsspielräume. Und macht ganz andere Ergebnisse möglich, weil die Grenzen sich verschieben.

Der Blick aufs System kostet initial mehr Energie als der Blick ins System.

Diese Energie macht vielfach bessere Ergebnisse möglich.