Systems Thinking und Team Coaching

Es ist Weihnachten und viel Zeit neue Dinge zu lesen - aber wie all das gut verarbeiten?

Viele Anregungen die ich derzeit bekomme, kommen aus der LeSS Trainer Kandidaten Gruppe - insbesondere zum Thema Systems Thinking, LeSS Einführung (Adoption) und agile Skalierungsframeworks (ich bin auch SAFe Trainer und habe kürzlich in einem Projekt mit dem Spotify Ansatz rsp. ING Way of Working gearbeitet).

Gleichzeitig bereite ich mich auf meine Scrum Team Coach (CTC) Zertifizierung vor und überlege, wie ich den recht dokumentenlastigen und feedbackarmen Prozess verbessern kann, indem ich mir selber Feedback bei Kollegen hole. Der Plan ist, in München eine Gruppe von Scrum Coaches zu gründen, die mit kollegialer Fallberatung arbeitet und die daraus gewonnene Erfahrungen für eine online Mentoring Gruppe von Scrum Practitioner/Coaches zu nutzen.

Durch die CTC Zertifizierung komme ich immer wieder auf drei Coachingansätze zurück, die mich maßgeblich beeinflusst haben:

- Solution Fokused (SF, lösungsorientiertes) Coaching, worin ich auch ausgebildet wurde und ein paar Jahre (2008/2009) - besonders in Retrospektiven intensiver praktiziert habe
- Human Systems Dynamics, Eoyangs Container-Differences-Exchanges (CDE) Modell, Organisationen als komplexe adaptive Systeme (CAS). Da möchte ich mehr zu lernen und auch verstehen, wo denn die Gemeinsamkeiten und Unterschiede zu Systems Dynamics und Solution Focus etc. bestehen.
- Lernende Organisationen, wo Systems Thinking und Mentale Modelle nur 2 Disziplinen neben Gemeinsame Vision, Persönliche Meisterschaft und Team-Lernen sind. Dazu gehören auch Argyris Action Science (Model 1 & 2 in Use, Ladder of Inference, Balance Inquiry & Advocay) und dessen praktische Anwendung in Schwartz Skilled Facillitator Ansatz. Auch da gibt es noch viel zu lernen - und vielleicht sollte ich da anfangen, da dieser Ansatz sehr praxisnah und gleichzeitig theoretisch sehr fundiert erscheint. Fragt sich nur wie die empirische Absicherung des Ansatzes aussieht!

Hackman's Leading Teams zähle ich auch im weiteren Sinne zur Learnenden Organisation dazu. Dort geht es um die inneren, strukturellen Voraussetzungen für Team Effektivität - Entwicklung der persönlichen Meisterschaft, Team-Lernen und Kundenzufriedenheit - und den externen Faktoren (System-Kontext), der dies erst ermöglicht und unterstützt. Auf diesem Ansatz basiert der Team Diagnistic Survey (TDS), den ich auch schon in der Praxis angewendet habe:
http://www.lauriate.com/tools/team-diagnostic-survey/
http://team-diagnostics.com/the-model/

Hackman's Ansatz kennt außerdem mehrer Stufen der Selbstorganisation und wurde auch schon in Zusammenhang mit Eoyangs CDE Model gesetzt, um Selbst-organisation im Team zu erklären:
https://www.infoq.com/articles/what-are-self-organising-teams

Somit schließt sich dort der Kreis ein wenig, auch wenn in der 5. Disziplin der Fokus eher auf Dialog, der Balance von Inquiry & Advocay und Double Loop Learning liegt. Der Skilled Facilitator Ansatz vereinigt beide Modelle:
- das Group Effectiveness Model von Hackman und
- Argyris (mentales) Modell 1

Bleibt die Frage nach dem lösungsfokussierten Team Coaching Ansatz
- humble Inquiry ist sicherlich ein wesentlicher Teil des Coaching Einstellung
- darüber hinaus Positivität, der Happiness Faktor

