Lasst doch bitte den Herrn Stacey in Ruhe

Die Stacey-Matrix wird gerne benutzt, um eine Auswahl an Werkzeugen darzustellen, die nach dem Komplexitätsgrad des zu lösenden Problems und der Kenntnis über die passenden Lösungen angeordnet sind. Das häufige Missverständnis dabei: Viele Menschen meinen, sie müssten nur in der Matrix das richtige Werkzeug (z. B. ein Management-Framework) auswählen, aber das ist zu trivial.

Was wollte Stacey mit seiner Grafik eigentlich erreichen?

Interessanterweise hatte Stacey kein Interesse daran, Probleme und Lösungen in einer Matrix anzuordnen. Er wollte mit dieser Grafik, die er übrigens gar nicht als Matrix verstanden wissen wollte, darstellen, wie sich Menschen verhalten, wenn sie vor ungewohnten Problemen stehen. Er wollte situative Führung erklären und das Paradoxon aufzeigen, wie Führungskräfte sich in Entscheidungssituationen verhalten: Je größer die Unsicherheit und die Uneinigkeit von Menschen in einer zu entscheidenden Situation sind, desto mehr verschiedene Sichten müssen einbezogen und desto tiefgehender muss die Situation durchdacht werden. Meist ist aber im Verhalten von Entscheiderinnen und Entscheidern genau das Gegenteil zu beobachten. Je komplexer die Situation, desto weniger Sichtweisen holen die Führungskräfte tendenziell ein. Details dazu können Sie gerne in diesem Beitrag von Frank Habermann nachlesen.

Welches Werkzeug nutze ich?

Das, was gemeinhin als Stacey-Matrix bezeichnet wird, ist also weder von Stacey noch eigentlich eine Matrix, denn das würde bedeuten, dass jedem Problem ein eindeutiger Lösungsweg zugeordnet werden kann. Aber die Probleme sind subjektiv und die Lösungen individuell. Deshalb müsste aus meiner Sicht eine sinnvolle „Stacey-Matrix“ so aussehen:

In diesem Diagramm wird auf der y-Achse der Grad der Unbestimmtheit des zu lösenden Problems eingetragen und auf der x-Achse die Lösung für das Problem. Je weniger Erfahrung ich habe oder je weniger ich das Problem bzw. die Lösung beschreiben kann, desto höher bzw. weiter rechts platziere ich diese Problem-Lösung auf der y- bzw. x-Achse, da die Unbestimmtheit jeweils größer wird.

Dazu zwei Beispiele:

1. Ein Unternehmen betritt ein neues Marktsegment. Wie hoch ist der Grad der Unbestimmtheit darüber, was Kundinnen und Kunden wollen und wie man dieses Wollen mit Produkten und Services erfüllen kann? Wahrscheinlich ist er eher hoch. Dieses Problem und seine Lösung liegen eher oben rechts im Diagramm.
2. Ein erfahrener Hausbauer wird das Problem des Hausbaus sicherlich auf der x-Achse weit links und auf der y-Achse weiter unten platzieren. Sollte ich, Conny, allerdings das zu lösende Problem des Hausbaus bewerten, würde ich wohl auf der x-Achse viel weiter rechts landen und auf der y-Achse viel weiter oben.

Daran können Sie sehen, dass die Bewertung in diesem Diagramm subjektiv ist und immer nur eine Momentaufnahme. Deshalb teile ich die Flächen im Diagramm auch nicht wie üblich in „einfach“, „kompliziert“, „komplex“ und „chaotisch“ ein, da diese Einteilung in meinen Augen keinen Wert für mich als Nutzer liefert. Auch platziere ich keine Werkzeuge in die Flächen, wie beispielsweise „Scrum“ weiter oben rechts als „Wasserfall“ oder Design Thinking weiter oben rechts als „Scrum“.

Die Kreise, die um die einzelnen Problemstellungen verlaufen, sind die PDCA-Zyklen. Je komplexer das Problem, desto mehr Kreise und desto mehr Zyklen muss ich durchlaufen. Ich plane meine Handlungen (Plan), führe diese aus (Do), beobachte meine Umwelt und was meine Handlungen bewirken und auslösen (Check) und passe ggf. meine Handlungen oder meine Ziele an (Act). Je weiter oben ein zu lösendes Problem platziert ist, desto öfter und schneller muss sich der dazugehörige PDCA-Zyklus zum Lösen des Problems drehen. Dafür brauche ich ein geeignetes Werkzeug. Skizzieren Sie gerne einmal zur Übung, wie eine Problem-Lösung mit Scrum oder Design Thinking innerhalb dieser vier Phasen aussehen könnte.

