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

Agile Toolbox
Conny Dethloff
April 13, 2021

Table of content

Diesen Beitrag teilen

Das könnte auch interessant sein:

Agile Coach
Agile Management
Agile Organization
Agile Prinzipien
Agile Toolbox

FRAGE: Warum macht ihr eigentlich kein SAFe?

Agile Management
Agile Organization
Agile Prinzipien
Agile Toolbox
Transformation

FRAGE: Was kostet eine agile Transformation?

Agile Management
Agile Organization
Agile Toolbox
Leadership
Agiles Lernen

FRAGE: Welche Rolle spielt Training?

Agile Coach
Agile Management
Agile Organization
Agile Prinzipien
Agile Toolbox

FRAGE: Wer sind die Top 10 agilen Unternehmensberatungen?

Agile Management
Agile Organization
Agile Tools
Agiles Management
Leadership

FRAGE: Wie viel bringt die Investition? Was ist der Business Case dahinter?

Agile Management
Agile Organization
Agile Prinzipien
Agile Toolbox
Führung

FRAGE: Welche sind häufige Herausforderungen, die ihr beim Kunden löst?

Agile Management
Agile Organization

FRAGE: Warum sollten wir mit borisgloger arbeiten?

Agile Management
Agile Organization
Agiles Management
Transformation

FRAGE: Wie viel kostet eine Beratung und ist es wirklich rentabel bei borisgloger?

Agile Prinzipien
Agile Toolbox
Projektmanagement

The Lie Behind the Parable of the Golf Balls and the Jar

Video
Change
Digitale Transformation
Hardware
Agile Organization

Agile in Industrial Automation: The Digital Transformation of Yokogawa

Versicherung
Neues Arbeiten
Führung
Agile Prinzipien
Kundenfokus

Kundenzentrierte Versicherung: Kann ein agiles Projekt die Organisation retten?

Versicherung
Change
Digitale Transformation
Agile Prinzipien
Kundenfokus

Agilität in den Vertrieb bringen – für Versicherer sinnvoll

Versicherung
Agile Prinzipien
Kundenfokus
Agile Toolbox
Produktentwicklung

BizDevOps in der Versicherungsbranche – Wie multidisziplinäre Teams wirklich besetzt sein sollten

Versicherung
Agile Prinzipien
Kundenfokus
Neues Arbeiten
Meetings

Undercover Agile für Versicherer: 5 agile Praktiken für Ihr klassisches IT-Projekt

Versicherung
Change
Digitale Transformation
Agile Prinzipien
Kundenfokus

IT-Projekte in der Versicherungsbranche – Das Rennen um die Time-to-Market

Team
Neues Arbeiten
Agile Prinzipien
Selbstorganisation
Social Skills

Umgang mit Fehlern & Diversität – Erfolgreiche agile Teams #2

Team
Neues Arbeiten
Agile Toolbox
Produktentwicklung

Das Geheimrezept von High-Performance-Teams

Team
Arbeiten bei borisgloger consulting
Agile Prinzipien
Freiwilligkeit
Selbstorganisation

Konsent und offene Wahl: 2 Prinzipien aus der Soziokratie, die jedes agile Team gebrauchen kann

Team
Neues Arbeiten
Meetings
Social Skills

Der agile Adventkalender

Team
Agile Toolbox
Scrum
ScrumMaster-Praxistipps
Agile Prinzipien

Selbstorganisation der Teams fördern: Ask the team!

Team
Agile Toolbox
Design Thinking

Who Recognizes the Truly Good Ideas?

Team
Agile Organization
Transformation

Pizza Is Not Dead, and Neither Is Agility

Scrum4Schools
Neues Arbeiten
Führung
Life
Social Skills

Trauen wir unseren Kindern mehr zu – auch in der Schule!

Scrum4Schools
Change
Agiles Lernen
Neues Arbeiten
Remote Arbeiten

Eine Scrum4Schools-Projekt-Rückschau mit Physiklehrer Ivan Topic

Scrum4Schools
Mehr Formate
Interview
Nachhaltigkeit

Mit Scrum4Schools dem Weltraum auf der Spur

Scrum4Schools
Change
Agiles Lernen

Scrum4Schools - ein Projekt nimmt Fahrt auf

Scrum4Schools
Agile Schulentwicklung
Agile Toolbox

Technik im Alltag - Scrum4Schools zu Gast in Langenzersdorf

Projektmanagement
Agile Toolbox
Scrum
Scrum-Begriffe
ScrumMaster-Praxistipps

Sprechen Sie Agile? Den klassischen Projektplan in die agile Welt überführen

Projektmanagement
Agiles Management
Agile Toolbox
Scrum
Enterprise Scrum

Das Management in Scrum

Projektmanagement
Change
Digitale Transformation

Agilität in der Logistik oder: Liefern wie Amazon

Projektmanagement
Agile Toolbox
Scrum

Meilensteine und Scrum

Portfoliomanagement
Project management

Too many projects? Portfolio management simplified

Neues Arbeiten
Mehr Formate
Agile Toolbox
Scrum
Scrum Values

Wie agiles Arbeiten die Kommunikation aus der Selbstverständlichkeit holt

Neues Arbeiten
Change
Agiles Lernen
Mehr Formate
Audio

New Learning heute für das New Work von morgen – mit Angelika Weis

Neues Arbeiten
Change
Soziale Innovation

New Work Experience 2019 – ein Erfahrungsbericht

Neues Arbeiten
Audit
Change

Agil im Audit: das Starter-Kit

Neues Arbeiten
Agile Toolbox
Scrum
Scrum4Schools
Agile Prinzipien

Scrum4Schools: Lernen für die Zukunft

Neues Arbeiten
Agile Toolbox
Scrum
Scrum Meetings
Retrospektive

Arbeiten wir uns gesund!

Neues Arbeiten
Agile Toolbox
Scrum
ScrumMaster-Praxistipps

Who should be in (agile) HR?

Neues Arbeiten
Agile Toolbox
Scrum
Scrum Values

Glauben Sie an die Seele Ihrer Firma?

Neues Arbeiten
Agile Toolbox
Scrum
Product Owner
ScrumMaster-Praxistipps

Produktivität auf Irrwegen: "Führen wir schnell mal Scrum ein!"

Neues Arbeiten
Agile Prinzipien
Selbstorganisation
Social Skills
Team

Freiwilliges Teilen von Wissen – Erfolgreiche agile Teams #5

Neues Arbeiten
Agile Prinzipien
Selbstorganisation
Social Skills
Team

Doing vs. Being Agile – Erfolgreiche agile Teams #1

Neues Arbeiten
Agile Prinzipien
Selbstorganisation
Social Skills
Team

Freude bei der Arbeit & Sustainable Pace – Erfolgreiche agile Teams #3

Neues Arbeiten
Agile Prinzipien
Selbstorganisation
Social Skills
Team

Anpassungsfähigkeit & schonungslose Offenheit – Erfolgreiche agile Teams #4