Kein Wunder also, dass sich manche SF Fans in diesem Zusammenhang auch mit Theory Y, intrinsischer Motivation und Drive (Sinn, Autonomie und Meisterschaft) beschäftigen. Hier verweist der hardcore SFler meist auf Studien in der Positiven Psychologie: man ist ja empirisch ausgerichtet und beschreibt was funktioniert, lehnt aber jede Theorie ab, da dies nur den Blick für das was schon da ist und funktioniert verschleiert. Alle Modelle und Theorien sind falsch, manche aber nützlich - Basta!
Und wenn ein Kunde ein Modell, eine Theorie oder Framework benutzt, um sich die Welt zu erklären? kein Problem. Dann lernen wir die Sprache des Kunden verstehen, fragen, nach Beispielen, woran wir dieses und jenes denn beobachten können, und wie es aussieht, wenn es besser ist ... - immer an der sichtbaren Oberfläche bleiben und nicht ins psychologieren kommen :-)

Durch Klaus Schenck, einen Freund, lösungsfokussierten Coach und Experten für Molekularbiologie von Nerven- & Immunsystem, komme ich immer wieder dazu, mich auch weiterhin mit dem Zusammenhang dieser Themen zu beschäftigen, mit seinem CORFU Modell, der darauf aufbauenden SF Topologie und dem Wishbone Tool. Das Akronym steht für „Core Fractal Unit (of Viable Systems)“, also für die kleinste Einheit von Systemen, unabhängig von Art und Größenordnung des Systems. Das kleinste System ist demnach ein Paar - was spannend ist, weil es einen Bogen spannt von CAS über SF Paar Therapie hin zu Pair Work im agilen Bereich. Und last but not least seh ich einen Zusammenhang zu Tribal Leadership, wo die Entwicklung von Stufe 3 (49%) "lone warrior, I'm great, you suck" zu Ebene 4 (22%) "Tribal pride, we are great, they suck" über Paare (Dyaden), Triaden und Teams, zum Tribe (Team von Teams, Zenturie) führt. Diese kleinen Systeme gibt es übrigens auch im Coaching, bei Coaching von Einzelpersonen als
- 1 on 1 Coaching (Monade)
- Kollegiale Beratung und Kreis Coaching (Speichen-Dyade)
- Co-coaching, Pair Coaching (Triade mit einem Driver Coach mit Fokus auf Einzelperson, Navigator Coach mit Fokus Ganze/System und einem Coachee)
http://www.triballeadership.net/business-culture/five-stages-of-culture

Das gleiche auch für das Coaching von Team, und jetzt kommt's - wenn man das Team als eine Einheit, als System betrachtet. Aber was heißt das?

Dank der LeSS Gruppe habe ich einen tollen Video von Russell Ackoff dazu angesehen, der sehr anschaulich und humorvoll erklärt, was er unter einem System versteht:
https://www.youtube.com/watch?v=OqEeIG8aPPk

Die für Agilisten nicht unbekannte Ausgangssituation:
2/3 of all quality improvement programs are a failure Why did the programs fail? Because there were not embedded in systems thinking

- das System/die Organisation als Ganzes ist mehr als die Summe seiner interdependenten Teile (Bsp. Auto)
- Veränderung der Teile und/oder ihrer Interaktion führen zu einer Veränderung der Eigenschaften oder des Verhaltens des Systems
- die Verbesserung eines Teils des Systems führt nicht zwangsläufig zur Optimierung des Systems als Ganzes (lokale Optimierung, Bsp. ein Auto, aus den besten verfügbaren Teilen zusammenzusetzen, führt nicht zwangsläufig zum besten Auto, weil die Teile nicht unbedingt zusammenpassen und daher nicht das Auto als Ganzes verbessern - ganz im Gegenteil)
- Effektivität geht vor Effizienz - das Richtige falsch zu machen ist besser als das Falsche richtig (Drucker)
- Wenn man nicht weiß, was das Richtige ist (e.g. value demand vs failure demand) ist es besser Nichts zu tun, um dadurch lokale Optimierung zu vermeiden (z.B. Optimierung des Bug Fixing Prozesses)

