On Lean and Agility

Bild: Pexels / Polina Tankilevitch - Lizenz

In den meisten agilen Teams sind die Daily Meetings (Daily Scrum, Daily Standup, Daily Symc, etc) ein fester Bestandteil ihrer Arbeitsweise. In einzelnen Fällen stösst dieses Konzept aber an Grenzen, etwa wegen nicht gegebener gleichzeitiger Verfügbarkeit, wegen Introvertiertheit oder (bei remote-Arbeit) wegen schlechter Internet-Verbindung. Um trotzdem im engen Austausch bleiben zu können, gibt es für solche Teams eine mögliche Alternaltive: digitales Working Out Loud (WOL).

Um Missverständnissen vorzubeugen: bei Working Out Loud handelt es sich in diesem Fall nicht um die seit 2015 entwickelte formalisierte Social Learning-Methode gleichen Namens, sondern um die dahinterstehende, 2010 von Bryce Williams entwickelte Grundidee, die lediglich aus zwei Prinzipien besteht: die eigene Arbeit sichtbar zu machen und sie in Erzählform zu vermitteln. Diese Prinzipien lassen sich auch in Team-interne Kommunikation übertragen.

Um das (in einer nicht-verbalen Form) zu tun braucht es zunächst einen gemeinsamen digitalen Kommunikationskanal. Das kann in der rudimentärsten Form eine Whatsapp-Gruppe sein. in den meisten Firmen sind aber professionelle Tools vorhanden (Teams, Slack, etc.), in denen sich eigene Kanäle für ein Team anlegen lassen. In diesen Chat kann man dann alles eintragen, woran man gerade arbeitet. Damit ist bereits das erste Prinzip erfüllt, die Sichtbarkeit.

Das zweite Prinzip, die Erzählform, ist nötig um die Information über die eigene Arbeit mit dem nötigen Kontext zu versehen. "Ich arbeite an Komponente XY" würde z.B. nicht klar machen, warum diese Arbeit stattfindet. "Ich arbeite wie besprochen an Komponente XY, damit unser Hauptkunde rechtzeitig die Exportfunktion bekommt die wir ihm bis Ende des Monats versprochen haben" macht dagegen den Hintergrund und die Prioritäten deutlich klarer.

Wichtig ist dabei, dass diese Information im Voraus stattfindet. Falls eines der anderen Teammitglieder Einwände, Fragen, Hinweise oder Verbesserungsvorschläge hat, können die dann noch eingebracht werden bevor die Arbeit begonnen wurde. Das Risiko, versehentlich unnötige oder in Relation unwichtige Arbeiten zu beginnen wird so minimiert. Und natürlich kann der Chat bei Unklarheiten auch für schnelle Klärungen und Abstimmungen genutzt werden.

Mit ein bisschen Übung kann diese Art des Working Out Loud einen Grossteil der Kommunikation ersetzen, die sonst in einem Daily Meeting stattfinden würde. Bei entsprechender Nutzung können die ausgetauschten Informationen sogar noch weiter angereichert werden, etwa durch Links zu Anforderungen oder Build Reports, durch angehängte Dateien oder in den Text eingebettete Screenshots und Diagramme. An diesen Stellen kann ein Chatt sogar besser sein als ein Meeting.

Schlechter als in einem Meeting lassen sich in einem Chat dagegen Stimmungen, Emotionen und sonstige soziale Aspekte sichtbar machen. Schlimmstenfalls kann es sogar zu Konflikten kommen, da Sorgen, Ungeduld oder Verärgerung nicht erkannt werden. Ein weiterer wichtiger Punkt ist, dass digitales WOL eine ständige Beachtung des Chats erfordert, was ggf. störend für Konzentration und Produktivität sein kann und zu Stress führen kann.

Digitales Working Out Loud kann also eine brauchbare Alternative zum klassischen Daily Meeting sein, es kommt aber mit einem Preis, dessen man sich bewusst sein sollte. Wenn nicht die oben genannten Gründe (oder ähnlich schwerwiegende) gegeben sind sollte man daher vor einer Umstellung die Vor- und Nachteile gegenüberstellen, und ggf. in einer Testphase erproben, wie der neue Modus funktioniert und mit welchen Effekten er verbunden ist.

