Dienstag, 3. Juni 2025
Digitales Working Out Loud als Alternative zum Daily
 |
| 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.
Donnerstag, 16. Februar 2023
User Story Mapping einfach erklärt
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.
Freitag, 11. Februar 2022
A long time ago, in an agility far far away ...
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.
Donnerstag, 27. Januar 2022
Stacey Matrix (III)
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.1
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.2
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.
2Dass diese Position nicht festzustellen ist liegt daran, dass auch sie von verschiedenen Faktoren beeinflusst wird und sich ständig verlagert
Donnerstag, 7. Oktober 2021
Do not automate all the things
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.
Montag, 4. Oktober 2021
Stacey Matrix (II)
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.
Freitag, 6. August 2021
Stacey Matrix
Wenn es irgendwo ein Erklär-Workshop für Agilität gibt kann man Geld darauf wetten, dass sie früher oder später auf einem Flipchart oder einer Präsentationsfolie auftaucht: die Rede ist von der Stacey Matrix, benannt nach dem englischen Wirtschaftswissenschaftler Ralp Douglas Stacey, der sie in den 90er Jahren entwickelte um aufzuzeigen welcher Vorgehens-Ansatz in welchem Umfeld am ehesten Sinn macht. Das ist bis heute ihr Zweck, oft verengt auf die Frage in welchem Umfeld Agilität sinnvoll ist.
Die Variante die dabei am häufigsten gezeigt wird (und die auch weiter oben auf dieser Seite zu sehen ist) trägt ihren Namen allerdings nicht völlig zu Recht. Es handelt sich bei ihr lediglich um eine modifizierte und stark vereinfachte Variation des ursprünglichen Modells, die um das Jahr 2000 von der kanadischen Organisationsforscherin Brenda Zimmermann entwickelt worden ist (und daher eigentlich Zimmermann-Matrix genannt werden müsste).
Dass die Zimmermann-Variante sich durchgesetzt hat und nicht das Original dürfte vermutlich an zwei Gründen liegen. Zum einen ist sie aufgrund ihres reduzierten Inhalts einfacher zu erklären, zum anderen wurde sie durch den Scrum-Miterfinder Ken Schwaber popularisiert, der sie 2004 in seinem Buch Agile Project Management with Scrum abbildete. Da heute fast nur noch diese Ableitung genutzt wird soll es im Folgenden um sie gehen. Wer mehr über das Original wissen will erfährt hier mehr.
Die zwei Achsen der Stacey/Zimmermann-Matrix sind das Was (fachliche Anforderungen) und das Wie (eingesetzte Technologie). Beide sind im unteren linken Bereich der Matrix klar, werden aber nach oben, bzw. nach rechts unklarer. Durch die Kombination der beiden sich verändernden Werte entstehen vier Bereiche: Einfach (links unten, Kompliziert (links-untere Mitte), Komplex (rechts-obere Mitte) und Chaotisch (rechts oben). Ihnen werden empfohlene Vorgehensweisen zugeordnet.
Der einfache Bereich ist der in dem am Ehesten klassisches Management mit Hierarchien, Arbeitsteilung und langfristigen Plänen machbar ist. Die Anzahl der beeinflussenden Faktoren hält sich in Grenzen, Änderungen treten selten auf und sind dann in der Regel vorhersehbar (oder selbst herbeigeführt), die Umsetzung erfordert nur geringe Expertise und kann häufig automatisiert werden. Beispiele wären eine Kartoffelernte oder das Bauen einer Ziegelmauer.
Im komplizierten Bereich ist es schon schwieriger den Überblick zu behalten. Es gibt viele kleinteilige Faktoren die sich auch gegenseitig beeinflussen, durch Standardisierung und optimierte Informationsflüsse kann aber auch hier noch nach Plan gearbeitet werden. Beispielhaft dafür sind der Betrieb einer Fabrikstrasse oder einer Systemgastronomie, empfohlene Vorgehensweisen kommen aus dem Lean Management-Umfeld, etwa Kanban oder SixSigma.
Im komplexen Bereich sind Fachlichkeit und Technik so unklar, dass Detail- und Langfristplanung nicht mehr funktionieren. Die Menge der Faktoren und Inputs und die Anzahl ihrer Abhängigkeiten sorgen dafür, dass das System sich ständig unvorhersehbar verhält, etwa in der Produktentwicklung oder in der Kathastrophenhilfe nach Überflutungen, Grossbränden, etc. Am besten können Inspect & Adapt-getriebene Ansätze damit umgehen, etwa die verschiedenen agilen Frameworks.
Der Chaotische Bereich lässt schliesslich überhaupt kein strukturiertes Arbeiten mehr zu, da eine extreme Kleinteiligkeit und Vernetztheit dafür sorgt, dass es nicht mehr möglich ist alles im Blick zu haben und darauf zu reagieren. Beispiele wären unkontrollierte Kettenreaktionen in Kernkraftwerken oder die Weiterentwicklung sehr grosser, alter und schlecht gewarteter Softwäre-Monolithen. Einzig mögliche Vorgehensweisen sind situatives Firefighting, Triage und (wenn möglich) das Abschalten ganzer Systeme.
Wie alle vereinfachten Informationsvermittlungs-Ansätze hat auch die Zimmermann-Variante der Stacey-Matrix Vor- und Nachteile. Zu den Vorteilen gehört die bereits erwähnte einfache einfache Erklärbarkeit und Verständlichkeit, zu den Nachteilen eine so hohe Abstraktion, dass sie auf Kosten der Anwendbarkeit geht. So ist es etwa auch bei grösstem Bemühen nicht möglich zu sagen ab wann Fachlichkeit und Technik so unklar werden, dass der Gesamtzustand von kompliziert zu komplex wechselt.
Wenn man sich dieser Begrenzungen bewusst ist kann diese Matrix aber ein sehr nützliches Werkzeug sein um im Rahmen von Schulungen und Methodeneinführungen aufzuzeigen, dass kaum eine Vorgehensweise überall anwendbar ist, jede aber in bestimmten Kontexten ihre Stärken haben kann. Alleine diese Erkenntnisse können vielen Organisationen bereits weiterhelfen und das Erreichen weiterer, darauf aufbauender Erkenntnisschritte deutlich erleichtern.
Donnerstag, 12. November 2020
Visualized Continuous Delivery
Schon ein paar Jahre alt, aber noch immer bemerkenswert. In diesen kleinen Kunstwerken stecken genug Details und Informationen um sich erstaunlich lange darin zu vertiefen. Man kann der Urheberin nur dankbar sein, dass sie es der Allgemeinheit zur Verfügung gestellt hat.
Grafiken: Nhan Ngo - CC BY SA 3.0
Donnerstag, 23. Juli 2020
Value, Flow & Bottlenecks (& Visualization)
Montag, 22. Juni 2020
Das Problem mit Jira, Trello, Leankit & Co
 |
| Bild: Pixabay / 12222786 - Lizenz |
Montag, 9. März 2020
(Kein) Powerpoint
Eine Beobachtung die man bei vielen Scrum Mastern und Agile Coaches machen kann ist die, dass sie selten bis nie Powerpoint oder vergleichbare Programme benutzen. Stattdessen wird auf Flipcharts, Whiteboards und Tafeln gemalt und geschrieben, Post Its werden an die Wand geklebt und Karten hochgehalten. Das ist eine derartig zentrale Abweichung von den üblichen Gepflogenheiten des Büroalltags, dass sich ein näherer Blick auf die Ursachen lohnt.
Als wichtige historische Rahmenbedingung ist zunächst die Herkunft der heutigen agilen Frameworks aus der IT zu nennen. Viele Scrum Master haben früher in ihrer Karriere Code geschrieben und sind daher daran gewöhnt, dass Arbeitsergebnisse auch nüchtern, schlicht und schmucklos sein können. Vor allem das für Präsentationen typische "Aufhübschen" ist in diesem Berufsverständnis irrelevant. Entweder etwas macht Sinn oder eben nicht, Ästhetik ist da eher sekundär.
Die zweite "historische Wurzel" ist die starke Abgrenzung der aus den Umsetzungs-Einheiten entstandenen agilen Bewegung zu den sich eher an das Management richtenden klassischen Unternehmensberatungen. Selbst bei den mittlerweile existierenden agilen Beratern wird dieser Unterschied weiterhin kultiviert und äussert sich neben der Ablehnung von beratertypischem Kleidungsstil und Fachjargon auch in der Meidung von Powerpoint als dem klassischen Beraterwerkzeug.
Neben diesen historisch-ideologischen Gründen gibt es aber auch ganz praktische wegen denen digitale Folienschlachten abgelehnt werden. Der offensichtlichste: das meistens groteske Missverhältnis zwischen Erstellungsaufwand und Nutzungsdauer. In grossen Organisationen fliessen oft Stunden oder sogar Tage in übertrieben perfektionistische Präsentationen, die dann nur für Minuten an die Wand geworfen werden. Wer die Steigerung von Effektivität und Effizienz zu seinem Beruf gemacht hat wird das instinktiv verabscheuen.
Ebenfalls ein Ärgernis ist das Verhalten von Meeting-Teilnehmern, das durch Powerpoint getriggert wird. Präsentationen mit vielen Informationen, mit gutem Design oder mit Animationen und eingebetteten Medien (und irgendetwas davon ist fast immer vorhanden) ziehen automatisch die Aufmerksamkeit weg vom Vortragenden und hin zum Bildschirm oder Beamer. Die Folge ist ein Fehlen von Focus und Verständnis, wodurch Termine nachhaltig entwertet werden.
Zuletzt zwingt ein vorbereiteter Foliensatz einem Meeting, bzw. einem Referenten eine starre Agenda auf. Wenn im Rahmen der Durchführung Gesprächsbedarf zu neuen Themen entsteht wird der häufig nicht bedient, da ja keine Folien dafür vorliegen. Und selbst wenn Themenblöcke nur untereinander vertauscht werden wird das Vor- und Zurückspringen (samt des kurzen Auftauchens der dazwischenliegenden Folien) den Ablauf für den Vortragenden hektisch und für die Zuhörer verwirrend machen.
Mit während des Meetings beschrifteten Flipcharts und Whiteboards treten all diese Probleme nicht mehr auf, weshalb sie mit der Zeit zu den bevorzugten Präsentationsmitteln von Scrum Mastern und Agile Coaches geworden sind. Es erfordert zwar gewisse Fertigkeiten in den Bereichen Tafelschrift und Visualisierung, die sind aber erlernbar. Und als unbeabsichtigter Nebeneffekt wirkt das gleichzeitige Miteinander von Vortrag und Visualisierung häufig so beeindruckend, dass es zur Soft Power of Scrum beiträgt.
Donnerstag, 8. Februar 2018
Pinball in Progress
 |
| Bild: Wikimedia Commons / Michael Moore - CC BY-SA 3.0 |
Die Beschreibung dieser Situation erinnerte mich stark an die im Inneren eines Pinball-Automaten. Auch in dem gibt es einen Eingang und einen Ausgang durch die Objekte (in diesem Fall Kugeln) das System betreten und verlassen. Aber: zwischen Ein- und Ausgang gibt es verschiedene blockierende Elemente, von denen die durchlaufenden Objekte abprallen können. Passiert das verändern sie auf unkontrollierbare Weise ihren Kurs und sind nur mit Mühe wieder in die richtige Richtung zu lenken. Genau derartige Bedingungen machten das Modellieren des Systems derartig schwierig. Nun zur Inspiration: könnte man die Analogie dafür nutzen ein Board im Pinball-Stil zu designen? Ein spontaner Erstentwurf sieht so aus:
Wie man sieht: aus der Work in Progress-Spalte wurde die "Pinball in Progress-Spalte", die mit Flippern (unten), schmalem Ausgang (oben) und Abprall-Körpern (rund und dreieckig) wie das Innere eines Pinball-Automaten gestaltet ist. Die Arbeitspakete (Post Its) fliessen durch den "Automaten" durch. So weit, so gut, nur - wozu das Ganze? Aus zwei Gründen. Zum einen wäre das ungewöhnliche Board-Design durch seine Andersartigkeit ein Aufhänger für Gespräche. Ähnlich wie im Fall des Zombie-Cage würde es für Aufmerksamkeit, Konversation und Problembewusstsein sorgen. Zum anderen würde das Kanban-Board gleichzeitig zu einem Impediment-Board. Die Abprallkörper symbolisieren schliesslich nichts anderes als organisatorische Impediments. Und da sie sich by Design bereits im In Progress-Bereich befinden kann gleich an ihrer Behebung gearbeitet werden. Die Anzahl dieser Elemente zeigt damit auch die Störanfälligkeit des Systems an.
Ist noch nicht ganz ausgereift, hat aber Potential. Jetzt muss ich nur noch ein Team überreden so etwas aufzubauen. Konstellationen in denen so etwas Sinn bringen könnte gibt es ja leider zur Genüge.
Montag, 24. Juli 2017
Stakeholder-Landkarten
 |
| Bild: Flickr / Doc Chewbacca - CC BY-NC-SA 2.0 |
Diese (von einem realen Beispiel inspirierte) Stakeholder-Landkarte ist die des Teams "Blue Men Group". Man sieht die Verbindungen zu den Kunden für die man produziert, zu den anderen "blauen" Teams, mit denen man gemeinsame Schnittstellen hat, und zum Management, in dem man besonders eine Person (den "Blue Ambassador") als Fürsprecher hat. Auf der rechten Seite befinden sich weitere Teams mit denen man nicht direkt in Verbindung steht, darunter das Team "Enemies at the Gate", mit dem ein Konflikt besteht (z.B. weil es der Blue Men Group eine andere Architektur aufdrängen will). Damit das nicht passiert achtet eine Abordnung des Managements (die "Border Watch") darauf, dass das Enemies-Team nicht versucht in die Blue Men Group hinenzuregieren.
Auch weitere Faktoren lassen sich darstellen, wie z.B. Abhängigkeiten zwischen anderen Teams, aus denen sich indirekte Betroffenheiten ergeben können. Je nach Phantasie kann die Karte auch zur Visualisierung weiterer Sachverhalte genutzt werden. So könnte die Platzierung des "Blue Islands Team" auf Sardinien und Korsika bedeuten, dass seine Anwendungen aus eigenständigen Microservices bestehen, oder die des "Land's End Team" in Apulien, dass dessen Anwendung in einer technischen Sackgasse steckt.
Aufgehängt werden sollte eine Karte gut sichtbar im Arbeitsbereich des Teams, idealerweise in Sichtweise der Personen die mit den Stakeholdern zusammenarbeiten. Dabei sollte man auch bedenken, dass ausserhalb des Teams stehende Personen die Karte zu Gesicht bekommen können oder sogar sollten (man kann die abgebildeten Personen auch fragen, ob sie sich in der Anordnung genauso sehen würden). Gegebenenfalls macht es daher Sinn die verschiedenen Gruppen neutraler zu benennen als im oben zu sehenden "Enemies at the Gate"-Beispiel.
Donnerstag, 23. Februar 2017
Kanban-Boards (box hide answer)
 |
| Bild: Flickr / Dennis Hamilton - CC BY 2.0 |
Ich werde am 23.02. von einigen Consultants durchoptimiert. Die haben eine "tolle neue" Erfindung. Projektplanung und -übersicht mit Hilfe einer Tafel und Klebestickern, statt Excel-Tabellen oder MS Project. Man fasst es nicht, wofür wir Geld ausgeben...Ich habe ihm mitgeteilt, dass diese "tollen neuen Methoden" auch zu meinem Berufsalltag gehören - bei unserer nächsten Begegnung sehe ich schon ein längeres Gespräch auf mich zukommen. In gewisser Weise in Vorbereitung darauf: warum machen wir das eigentlich, warum benutzen wir nach Möglichkeit Kanban-Boards statt Computerprogrammen?
Die Antwort darauf ist im Grunde nichts anderes als das "big Picture". Die Darstellung großer Wertströme durch verschiedene Phasen könnte man zwar auch digital umsetzen, es wäre dann aber kein Bildschirm groß genug um das alles so wiederzugeben, dass es auf einen Blick sichtbar ist. Jeder der schon einmal Excel, Jira, Redmine, Trello oder ein ähnliches Tool auf seinem Rechner gesehen hat kennt das Phänomen: immer ist irgendetwas ausserhalb des sichtbaren Bereichs. Erst durch ständiges Scrollen wird es sichtbar, wodurch sich aber andere Elemente aus dem Schirm herausbewegen. Es gibt sogar Abschnitte an denen man nur selten bis gar nicht vorbeikommt, und was dort hängt wirde gerne vergessen. Was noch dazu kommt: wenn der Rechner aus ist oder ein anderes Fenster geöffnet ist sieht man gar nichts mehr. Aus den Augen, aus dem Sinn, oder mit den Worten eines Toyota-Managers: "When you put problem in computer, box hide answer. Problem must be visible!"
Beispiele für große Boards habe ich auf meinen Projekten schon einige gehabt, und sie sind bis zu sechs Meter breit und bis zu zwei Meter hoch gewesen. Wie hätte man darauf navigieren wollen, wenn sich das irgendwo in digitaler Form befunden hätte? Wie oft hätten Aufgaben oder Probleme (zeitweise) in Vergessenheit geraten können wenn wir sie nicht permanent vor Augen gehabt hätten? Und wie wäre es uns gelungen Managern und Stakeholdern eine "schnelle Übersicht" zu geben, wenn wir dafür ewig hätten hin- und herscrollen müssen? Boards und Post Its sind zwar weder neu noch innovativ, für den Blick auf das Große Ganze aber unverzichtbar.
Donnerstag, 14. April 2016
Steuerung langfristiger Vorhaben mit Kanban-Boards
 |
| Bild: Unsplah / Sebastien Bonneval - Lizenz |
In diesem Vorgehensmodell wird der To do/In Progress/Done-Ablauf in mehreren Phasen wiederholt, wobei diese von links nach rechts immer kürzer werden. Die langfristige Vorarbeit könnte zum Beispiel die bereits im Vorjahr stattfindende Budgetplanung sein, die "kurz"fristige Vorarbeit wäre die im Vorquartal stattfindende Kommunikations- oder Schulungsphase, die Umsetzung wäre dann die eigentliche Arbeit, etwa das Rollout einer neuen Software oder das Rebranding einer Dienstleistung. Abhängig davon wie komplex und unberechenbar dieser Abschnitt ist könnte man in ihm sogar tatsächlich Scrum einsetzen, wobei es in diesem Fall sinnvoll wäre ihn auf einem zweiten Board mit höherem Detaillierungsgrad zu spiegeln. Als letztes ließe sich sogar ein Lessons Learned-Prozess mit abbilden, dessen Ergebnisse dann wieder auf der linken Seite ins Backlog einfließen könnten.
Natürlich ist dieser Entwurf zunächst nur einer auf relativ hohem Abstraktionslevel. Einige Aspekte fehlen noch und müssten ausgearbeitet werden, etwa die Visualisierung der Zuordnung von Aufgaben zu Personen oder Teams, oder auch die Kennzeichnung von Aufgaben die zu bestimmten Zeitpunkten erledigt sein müssen. Er ist auch nicht universell anwendbar, in manchen Fällen werden andere Vorgehensweisen mehr Sinn machen, beispielsweise die Benutzung von Story Maps oder anders konfigurierten Boards. In vielen Fällen wäre er aber ein erheblicher Beitrag zu mehr Transparenz und Übersicht - und mit Sicherheit wesentlich besser benutzbar als die immer noch weit verbreiteten Excel- oder MS Project-Monstrositäten.
Donnerstag, 7. April 2016
Wohin mit dem Kanban Board?
Ein Klassiker unter den Ausreden "warum Agil bei uns nicht geht": Es dürfen keine Post-Its an den Wänden angebracht werden, weil der Putz/die Tapeten so empfindlich sind.1 Vor kurzem erst habe ich mir das von einer jungen Projektmanagerin anhören dürfen, der ich gleich eine Wette angeboten habe - alleine in ihrem Lieblings-Social Media-Service (Instagram) würde ich genug Beispiele dafür finden, wie man diese Beschränkung umgehen kann. Hier sind einige Ergebnisse:Auf ein Fenster
Auf Stellwände
Auf einen Schrank
Auf ein Whiteboard
Auf einen Spiegel
Auf ein Flipchart
Auf eine Korkwand
Auf einen Kalender
Auf den Schreibtisch
Auf ein mitnehmbares laminiertes Blatt
Übrigens: der Dame sind dann sofort ganz viele andere Gründe eingefallen warum Scrum dort nicht funktioniert. Wer nicht will, der will nicht.
1Nur zur Klarstellung: natürlich geht Agilität auch ganz ohne physisches Board, es gibt aber gute Gründe eines zu haben.