Das führt mich zu der Frage, was ist denn eigentlich der Zweck einer Produktentwicklungsorganisation - Qualität, die Erwartungen (oder Bedürfnisse?) der Kunden zu erfüllen ihn zufriedenzustellen oder gar zu begeistern? Radical Management sagt ja, genau das. Und verwende NPS um die Kundenzufriedenheit zu messen!

LeSS sagt nein. Agilität/Adaptivität ist das Ziel, die Perfection Vision für LeSS. Aber warum und wozu? Weil wir nicht wissen was die Bedürfnisse des oder Kunden sind - und die Kunden selber auch nicht wissen was ihre Bedürfnisse sind, bevor sie das Produkt nicht gesehen habe (Ford: Wenn ich die Kunden gefragt hätte, was sie denn gerne hätte oder brauchen, wäre die Antwort "schnellere Pferde" gewesen)

Agilität ist also - aus Lean Startup Sicht - wichtig, um den Build-Measure-Learn Zyklus des Customer Development nachhaltig zu verkürzen - double loop learning?: Warum sollen wir in kurzen Iterationen potentiell auslieferbare Software (output) entwickeln? Ja damit wir auf der schneller ein Produkt entwickeln können, dass den "Anforderungen des Marktes" genügt (outcome, product market fit) Leider wissen wir aber nicht, was die Anforderungen sind, sondern müssen sie erst durch gezielte (customer development) Experimente finden. Also: bevor wir nicht wissen was Effektivität bedeutet, sollten wir auch nicht die Effizienz der Software Entwicklung verbessern - das würde nur lokaler Optimierung führen. Oder?