Youtube ist und bleibt eine Fundgrube für die bemerkenswertesten Dinge. Das heutige Fundstück ist ein Video eines weitgehend unbekannten E-Learning-Anbieters namens Bean Stalk, der auf wunderbar nachvollziehbare Art und Weise das Konzept des User Story Mappings erklärt.

Was mir beim Ansehen auffällt - ich muss unbedingt wieder meine Visualisierungs-Fähigkeiten trainieren. Vor Corona hätte ich ein ähnliches wachsendes Gemälde wie das im Video auch hinbekommen, nach drei Jahren Miro-Nutzung ist dieses Talent aber etwas eingerostet.

Es gibt einige ältere Dinge die so cool sind, dass sofort zwei Reaktionen hochkommen wenn man sie sieht: 1) "Wow, das gibt es schon so lange?" Und 2) "Oh Mann, warum wurde davon nicht viel mehr gemacht?"
Die Seite Something Agile Lean Something gehört auf jeden Fall in diese Kategorie, denn auf Ihr wurden schon 2015 eine Reihe von Begriffen aus dem agilen Kosmos mit gezeichneten Star Wars-Lego-Figuren erklärt. Leider sind insgesamt nur acht Panels zusammengekommen, die sind aber alle wirklich sehenswert. Hier ist mein Favorit, die Erklärung verschiedener Typen von MVPs:

Zum Vergrössern auf die Grafik klicken

Dieses und die anderen Panels können auf der Seite somethingagileleansomething.com in hoher Auflösung heruntergeladen werden, alle unter der Creative Commons-Lizenz CC BY-NC-ND 2.0.

Fehlt noch etwas um den Popkultur- und Methoden-Nerd vollkommen zu begeistern? Natürlich, ein Easter Egg. Bitte noch einmal alle Augen auf die oben zu sehenden "MVP-Flavors". In ihnen gibt es eine Referenz auf eines der bekanntesten MVPs der Technik-Geschichte. Noch nicht gefunden? Die Auflösung gibt es hier.

Ich möchte noch einmal über die Stacey Matrix sprechen. Diesesmal nicht darüber was sie ist und wofür sie meistens benutzt wird und auch nicht darüber, dass sie ursprünglich ganz anders aussah als auf den mittlerweile üblichen Darstellungen. Beides habe ich an anderer Stelle bereits gemacht (siehe hier und hier). Heute möchte ich eine weitere Einsatzmöglichkeit aufzeigen, und zwar eine die zwar wichtig ist aber leider noch zu selten genutzt wird.

Um mit der Problemstellung zu beginnen: sehr häufig wird die Stacey-Matrix eingesetzt um Vorhaben oder Herausforderungen in eine der vier Kategorien (Einfach, kompliziert, komplex, chaotisch) einzusortieren und sie dann langfristig dort stehenzulassen (meistens verbunden mit der Auswahl eines jeweils passenden methodischen Ansatzes). Das entspricht allerdings im Normalfall nicht der Realität, in der sich früher oder später alles von der Position wegbewegt in die es einsortiert wurde.¹

Darüber hinaus (und jetzt kommt der eigentliche Punkt) erfolgt diese Bewegung im Normalfall nicht in irgendeine Richtung sondern fast immer in die selbe: nach rechts oben. Praktisch jedes Vorhaben in mittleren oder grossen Organisationen wird über die Zeit immer komplizierter, komplexer und chaotischer, bis zu dem Punkt an dem es ohne Gegensteuerung ins Unbeherrschbare abkippt. Und sobald man sich Beispiele dafür ansieht wird auch nachvollziehbar warum das so ist.

Bei einfachen Vorhaben oder Herausforderungen ist eine häufige Ursache die Automatisierung. Die ist im einfachen Bereich richtig und wichtig, was oft übersehen wird ist aber, dass die dafür nötige Hard- und Software mindestens kompliziert, im Zweifel sogar komplex ist. Da sie aber untrennbar mit ihrem Durchführungs-Gegenstand verbunden ist kann auch dieser nicht mehr einfach sein. Eine andere Ursache ist das Outsourcing, das alleine durch Verträge und Zahlungsströme kompliziert werden muss.

