Die Reise nach Mordor – Kernprobleme in komplexen Systemen identifizieren
TL;DR: Die Methode „Die Reise nach Mordor“ hilft Teams, den wahren Ursprung von Problemen in komplexen Systemen zu finden. Durch das Visualisieren des Systems und das Verorten von Problemen wird der Fokus auf die effektivsten Lösungsansätze gelenkt, was zu tiefem Systemverständnis und besserer Akzeptanz führt.
Worum geht es?
In komplexen Umgebungen fällt es Teams oft schwer, die Ursache von Problemen zu erkennen und nicht nur Symptome zu bekämpfen. Die Methode „Die Reise nach Mordor“ bietet einen spielerischen, aber tiefgründigen Ansatz, um das umgebende System zu verstehen und den „Ort des Übels“ – den Ursprung der meisten Schwierigkeiten – sichtbar zu machen. Indem das Team eine „Landkarte“ des Systems erstellt und alle bekannten Probleme darauf verortet, lassen sich Hebelpunkte für nachhaltige Verbesserungen identifizieren.
Die Methode auf einen Blick (Methoden-Steckbrief)
| Kriterium | Details |
|---|---|
| Einsatzgebiet | Systemverständnis schaffen, Ursachenanalyse von Problemen in Software-Architekturen, Organisationen, Produktentwicklung, Zusammenarbeit mit anderen Bereichen |
| Zielgruppe / Größe | Teams (erst alleine, dann in Gruppen 1-2-4-All); reife Teams können es auch ohne Moderation anwenden |
| Dauer | Nicht spezifiziert |
| Material | Miro, Post-its, Zeichenmaterialien |
| Schwierigkeitsgrad | Nicht spezifiziert (Moderation kann „etwas anstrengend“ sein) |
Der konkrete Mehrwert für das Team
- Schafft ein tiefes und gemeinsames Systemverständnis im Team.
- Fokussiert die Problemlösung auf die wahren Ursprünge und nicht nur auf oberflächliche Symptome.
- Ermöglicht eine natürliche Priorisierung von Problemen durch die Konzentration am „Mordor-Ort“.
- Fördert die Akzeptanz für bestimmte Probleme, wenn deren Ursache an anderer Stelle im System Vorteile bringt.
- Identifiziert effektive Hebelpunkte für Refactoring, Umpriorisierungen oder die Klärung von Konflikten.
Schritt-für-Schritt-Anleitung
- Probleme sammeln: Startet eine normale Retrospektive und sammelt alle aktuellen Probleme, die das Team belasten. Legt diese gesammelten Probleme vorerst zur Seite.
- Systemlandkarte erstellen: Der Moderator schlägt vor, eine Landkarte des umgebenden Systems zu malen. Dies kann die gesamte Software-Architektur, die Organisationsstruktur oder die relevanten Arbeitsbereiche umfassen.
- Individuelle Karten: Jedes Teammitglied erstellt zunächst alleine eine eigene Landkarte. Dies kann in Miro mit Post-its oder als Zeichnung erfolgen.
- Karten zusammenführen: Führt die individuellen Karten in kleinen Gruppen zusammen (z.B. mit der Methode „One, Two, Four, All“) bis eine große, gemeinsame Systemlandkarte entsteht.
- Probleme verorten: Der Moderator nimmt ein gesammeltes Problem-Post-it und fragt das Team: „Wo nimmt dieses Problem seinen Anfang?“ Das Problem wird auf der Landkarte an seinem vermuteten Ursprungsort platziert. Dies wird für alle gesammelten Probleme wiederholt.
- Ursprünge überprüfen: Wenn alle Probleme auf der Karte platziert sind, überprüft das Team gemeinsam: „Sind tatsächlich alle Probleme dort, wo sie ihren Ursprung haben?“ Sortiert die Probleme gegebenenfalls um, bis sie am tatsächlichen Ursprungsort kleben.
- „Mordor“ identifizieren: Der Bereich der Karte, an dem die meisten Probleme ihren Ursprung haben, ist „Mordor“ – der Fokuspunkt für die weitere Arbeit.
- Lösungsansätze entwickeln: Mit dem richtigen Mindset (keine Schuldzuweisung) diskutiert das Team: „Wie ist es dazu gekommen?“ und „Was können wir jetzt tun, um es besser zu machen?“
- Maßnahmen ergreifen: Leitet konkrete Maßnahmen ab, z.B. Refactoring, Umpriorisierung von Features oder Klärung von Prioritätenkonflikten mit angrenzenden Teams.
Stolpersteine & Tipps für die Moderation
Die Rolle des Moderators kann „etwas anstrengend“ sein, da es oft nicht der erstbeste Schritt ist, der zum wahren Ursprung eines Problems führt. Es erfordert Beharrlichkeit, die richtigen Fragen zu stellen und das Team dazu anzuleiten, tiefer zu graben. Ein entscheidender Tipp ist das richtige Mindset: Statt zu sagen „dieses Repository ist scheiße“ oder „dieses Team ist Grütze“, sollte der Fokus auf die oberste Direktive gelegt werden: „Wie ist es dazu gekommen?“ und „Was können wir jetzt tun, um das Ganze besser zu machen?“. So vermeidet man Schuldzuweisungen und fördert eine konstruktive Lösungssuche.
Häufig gestellte Fragen (FAQ)
Was bedeutet „Mordor“ in dieser Methode?
„Mordor“ symbolisiert den Ort im System, an dem die meisten Probleme ihren Ursprung haben. Es ist der zentrale Punkt, auf den sich die Energie des Teams für eine nachhaltige Lösung konzentrieren sollte.
Warum ist ein Systemverständnis so wichtig für die Problemlösung?
Ein tiefes Systemverständnis hilft Teams, nicht nur die Symptome eines Problems zu behandeln, sondern dessen wahre Wurzel zu finden. Nur durch das Verstehen des Kontextes und der Zusammenhänge können nachhaltige Lösungen entwickelt werden.
Was tun, wenn der Ursprung eines Problems nicht verändert werden kann?
Selbst wenn ein identifiziertes Problem nicht direkt gelöst werden kann, weil seine Ursache an anderer Stelle im System einen positiven Zweck erfüllt, hilft die Methode, dieses Problem besser zu verstehen und zu akzeptieren. Das Team gewinnt Klarheit und kann bewusstere Entscheidungen treffen.
Kann diese Methode auch ohne einen externen Moderator eingesetzt werden?
Ja, laut Podcast ist die Methode auch für „sehr reife“ Teams ohne externe Moderation anwendbar, da solche Teams in der Lage sind, sich selbst kritisch zu hinterfragen und die Ursachenforschung eigenverantwortlich durchzuführen.
Tiefer eintauchen: Die komplette Folge
Die Reise nach Mordor: Das Kernproblem in komplexen Systemen identifizieren
Heute tauchen Florian und Jan in eine spannende Methode ein, die sie liebevoll „Die Reise nach Mordor“ nennen. Inspiriert von „Der Herr der Ringe“, zielt diese Methode darauf ab, in komplexen Systemen – sei es eine Software-Architektur, eine Unternehmensorganisation oder ein Produktentwicklungsprozess – den eigentlichen Ursprung eines Problems zu identifizieren.