Lean Product Development (Reinertsen's Product Development Flow) und Kanban besagen: Willst Du häufiger, schnelleres Feedback zu Deinen Produkt Inkrementen, dann reduziere die Transaktionskosten - z.B. durch Automatisierung von Integration, Systemtest und Deployment - sprich, mit agilen Praktiken wie User Stories ATDD, TDD und Continuous Integration, Delivery und Deployment.

Die LeSS Vertreter würden sagen, für dies Erkenntnis brauchen wir nicht Lean Startup: es gab schon immer den Product Owner Zyklus mit Vision und Product Backlog und den Team Zyklus mit Sprint Planning, Sprint Review und potentially shippable increment am Ende. Das Feedback aus dem Review wirkt sich auf beide Zyklen aus:

- dem PO (und dem Scrum Team als Ganzes) hilft es das Produkt an die Marktanforderungen anzupassen. Leider bekommt man qualitativ hochwertiges Feedback dazu im Sprint Review eher selten, repräsentative Nutzer sind schwer zu finden, Entscheider haben ihre eigenen, oft wenig repräsentativen Vorlieben und haben kaum Zeit. Quartalsweise größere Reviews und Usability Tests würden vielleicht helfen.

- der PO kann seine (hoffentlich relevanten) Prioritäten im Backlog der aktuellen Lieferkapazität (Velocity) des Teams anpassen

- dem Entwicklungsteam hilft das Feedback seine Definition von Done zu verbessern und ihre Kapazität für den nächsten Sprint besser abzuschätzen - sich nicht über-zu-committen. Auch das funktioniert bei dem allgegenwärtigen Zeitdruck selten und die Qualität leidet, was zu noch mehr Verzögerungen und Zeitdruck führt.

Ok, hier sind wir wieder bei Systemen und Feedbackschleifen, wobei die äußere dazu dient, die vorhandene Kapazität optimal zu nutzen, um den Bedarf an hochprioren Features zu bedienen, die innere Schleife, die Qualität auf hohem Niveau zu halten oder gar zu verbessern. Auch letztere dient der Kundenzufriedenheit, denn sie lieben Features (insbesondere Begeisterungsfeatures) und Kunden hassen high prio bugs, die verhindern, dass sie arbeiten können oder nur unter erschwerten Bedingungen arbeitsfähig sind. Kurzum, Kunden hassen es generell zu warten und gehen speziell im Internet nach wenigen Sekunden woanders hin, um das zu bekommen, was sie möchten. Und das sollte - neben Kunden zu begeistern - bedeuten, auf keinen Fall Kunden warten zu lassen -

Speed is King - aber nicht Zeitdruck. Wenn der PO gut priorisiert und dadurch den Wert der Arbeit des Teams optimiert und das Team qualitativ hochwertige Software liefert, gerät man erst garnicht unter Zeitdruck - vorausgesetzt die Rahmenbedingungen passen und sind verhandelbar (z.B. Agiler Festpreis "change for free", "money for nothing" und Ausstiegsklausel für beide Seiten, auch für den Fall, dass es schlecht läuft).

So, ich hoffe der Zweck der Software Entwicklung im Zeitalter des Digital Business ist damit klarer geworden auch damit ein wesentlicher Bestandteil des Systems. Ebenso die Hebel, die sich in vielen Projekten schon bewährt haben:

- gute Priorisierung nach Kundenmehrwert und Risko, aber auch nach dem Kano Model (Begeisterungs- vor Leistungsfeatures und 80:20 bei Basisanforderungen). Konzepte aus der Release Planung wie Walking Skeleton (Feldweg) und MVP (Landstraße) gehören ebenfalls dazu.
- DoD kontinuierlich verbessern, technische Exzellenz (XP Praktiken, Clean Code) und Software Craftsmanship Ehre hochhalten
- geschützter Sprint, Team schützen und fokussiertes Arbeiten
- last but not least: Impediments rechtzeitig sichtbar machen und schnellstmöglich beseitigen

OK, und wo ist da der Bezug zum Coaching?
Das Wissen über Agile Softwareentwicklung als System hilft die richtigen Fragen zu stellen und damit die Aufmerksamkeit auf die "kriegsentscheidenden" Dinge zu lenken. Visuellen Management unterstützt diesen Prozess zusätzlich. Dazu zwei Schlagworte aus dem Scrum Umfeld:

- Make it visible
- Inspect & Adapt
- Ask the Team

Diese empirische, selbst-steuernde Vorgehen passt sehr gut zu folgenden SF Prinzipien:

- Veränderungen passieren ständig - unsere Aufgabe ist es die wünschenswerten Veränderungen zu finden und zu verstärken.
- kein Problem hält ständig an, mit immer gleicher Intensität, es gibt meist (funktionierende) Ausnahmen vom Problem
- wenn etwas (auch nur ein kleines bisschen) funktioniert, mach mehr davon
- wenn etwas (trotz ernsthafter Bemühungen) nicht funktioniert, versuche etwas andere (s.o.)

Am wichtigsten ist dabei aber die Überzeugung rsp. Einstellung, dass unsere Klienten alles zur Lösung eines Problems nötige mitbringen - auch wenn es manchmal wiedergefunden werden muss:
a) Wissen, was für sie wünschenswert ist
b) Fähigkeit zu unterscheiden, was für sie besser ist und was nicht
c) Stärken, die sie nutzen können, um Schritt für Schritt ihrer Wunschvorstellung näher zu kommen
d) (intrinsische) Motivation ihre Wünsche zu leben
e) Zuversicht, dass sie selber etwas in die eine oder andere Richtung verändern können (dass sie eine Unterschied machen können)
f) Widerstandsfähigkeit, dass auszuhalten, was sich jetzt gerade nicht so einfach verändern läßt
...

Und so ist es die Aufgabe des Coaches, dass was beim Kunden schon innerlich vorhanden ist, hervorzuholen und für ihn nutzbar zu machen - seine Handlungsfähigkeit soweit zu stärken, das er wieder ohne unsere Hilfe aus-kommen kann.

Dazu passt ein wunderschönes Zitat von Michelangelo:
„Der David war immer schon da gewesen. Ich musste lediglich den überflüssigen Marmor um ihn herum entfernen.“