Auch im komplizierten Bereich sind es eine eigentlich richtige Massnahmen die zum Abrutschen in die Komplexität führen: die Normierung und Standardisierung vergleichbarer Tätigkeiten sowie ihre Optimierung und Beschleunigung. Ab einem bestimmten Punkt ist der Regulierungsumfang so hoch und die Durchführungsgeschwindigkeit so schnell, dass sich nicht mehr rechtzeitig nachverfolgen lässt welcher Prozess gerade in Kraft tritt oder in Kraft treten müsste. Kleine Kontrollverluste häufen sich.

Dort wo es komplex ist greifen schliesslich zwei Effekte ineinander: das hier sehr effektive Inspect & Adapt führt versehentlich immer wieder zu einem Vorrang kurzfristiger und lokaler Lösungen vor langfristigen und grösseren. Der Reflex das durch übergreifende Kontroll- oder Verwaltungsstrukturen kompensieren zu wollen führt dann ins Chaos -  die Organisation wird schwerfällig und kann nicht mehr rechtzeitig auf die ständigen Störungen und Disruptionen reagieren. Es kommt zum grossen Kontrollverlust.

All das kann man wunderbar anhand der Stacey Matrix erklären, sei es indem man Post-Its oder digitale Kacheln von links unten nach rechts oben wandern lässt oder indem man die Dynamik durch Pfeile darstellt. Und wer eine mittlere oder grosse Organisation auch nur ein bisschen kennengelernt hat wird zahlreiche Beispiele nennen können mit denen sich der Einwand "so etwas würden wir doch niemals bei uns zulassen" widerlegen lässt.

Das Fatale an der so beschriebenen Situation ist, dass sie in einer Zwickmühle endet. Auf der einen Seite führen die an sich richtigen Optimierungsbemühungen früher über später über den Kipp-Punkt hinaus an dem aus Verbesserungen Verschlimmbesserungen werden, auf der anderen Seite führt seine unklare Position dazu, dass ab einem bestimmten Optimierungsgrad Ineffizienz und Ineffektivität nicht mehr weiter beseitigt werden können, wenn man sicher sein will nicht versehentlich zu weit zu gehen.²

Die einzige Möglichkeit mit der sich ein Abkippen in eine dieser beiden Dysfunktionen vermeiden lässt ist die Anwendung von agilen Entwicklungspraktiken auch auf die Organisationsentwicklung selbst. In einem kontinuierlichen, niemals endenden Prozess muss regelmässig überprüft werden ob sich alles noch in der "goldenen Mitte" zwischen Verbesserung und Verschlimmbesserung befindet. Nur so entsteht in der Stacey Matrix-Visualisierung wieder die ausgleichende Bewegung nach links unten.

An dieser Stelle fällt auch einer der am weitesten verbreiteten "agilen Mythen" in sich zusammen: der Mythos, dass der Scrum Master, bzw. Agile Coach sich irgendwann selbst überflüssig macht. Zwar gibt es Teams die in der Lage sind selbst gegen den Sog nach rechts oben zu arbeiten, zu viele verlieren sich aber früher oder später in Routinen, Termindruck und Bestätigungsfehlern - sie brauchen jemanden der ausserhalb des Hamsterrades steht, und hilft dauerhaft gegen diese Strömung zu arbeiten.

Es ist der Schlachtruf der DevOps-Bewegung: Automate all the Things!, ein Anspruch der in seiner radikalen Absolutheit oft von dem Hyperbole and Half-Meme unterstrichen wird. Nicht nur in Bezug auf DevOps sondern mittlerweile auch für die Agilität im Allgemeinen ist diese Haltung zu einem der zentralen Distinktionsmerkmale geworden, ohne sie wäre es vermutlich nicht zu der damit verbundenen Erfolgsgeschichte gekommen. Und doch - mittlerweile sollte man  das Ganze kritisch hinterfragen.