Nun noch ein weiteres Beispiel, diesmal aus dem Bereich der Fotografie: Beim analogen Fotografieren dreht sich der PDCA-Zyklus sehr langsam. Bevor man sich das Endergebnis anschauen kann, müssen die Negative zum Fotografen gebracht werden, der diese dann entwickelt. Das dauert nicht nur lange, sondern verhindert auch das schnelle Feedback-Einholen, wie man es beispielsweise beim digitalen Fotografieren hat. Wenn ich mit meinem Handy fotografiere, sehe ich das Bild sofort und kann, falls es mir nicht gefällt, den Prozess des Fotografierens adaptieren und sofort wiederholen. Der PDCA-Zyklus dreht sich schneller. Einem versierten und erfahrenen Fotografen ist dieser Fakt wahrscheinlich nicht so wichtig wie mir als Laien.

Umgang mit Komplexität

Je höher ich den Grad der Unbestimmtheit bewerte, sowohl im Kontext „Problem“ als auch im Kontext „Lösung“, desto weniger kann ich diese Problem-Lösung im Voraus beschreiben und planen, desto mehr komplexe (unbekannte) Anteile hat diese Problem-Lösung für mich und desto weniger weiß ich, ob meine Handlungen, bevor ich sie ausführe, „richtig“ oder „falsch“, also zielführend sind oder nicht. (Weitere Eigenschaften von Komplexität habe ich hier zusammengetragen). Das allerdings bedeutet, dass ich mir öfter das Feedback meiner Umwelt holen muss, um zu erfahren, ob meine Handlungen geeignet sind, um das Problem zu lösen. Der PDCA-Zyklus muss sich schneller und öfter drehen.

Agil ist nicht gleich besser

Menschen wollen mit der Stacey-Matrix herausfinden, ob ein Problem agil oder nicht agil gelöst werden sollte, was kompletter Unsinn ist. Wo ein Problem und eine Lösung im Diagramm platziert sind, hat rein gar nichts damit zu tun, ob die Lösung agil oder nicht agil ist. Kommen wir zum Beispiel des Hausbaus zurück. Welchen Nutzen hat es, wenn ich einen erfahrenen Hausbauer, nur weil er seine Problem-Lösung des Hausbaus im Diagramm unten links platziert, als nicht agil bezeichne und mich, da ich mich weiter oben rechts platziere, als agil? Was ich dabei oft höre: Agil ist besser. Das ist Unsinn. Wenn ich in einer bestimmten Problem-Lösung viel Erfahrung habe und sie deshalb unten links platziere, ist es gar Verschwendung, wenn ich meinen PDCA-Zyklus oft drehen lasse.

Auch, wie oben bereits angesprochen, kontextlos Werkzeuge in dieses Diagramm einzuordnen, ergibt in meinen Augen keinen Sinn. Wenn ich beispielsweise beim Verwenden des Werkzeugs Scrum die Sprintlänge erhöhe (der PDCA-Zyklus verlangsamt sich), weil ich dann nicht so oft reflektieren muss, ob ich noch in die richtige Richtung agiere, wandert das Werkzeug „Scrum“ nach unten links im Diagramm. Ich könnte also das gleiche Werkzeug je nach Problem-Lösung in alle Bereiche im Diagramm einordnen, immer abhängig davon, wie schnell ich den PDCA-Zyklus drehen lasse. Das Werkzeug bleibt das gleiche. Die Methode ändert sich. Mit diesen Gedanken im Kopf sind also weder der Wasserfall noch Scrum agil oder nicht agil.

Erfahrung entscheidet über Komplexität

Einen weiteren Grund möchte ich anmerken, warum es nicht sinnvoll ist, Werkzeuge wie Scrum, Kanban oder Design Thinking kontextlos im Diagramm zu platzieren: Auch die Erfahrung der Menschen im Umgang mit diesen Werkzeugen ist entscheidend. Je weniger Erfahrung ich im Umgang mit Werkzeugen habe, desto häufiger sollte ich meine Handlungen überprüfen, desto öfter dreht sich also der PDCA-Zyklus. Sollte ich also beispielsweise eine Wand mauern, müsste ich sicher öfter messen, ob die Mauer auch in der Waage ist, als es beispielsweise ein erfahrener Maurer tun müsste, auch wenn wir die gleichen Werkzeuge benutzen. Je mehr komplexe Anteile ein zu lösendes Problem hat, desto wichtiger und entscheidender wird der Mensch, der lernt, ein passendes Werkzeug zu wählen und dieses angemessen einzusetzen. Details dazu können Sie hier lesen.

Ich hoffe, ich habe Ihnen zusätzlich zur Stacey-Matrix, die eigentlich gar nicht so heißen dürfte, mit dem Diagramm der PDCA-Zyklen ein weiteres Werkzeug an die Hand gegeben, mit dem sie zukünftig ihre Werkzeuge zum Problemlösen auswählen.

Titelbild: Pexels License, Pixabay