Zur Erinnerung, eigentlich ist Automatisierung in der agilen Produktentwicklung etwas Gutes. Manuelle Release-, (Regressions-)Test-, Dokumentations- und ähnliche Prozesse können schnell absurde Umfänge annehmen, in der Durchführung ewig dauern und gigantische Kontroll- und Koordinierungs-Bürokratien erzeugen. Da das jegliche Beweglichkeit und Reaktionsfähigkeit ersticken würde bleibt nur eines - automatisieren, im Wettlauf gegen die Zeit.

Was im Rahmen dieses Vorgehens aus dem Blick geraten kann ist aber, dass die Automatisierung auch im wahrsten Sinn des Wortes Schattenseiten hat. Nicht umsonst wird sie im Deutschen auch als Dunkelverarbeitung bezeichnet, sobald Prozesse einmal selbstständig ablaufen sind sie vor dem menschlichen Auge verborgen (zumindest in der IT, wo Automatisierung fast immer Digitalisierung bedeutet, unter Umständen sogar irgendwo in der Cloud statt in den eigenen Systemen).

Bedingt dadurch kann es vorkommen, dass Informationen gar nicht mehr auffallen (oder erst dann wenn es zu spät ist). Eines der häufigsten Beispiele dafür sind Burndown-Charts. Dort wo sie manuell an der Wand erstellt werden ist es für ein Team schon früh sichtbar ob es Fortschritte macht oder ob es sich festgefahren hat, dort wo sie automatisiert erstellt werden (z.B. auf einer versteckten Web-Seite in Jira) werden sie oft nur zum Sprintende angeschaut, schlimmstenfalls nie.

Selbst wenn sie sichtbar angezeigt werden, können wichtige Informationen aber übersehen werden. Auch hier gibt es ein häufiges Beispiel: die Summe der Punkte auf den Tickets, die anzeigen seit wann sich hier nichts mehr bewegt hat. Dort wo sie automatisiert hochgezählt werden treten oft schnell Abstumpfungs-Effekte ein, dort wo sie manuell hinzugefügt werden entsteht eine bewusstere Beschäftigung mit dem Thema, die häufiger zu Korrekturmassnahmen führt.

Nicht zu unterschätzen ist auch der Effekt der eintritt wenn die Beschäftigung mit den eigenen Prozessen zu einem Standard-Bestandteil von Regelmeetings wird. Das kann etwa im Rahmen von Reviews oder Retrospektiven stattfinden, es können aber auch eigene Termine dafür geschaffen werden, z.B. solche in denen man gemeinsam die eigenen technischen und organisatorischen Schulden begutachtet. Das Ergebnis ist eine Verankerung der Themen im kollektiven Gedächtnis der Organisation.

Um langsam zum Schluss zu kommen - heisst das, dass man die Prozessautomatisierung doch wieder seinlassen soll? Natürlich nicht, und die bisher genannten Beispiele verleiten auch nicht dazu. Repetitive Tätigkeiten sollen (bzw. müssen) weiterhin automatisiert werden wenn Agilität das Ziel ist, das bleibt unverändert. Eine "Ent-Automatisierung" lohnt sich aber trotzdem, vor allem bei vielen Datenerhebungen, um so Probleme offensichtlich zu machen und Lösungsfindungen anzustossen.

Noch einmal ein paar Worte zur Stacey Matrix, jenem Analyse-Werkzeug des Organisationsforschers Ralph D. Stacey, mit dessen Hilfe meistens versucht wird Sachverhalte als einfach, kompliziert, komplex oder chaotisch einzuordnen. Wie an anderer Stelle geschrieben sind die meisten Anwender in einem Irrtum gefangen - was sie nutzen ist nicht die eigentliche Stacey Matrix sondern nur ihre vereinfachte Version, die Stacey-Zimmermann-Matrix. Das Original ist weitgehend unbekannt.

Der Grund für diese relative Unbekanntheit dürfte sein, dass Stacey's Orginalversion (zu finden u.a. bei Dave Snowden) wesentlich detaillierter und differenzierter ist und damit auch schwerer zu erklären und zu verstehen. Der grobe Aufbau ist zwar ähnlich, je nachdem wo in der Matrix man sich befindet kann die Analyse aber eine andere sein als in der Zimmermann-Ableitung. Selbst die Bezeichnung der Achsen ist eine etwas andere, um Stacey's Orginal zu verstehen sollte man daher nochmal neu beginnen.

Um auch direkt mit den Achsen zu anzufangen - statt "Was" und "Wie" wie in der vereinfachten Version heissen sie ursprünglich Agreement (gemeinsames Verständnis des Sachverhalts) und Certainty (Sicherheit darüber welche Handlungsoptionen gegeben sind). Beide Variablen sind in der unteren linken Ecke am höchsten, sinken aber mit zunehmendem Abstand zu diesem Punkt kontinuierlich ab, bis sie am Ende der jeweiligen Linien nicht mehr gegeben sind.

In der Anwendung folgt daraus, dass dort wo sich die Variablen mit hohen Werten überschneiden (links unten) eine technisch-rationale Entscheidungsfindung und technisch-rationale Kontrollmechanismen möglich sind. Die (nähere) Zukunft ist hier prognostizierbar und planbar, der Umsetzungsfortschritt ist messbar. Zu finden sind solche Situationen dort wo es standardisierte Abläufe und nur wenige Störungen und Änderungen gibt, etwa in der Serienfertigung oder in Call-Centern.

Komplizierter wird es dort wo die Variablen auseinandergehen. Eine hohe Sicherheit über die möglichen Handlungsoptionen bei geringerem Verständnis darüber welche richtig sind führt zu politischem Verhalten (Mitte links). Es wird nötig Bündnisse mit den Vertretern ähnlicher und kompatibler Standpunkte einzugehen, meistens mit der Folge, dass das weitere Vorgehen auf einem Kompromiss beruht, der schlimmstenfalls halbherzige oder unvollständige Umsetzungen nach sich zieht.

Umgekehrt führen eine geringere Sicherheit über die möglichen Handlungsoptionen bei hohem gemeinsamen Verständnis über über das richtige Ziel zu eher subjektiver Entscheidungsfindung (untere Mitte). Die Auswahl der nächsten Schritte beruht in solchen Kontexten auf Glaubenssätzen und Methodismus, überprüft wird eher die Methodentreue als die Sinnhaftigkeit. Schlimmstenfallskann so eine "Entsachlichung" und Emotionalisierung der Diskussionen stattfinden.

Jenseits dieser beiden nebeneinanderliegenden Sektoren liegt die Komplexitätszone, die sich von links oben nach rechts unten durch die Matrix zieht. Auch in ihr gebt es Unterschiede: geringe Übereinstimmung bei hoher Sicherheit verleitet zu Bauchentscheidungen und sprunghaftem Verhalten, hohe Sicherheit bei geringer Übereinstimmung ermöglicht kontrollierte Überprüf- und Lernprozesse, mit dem Ziel auf diesem Weg die beste Lösung zu finden.

Oben rechts befindet sich schliesslich die chaotische Zone, in der ein strukturiertes Vorgehen nicht mehr möglich ist. Selbst hier gibt es aber noch Unterschiede - ein Rest an Sicherheit über mögliche Handlungsoptionen bei gleichzeitiger völliger Uneinigkeit lässt Systeme zerfallen, ein Rest an Übereinstimmungen bei gleichzeitigem Fehlen von Handlungssicherheit ermöglicht zumindest eine letzte gemeinsame Kraftanstrengung, mit dem Ziel dem Chaos irgendwie zu entkommen.

Was bei dieser Betrachtung der ursprünglichen Stacey Matrix klar wird ist das Ausmass der Vereinfachung, das die Umwandlung in die Zimmermann-Variante mit sich gebracht hat. Weder sind im Original Einfach, Kompliziert und Komplex als einheitliche Blöcke zu finden, noch lassen sich methodische Ansätze grossflächig zuordnen. Die agilen Frameworks machen beispielsweise nur unten rechts Sinn, nicht im gesamten mittleren Bereich.

Damit soll nicht gesagt werden, dass die Zimmermann-Variante schlecht ist, aufgrund ihrer Einfachheit und Übersichtlichkeit eignet sie sich gut als Einstieg in eine Beschäftigung mit den Themen Kompliziertheit und Komplexität. Sobald diese Beschäftigung vertieft werden soll ist es aber sinnvoll dazu die Original-Matrix zu nehmen, so wie sie von Ralph D. Stacey erfunden wurde.