Samstag, 31. Dezember 2022

Kommentierte Links (XCVI)

Bild: Unsplash / Fabio Bracht - Lizenz
Normalerweise sammele ich in den kommentierten Links die jeweils interessantesten oder amüsantesten Artikel die ich im letzten Monat gelesen habe. Von Zeit zu Zeit kommt es aber vor, dass ich einen vorübergehend vergesse oder ihn erst entdecke Monate nachdem er erschienen ist. Hier sind die besten dieser "verpassten" aber trotzdem lesenswerten Texte aus dem letzten Jahr.

Christopher Berry: What Is A Garbage Can Product Roadmap?

Zu den provokantesten Beschreibungen der Abläufe in Grossunternehmen gehört das Garbage Can Model von Cohen, March und Olsen, das davon ausgeht, dass alle Untereinheiten ununterbrochen und unabgestimmt Probleme und Lösungsansätze produzieren, die sie irgendwann unabgestimmt wieder aufgeben um sich neuen Themen zuzuwenden. Als Folge entstehen überall "Müllhaufen" von Problemen, potentiellen Lösungen und Entscheidungsbedarfen. Verstörenderweise beschreibt dieses Modell die Realität in vielen Unternehmen sehr gut. Christoper Berry versucht sich darauf aufbauend an einer weiterführenden Frage: wir kann in einer solchen Umgebung Planung stattfinden, und wie liessen sich derartige Planungen in einer Roadmap abbilden? Das Ergebnis ist eines das sich gut auf das Produktmanagement in (mehr oder weniger) agil arbeitenden Grossorganisationen übertragen lässt.

Aakash Gupta: The History of Product Management

Um es vorwegzunehmen - die Geschichte des Produktmanagements ist relativ kurz. Genau das ist auch der Ausgangspunkt von Aakash Guptas Überlegungen: seit wann gibt es dieses Tätigkeitsfeld überhaupt, und durch welche Entwicklungsstufen ist es gegangen um dort anzukommen wo es heute ist? Von den Anfängen bei Procter & Gamble und bei Hewlett Packard in den 30er und 40er Jahren bis hin zu den Produktmanagement-Ausbildungen der Gegenwart zeigt er auf, wie es nach und nach dazu gekommen ist, dass aus vorher über die ganze Organisation verteilten Verantwortlichkeiten der heutige Beruf geworden ist. Dabei macht er auch die Rolle deutlich, die die agilen Frameworks dabei gespielt haben, inbesondere Scrum, dessen Product Owner-Rolle eine der ersten gewesen ist, die das Wort Produkt bewusst als Namensbestandteil und Haupt-Tätigkeitsfeld hatte.

Johannes Klingebiel: The five Levels of Hype

Sowohl in der IT als auch in der agilen Community sind Hypes durchaus verbreitet, sei es in Form der neuesten Programmiersprache, des neuesten Methoden-Frameworks oder sonstiger Moden. Bei genauerer Betrachtung wird der Begriff des Hype aber eher undifferenziert gebraucht, oft mit der ungefähren (und uneingestandenen) Bedeutung "etwas Neues, das ich nicht mag". Johannes Klingebiel versucht Struktur in das Ganze zu bringen, indem er fünf Stufen definiert, über die sich Hypes immer stärker von der Realität entkoppeln können: Werbe-Botschaften, überzogene Erwartungen, utopische Verheissungen, magisches Denken und Sektenhaftigkeit (hier als handliches Übersichts-PDF herunterladbar). Legt man diese Skala neben die verbreiteten Entwickler- und Agile-Hypes lässt sich zum Glück feststellen, dass die sich alle noch auf den unteren Stufen befinden.

Luca Minudel, Michael Kelley Harris: Transcending the CapEx – OpEx dichotomy

Dass Anwendungsentwicklung und Anwendungsbetrieb unterschiedliche Aufgaben sind, die unterschiedliche Tätigkeiten erfordern, dürfte jedem klar sein, der schon einmal im IT-Umfeld gearbeitet hat. Weniger bekannt ist, dass in vielen Firmen diese Aufgaben auch unterschiedliche Budget-Posten haben: CapEx (Capital Expenditure) für Anwendungsentwicklung und OpEx (Operating Expenses) für den Betrieb. Dass diese Trennung in Zeiten von DevOps und kontinuierlicher Weiterentwicklung nicht mehr sinnvoll ist belegen Luca Minudel und Michael Kelley Harris anhand von nachvollziehbaren Beispielen (um ein banales zu nennen: ein Bugfix der die Funktionalität verändert). Sich mit den von ihnen gemachten Gedanken zu beschäftigen kann man jedem der in grossen Organisationen agil arbeiten will nur empfehlen, wenn er nicht riskieren will, dass er irgendwann sinnvolle oder notwendige Dinge wegen aufgebrauchten Einzelbudgets nicht mehr machen darf.

Bryan Finster: Scaled Agile DevOps Maturity Framework

Wenn ich es richtig überblicke ist das hier ein Aprilscherz gewesen, und zwar ein durchaus gelungener. Viele Scrum Master und Agile Coaches denen ich Bryan Finsters Scaled Agile DevOps Maturity Framework (abgekürzt SAD MF) vorgestellt habe waren sich zuerst unsicher - ist das hier ernst gemeint oder ist das ein Witz? Dass es überhaupt zu derartigen Unsicherheiten kommen kann zeigt deutlich auf, wie nahe an der Selbst-Persiflage die bekannten agilen Skalierungsframeworks (v.a. SAFe) mit ihrem Slang-Begriffen, ihren Erfolgsversprechen und ihren kaum getarnten Wasserfall- und Command & Control-Elementen mittlerweile sind. Für alle denen die so verpackte Kritik noch nicht beissend genug ist gibt es nebenbei noch einen Seitenhieb auf den Agil-Industriellen Komplex: wem es nicht ausreicht zertifizierter SAD Practitioner oder SAD Fellow zu werden, der kann selbst in den Zertifizierungsverkauf einsteigen - als Scaled Agile Dev Ops Accredited Facilitator, oder SAD AF.1

Beyang Liu: A dev's thoughts on developer productivity

Wenn es um die Bedingungen geht in denen Software-Entwickler produktiv arbeiten können wird in vielen Firmen über die Entwickler gesprochen, selten mit ihnen und fast nie geht die Unterhaltung von ihnen aus. Beyang Liu versucht dagegenzuhalten indem er aus seiner Perspektive (er ist Software-Entwickler) zusammenfasst was ihn produktiv macht und was nicht. Zu den Themen die er dabei behandelt gehören die Einbettung seines persönlichen Arbeitsrhythmus in die Iterations-Zyklen, unterbrechungsfreie Konzentrationsphasen, Kontextwechsel und Klarheit über Standards und Ziele. Darüber hinaus zeigt er auf, dass Team-Produktivität mehr ist als die Summe der Produktivität aller Entwickler, da diese sich ergänzen und unterstützen können. Zuletzt äussert er eine Erkenntnis die man sich auch bei manchem anderen wünschen würde: wenn die Entwickler nicht selbst ihre Produktivität thematisieren wird es jemand anders tun - oft indem er über sie redet statt mit ihnen.

Oleg Mykolaichenko: Engineering Management During Wartime

IT-Anwendungen auf eine Produktions-Umgebung zu bringen und dort zu betreiben ist in westlichen Ländern vor allem eine Frage funktionierender Software und funktionierender Prozesse. Dass auch ganz andere, extreme Herausforderungen dazukommen können zeigt diese Zusammenfassung eines Vortrags von Oleg Mykolaichenko auf den unkrainischen DevOps Day 2022. Business Continuity Planning, Incident Management und Disaster Recovery bekamen in seiner Firma eine ganz andere Bedeutung als sie plötzlich in einem Krieg stattfinden mussten, durchgeführt von Menschen in der von Russland angegriffenen Stadt Kiew. Zu den verstörendsten Elementen gehören Bots die regelmässig überprüfen ob die Mitarbeiter am Leben und unverletzt sind und Vorkehrungen die explizit darauf ausgerichtet sind nicht nur den Ausfall von Infrastrukturen sondern auch den Tod von Managern zu kompensieren. Eine sowohl faszinierende als auch beängstigende Fallstudie.

Charity Majors: The Hierarchy Is Bullshit (And Bad For Business)

Charity Majors hat es richtig erkannt: die eigentliche Funktion von Hierarchien ist es, Informationsflüsse und Zusammenhänge vereinfacht darzustellen, um dadurch in der Lage zu sein grosse Vorhaben zu planen und umzusetzen. Sobald hierarchische Positionen aber mit mehr Gehalt, mehr Prestige oder anderen Belohnungen aufgeladen werden, wird es dazu kommen, dass sie aus den falschen Gründen angestrebt werden. Ihr Artikel ist eine bemerkenswerte Mischung aus Analyse, Rant und Inspiration zum besser machen, letzteres mit der interessanten Idee von "formal power as a service function", einer neuen Dimension von Servant Leadership.


1Für alle die gerade rätseln: hinter Sad MF und Sad AF verbergen sich in der US-amerikanischen Umgangssprache wüste Beschimpfungen

Donnerstag, 29. Dezember 2022

Kommentierte Links (XCV)

Bild: Pixabay / Buffik - Lizenz
Das Internet ist voll von Menschen die interessante, tiefgründige oder aus anderen Gründen lesenswerte Artikel schreiben. Viele dieser Texte landen bei mir, wo sie als „Food for Thought“ dazu beitragen, dass auch mir die Themen nicht ausgehen. Wie am Ende jedes Monats gibt es auch diesesmal wieder eine kommentierte Übersicht über die erwähnenswertesten.

Charles Lambdin: Industrial Revolution Org Cultures

Wenn man komplexe Zusammenhänge verstehen will kann es eine gute Idee sein, sich mit ihrem Entstehungskontext zu beschäftigen. Charles Lambdin geht dafür weit in die Vergangenheit zurück, bis zur Gesellschaft der New York and Erie Railroad, die im Jahr 1854 das erste Unternehmens-Organigramm aller Zeiten erstellte - für viele der Startschuss des modernen Managements. Aufbauend darauf zeichnet er eine zweite, eher unbekannte Entwicklungslinie der Management-Lehre auf, die nach und nach von der heute dominierenden, auf das Management von Menschen fokussierten Variante abzweigte und stattdessen einen Schwerpunks auf das Management systemischer Faktoren legte. Als bekannte Vertreter nennt Lambdin u.a. William Edwards Deming, Edward Martin Baker, Peter Scholtes und Johanna Rothman, deren Werke zur vertieften Beschäftigung mit dem Thema sehr zu empfehlen sind. Sie zeigen, dass Management deutlich mehr sein kann als das was in den meisten grossen Organisationen zu beobachten ist.

Matthew Ström: The micromanager's dilemma

Um beim Thema Management zu bleiben - dass niemand Micro-Management mag, dieses Vorgehen aber trotzdem weit verbreitet ist, ist ein Rätsel dem Matthew Ström auf den Grund zu gehen versucht. Sein Ansatz: die Analyse von micromanagendem Vorgehen anhand des Gefangenen-Dilemmas. Die Erkenntnis die er daraus zieht ist die, dass kein Manager sich sicher sein kann, dass ein Teil seiner Untergebenen die Delegation von Verantwortung nicht ausnutzen würde. Da die dadurch entstehenden Nachteile schnell die dadurch entstehenden Vorteile aufwiegen würden ist Micromanagement nicht nur eine naheliegendes sondern (scheinbar) sogar ein wirtschaftlich sinnvolles Vorgehen. Ström nennt verschiedene Ansätze mit denen man sich aus diesem Denkgebäude befreien kann, lässt aber meiner Meinung nach den effektivsten aus - die Delegation von Ergebnisverantwortung in stabile, selbstorganisierte Teams, deren Mitglieder dann untereinander dafür sorgen können, dass sich keiner auf Kosten der anderen zurückhält.

Dorian Taylor: Agile as Trauma

Wer schon einmal miterlebt hat, in welchem Ausmass Mitglieder der Umsetzungsebene die Einführung von agilen Arbeitsweisen als Befreiung empfinden können, wird Dorian Taylor zustimmen - zumindest in der Anfangsphase kann es einer der Haupteffekte sein, die Traumatisierung durch schlechte Management-Praktiken (Micromanagement, Herrschaftswissen, Schuldzuweisungen, etc.) zu heilen. Problematisch wird es aber, wenn diese Trauma-Bewältigungs-Funktion des agilen Arbeitens zu einem Selbstzweck wird und dazu führt, dass Agilität negativ definiert wird (d.h. als Abwesenheit von Wasserfall-Prozessen oder Hierarchien). In einem solchen Kontext werden Elemente an denen auch in einem agilen Modus aktiv gearbeitet werden muss vernachlässigt werden, zum Beispiel Unternehmensführung, Software-Architektur und Produktstrategie. Findet eine solche Vernachlässigung statt, kann der (scheinbar) agile Arbeitsmodus selbst anfangen traumatisierend auf die von ihm Betroffenen zu wirken.

Michael Bolton: Talking About Coverage

Wenn es um die eher technische Seite der Agilität geht wird mit grosser Wahrscheinlichkeit früher oder später die Testabdeckung als entscheidender Faktor genannt werden, also die Metrik aus der sich ablesen lässt zu wieviel Prozent des Code durch automatisiert ausgeführte Tests abgesichert ist. Warum diese Zahl wichtig ist, ist einfach zu erklären: versehentliche Seitenauswirkungen von Featureentwicklungen werden sofort erkannt, die dauerhafte Funktionsfähigkeit einer Anwendung wird regelmässig überprüft, bestenfalls sind die Tests sogar eine einfach zu verstehende Dokumentation der Software. Weit weniger klar ist häufig, was durch diese Tests eigentlich abgesichert wird. Michael Bolton verhilft hier zu mehr Klarheit indem er aufschlüsselt was mögliche Definitionen von Testabdeckung sind, wofür sie gut ist (und wofür nicht) und wann man welche Variante anwenden kann. Eine einfache Erklärung hat man zwar auch nach dem Lesen seines Textes nicht, man hat den Sachverhalt aber deutlich besser verstanden.

Jason Yip: All my thoughts on program management

Ob Agilität auch in Vorhaben möglich ist die so gross sind, dass sie organisatorisch nur noch als Programm (übergreifende Struktur über mehreren Projekten oder Produktlinien) abgebildet werden können, lässt sich ausgiebig diskutieren. Lässt man diese Überlegungen beiseite bleibt aber zumindest die Frage, wie man zumindest so viel Agilität wie möglich erreichen kann. Jason Yip trägt einige gute Ideen dazu zusammen, wie oft in seinen Artikeln angereichert durch hilfreiche Visualisierungen. Empfehlenswert für jeden der in einem skalierten Umfeld unterwegs ist.

Montag, 26. Dezember 2022

Wie der Staat wieder handlungsfähig wird

Bild: Pixabay / Borevina - Lizenz

Wenn es etwas gibt, das als Inbegriff von fehlender Agilität gilt, dann ist es die staatliche Verwaltung. Warum diese Betrachtung etwas zu einseitig ist habe ich bereits an anderer Stelle aufgeschrieben, im Grossen und Ganzen ist es aber leider so, dass Schwerfälligkeit und Langsamkeit in vielen Behörden vorherrschen. Umso interessanter ist ein aktueller Fall, der zeigt, dass auch dort wo bisher die Bürokratie dominierte erstaunliche Verbesserungen möglich sind.


Die Rede ist von dem Bau des Flüssiggas-Terminals in Wilhelmshaven, dessen beschleunigte Genehmigung und Erstellung in einem Artikel der Zeit beschrieben wird. Das Ausmass dieser Beschleunigung wird bereits durch das Nebeneinanderhalten der Zeiträume deutlich: normalerweise wird bei Vorhaben dieser Art von acht Jahren (!) ausgegangen, in diesem Fall waren dagegen für die gesamte Zeit von Beschlussfassung bis Inbetriebnahme nur 10 Monate nötig.


Der grösste Zeitgewinn ist dabei offensichtlich in der Genehmigungsphase erzielt worden, alleine die scheint im Normalfall bis zu sechs Jahre (!) zu dauern. Die bemerkenswert einfache Lösung: einmal pro Woche hat ein gemeinsamer Call aller an der Genehmigung beteiligten Behörden stattgefunden, in dem geklärt wurde wer als nächstes was an wen zuzuliefern hat. Diese direkte Abstimmung hat schnell Ergebnisse geliefert, für die es sonst einen wochenlangen Schriftverkehr gebraucht hätte.


Dass diese Runden stattfinden konnten und arbeitfähig waren wurde durch eine weitere bemerkenswert einfache Massnahme möglich: realistische Personalplanung. Statt unterbesetzte Dienststellen mit Arbeit zu überhäufen und darauf zu hoffen, dass es irgendwie gut geht wurde darauf geachtet, dass ausreichende Arbeitskapazitäten verfügbar gemacht wurden um die anstehenden Aufgaben zu erledigen. Ein für Grossorganisationen keineswegs selbstverständliches Vorgehen.


Etwas komplizierter war der Umgang mit anderen Ressourcen: den Baustoffen (vor allem Stahl). Statt den klassischen Weg zu gehen, zuerst einen Plan zu erstellen und dann nach den in ihm vorgesehenen Baustoffen zu suchen (die in diesem Moment ggf. nicht verfügbar wären), wurden nach einer ersten Grobschätzung zuerst die Baustoffe gekauft um dann erst basierend auf deren Verfügbarkeit die Baupläne zu erstellen. So konnten die Bauarbeiten direkt beginnen.


Eine zusätzliche Beschleunigungsmassnahme war die Aufhebung der strikten Sequenzialität aller Vorgänge. Dort wo die Erteilung von Genehmigungen absehbar war wurde bereits mit der Umsetzung begonnen, die offiziellen Freigaben wurden nachgeliefert wenn sie fertig waren. Verbunden war das allerdings mit der Vorgabe im eventuellen Fall einer doch verwehrten Genehmigung alles bis dahin Gebaute wieder rückgängig zu machen.


Die Bereitschaft sich darauf einzulassen war auch Teil von etwas Grösserem: der Einsicht, dass sich nicht alles vorhersagen und planen lässt, und dass es deswegen zu Kostensteigerungen kommen kann die dann zu tragen sind. Diese Einsicht steht in deutlichem Gegensatz zur in Grossvorhaben üblichen Praxis Kostensteigerungen mit Sparmassnahmen an anderen Stellen kompensieren zu wollen, die meistens zu schlechteren (und langfristig sogar teureren) Ergebnissen führen.


Zuletzt kamen noch kleinere Massnahmen dazu, etwa verkürzte Fristen für die öffentliche Auslegung der Pläne. In Kombination haben alle diese Massnahmen dazu geführt, dass ein Grossprojekt in nur einem Zehntel der Zeit umgesetzt werden konnte die sonst für vergleichbare Vorhaben notwendig ist. Das Beispiel des Flüssiggas-Terminals in Wilhelmshaven zeigt, dass auch staatliche Grossprojekte schnell und unbürokratisch realisiert werden können, wenn es denn gewollt ist.


Die Frage die bleibt - wenn das einmal möglich war, warum nicht öfter so?

Donnerstag, 22. Dezember 2022

Jahresziele

Bild: Unsplash / Glenn Carstens-Peters - Lizenz

Irgendwann in jedem Winter stehen sie an: die Ziele für das nächste Jahr. Zwar sehen viele Agilisten sie als kontraproduktiv oder schädlich an, als zu langfristig und zu unflexibel, zu sehr auf Einzelleistungen von Personen und zu wenig auf Ergebnisse ausgerichtet - aber in den meisten Unternehmen sind sie nun mal da und können nicht wegdiskutiert werden. Es stellt sich daher die Frage, wie man zumindest das Beste aus ihnen machen kann.


Um mit dem Einfachsten zu beginnen: man kann zunächst aus Personenzielen Teamziele machen. Natürlich wird jetzt der eine oder andere nach Atem schnappen, denn die Verzielungs-Strukturen eines Unternehmens anzupassen ist alles mögliche, nur nicht einfach. Es gibt aber einen simplen und effektiven Umgehungsmechanismus: alle Mitglieder eines Teams erhalten zwar ein eigenes Ziel, dieses ist aber bei allen identisch (und bestenfalls nur gemeinsam erreichbar).


Als nächsten Schritt kann man damit beginnen die Ziele Ergebnis- statt Liefer-orientiert zu formulieren. Also weg von "System X wird bis Dezember mit allen spezifizierten Features auf Produktion released" und hin zu "bis Dezember können wir Kundenbedürfnis Y befriedigen". Das löst die Koppelung an (möglicherweise gar nicht optimale) vordefinierte Lösungen und ermöglichst eine Refocussierung auf die Frage welches Problem eigentlich gelöst werden soll.


Als Drittes kann man einplanen während des Jahres die Arbeit am Ziel zu überprüfen und anzupassen. Der ursprünglich gewählte Lösungsansatz erweist sich als nicht so gut wie gedacht? Kein Problem, dann nimmt man eben einen anderen. Da das Ziel nur das zu lösende Problem vorgibt und nicht den Lösungsweg kann es unverändert bestehenbleiben, selbst dann wenn das gesamte Vorgehen verändert wird. Dem Planen von z.B. monatlichen Inspect & Adapt-Terminen steht nichts im Weg.


Zuletzt kann eine solche Art der Zielsetzung als ein Hebel für mehr Crossfunktionaität und Empowerment genutzt werden. Den Kunden soll auch ausserhalb der Arbeitszeiten bei Bedienungsproblemen geholfen werden? Dann muss es z.B. möglich sein durch Marktforschung herauszufinden womit er besser klarkommt, mit einem Chatbot oder mit einem Anleitungsvideo. Schliesslich machen es nur so gewonnene Erkenntnisse möglich das Ziel zu erreichen.


Natürlich heisst das nicht, dass man sich in einem solchen Vorgehen dauerhaft mit der Existenz von Jahreszielen abfinden muss, dafür sind ihre potentiellen Dysfunktionen zu gross. Man kann aber zumindest zeitweise einen Arbeitsmodus finden in dem sie agiles Arbeiten nicht mehr grundsätzlich behindern, und von dem ausgehend man versuchen kann sie durch andere, zielführendere Vorgehensmodelle zu ersetzen.

Montag, 19. Dezember 2022

The agile Bookshelf: Pirates in the Navy

Bild: Wikimedia Commons / J. A. Hampton - Public Domain

Steve Jobs wird das Zitat zugeschrieben, er habe lieber Pirat werden wollen als in die Marine zu gehen, womit er ausdrücken wollte, dass er seinen sein Unterternehmergeist nicht durch zu viele Regeln eingeschränkt sehen wollte. Der Innovationsberater Tendayi Viki hat sich diese Analogie für den Titel seines Buches Pirates in the Navy ausgeliehen, allerdings mit einer zusätzlichen Drehung: er fragt sich was die Faktoren sind, die es einem Piraten möglich machen würden Teil der Marine zu sein.


Was er damit aussagen will: immer wieder versuchen Grossunternehmen (die Marine), unternehmerische Freigeister (Piraten) bei sich anzustellen - nur um sie dann mit Vorschriften, Budgetzwängen und Regeln so einzuengen, dass sie den Zweck zu dem sie geholt wurden nicht mehr erfüllen können. Das was in solchen Konstellationen entsteht ist für Viki "Innovationstheater". Einheiten die auf den ersten Blick innovativ und unternehmerisch aussehen, in Wahrheit aber wirkungslos sind.


Um zu erklären warum das so ist geht er auf verschiedene Trugschlüsse ein, die den (ja gut gemeinten) Konstellationen zugrundeliegen, die aus Innovations-Einheiten Theatergruppen machen. Ein offensichtlicher ist die überzogene Erwartung an Methoden wie Lean Startup, von denen oft geglaubt wird, dass Ihr Einsatz auch im bürokratischen Umfeld ein Erfolgsgarant wäre, aber auch weitere sind dabei, etwa die, dass grosse Visionen wichtiger sind als wirtschaftliches Handwerkszeug.


Was er stattdessen empfiehlt ist eine regelmässige Rückbesinnung darauf, welchen Zweck Innovation in einem Unternehmen erfüllen sollte: im Rahmen einer übergreifenden Strategie neue Geschäftsfelder erschliessen (oder bestehende stärken) um dadurch zum wirtschaftlichen Erfolg beizutragen. Findet das nicht statt werden Innovationsbemühungen für Viki schnell zu einem keinen Mehrwert stiftenden Selbstzweck, der früher oder später zurecht beendet werden wird.


Um alles in die richtige Richtung zu lenken enthält das Buch nicht nur verschiedene Ratschläge und Werkzeuge sondern auch erhellende Einordnungen. Unter anderem geht es darauf ein, warum das mittlere Management häufig ein (scheinbar) innovationsfeindliches Verhalten an den Tag legt, warum dieses rational und sogar sinnvoll ist und was man tun kann um mit ihm zusammenarbeiten statt ständig Konflikte mit ihm auszutragen.


In einer Literatur- und Forschungslage die sich in grossen Teilen entweder auf kleine Teams konzentriert oder schwergewichtige Skalierungsansätze für grosse Konzerne entwirft schliesst Tendayi Vikis Buch eine wichtige Lücke. Jedem der mit dem Aufbau von beweglichen Innovations-Einheiten in grossen Organisationen beauftragt ist, ist es sehr zu empfehlen. Und selbst die, die nur wenig Zeit haben können sich freuen - Pirates in the Navy umfasst gerade mal schlanke 100 Seiten. Das passt auf jeden Fall noch in die Leseliste des nächsten Urlaubs.

Donnerstag, 15. Dezember 2022

Doch wie Spotify werden (II)

Bild: Flickr / Rasmus Anderson - CC BY-NC 2.0

Reden wir noch einmal über das berühmt-berüchtigte Spotify Model, jenen Erfahrungsbericht, der ohne dass es von seinem Verfasser jemals geplant war zu einer Blaupause für zahllose agile Transitions- und Skalierungsvorhaben geworden ist. Dass diese Verwendung nicht im Sinne des Erfinders ist und besser unterlassen werden sollte ist ein immer wieder vorgebrachtes Mantra vieler überzeugter Agilisten. Ein bekannter Name sieht das allerdings anders - der Erfinder selbst, Henrik Kniberg.


Wird Kniberg zu "seinem" Framework befragt (z.B. hier) äussert er sich in der Regel undogmatisch und realistisch. Er sagt, dass in seiner Wahrnehmung die überwiegende Mehrzahl der Umsetzungen weder zu Verbesserungen noch zu Verschlechterungen führt, dass es eine kleine Menge gibt bei der es zu signifikanten Verbesserungen kommt, aber fast keine Beispiele dafür, dass Verschlechterungen die Folge sind. Und diese Beobachtung ist bemerkenswert genug für einige Überlegungen.


Dass die Mehrzahl der Umsetzungen alles beim Alten lässt liegt an einem schlichten Grund: das Spotify Model wird von Beratungen vor allem an Konzerne verkauft, und die sind in der Regel als Matrix-Organisation aufgestellt. Auch das Spotify Model ist eine solche Matrix-Organisation, so dass seine Einführung oft nur eine Umbenennung ist - aus Abteilungen werden Chapter, aus Projekten Squads oder Tribes. So wird zwar nichts besser, aber eben auch nichts schlechter.


Zu Verbesserungen kommt es dort wo die über den blossen Organisationsaufbau hinausgehenden Vorteile des Spotify Models erkannt und umgesetzt werden (mehr dazu hier). Die Ähnlichkeit zur klassischen Matrix-Organisation kann dabei sogar ein Vorteil sein, da der Umbruch weniger hart erscheint und die Sorgen und Widerstände dementsprechend geringer ausfallen. Die Veränderungen erfolgen in solchen Fällen eher evolutionär, was sie aber nicht weniger wirksam macht.


Wirklich interessant ist aber, dass es kaum Fälle gibt in denen eine Umstellung auf das Spotify Model zu einer Verschlechterung des Gesamtzustandes führt (was ich aufgrund der Erfahrungen die ich in über 10 Jahren bei vielen Kunden und auf zahllosen Meetups gemacht habe nur bestätigen kann). Gerade vor dem Hintergrund, dass erschütternd viele Veränderungsvorhaben nur Verschlimmbesserungen hervorbringen, sollte das nicht geringgeschätzt werden.


Näher betrachtet ist ein Grund dafür, dass es nicht nötig ist die alte, funktionierende Struktur zu zerstören um die neue Zielstruktur errichten zu können. Die Ähnlichkeit zur alten Matrix-Organisation ermöglicht schrittweises Ausrollen, eine beliebig lange Koexistenz von alter und neuer Welt und im Extremfall sogar ein relativ schmerzloses rückgängig Machen. Ein riskanter "methodischer Big Bang Release" wird dadurch unnötig, ein dezentrales und asynchrones Change Management wird einfacher.


Ein zweiter Grund ist die einzigartige Benennung der Organisationseinheiten, die verhindert, dass aus anderen Kontexten bereits mit Bedeutungen belegte Begriffe umgedeutet werden müssen. Weder bedeuten alte Namen wie Abteilung oder Projekt plötzlich etwas anderes, noch müssen "agile Fachbegriffe" für Konzern-Erfordernisse verbogen und verfremdet werden, wie es z.B. mit der Scrum-Terminologie in SAFe passiert. Mehrdeutigkeit und Missverständnisse werden so unwahrscheinlicher.


Zusammengenommen tragen diese Faktoren zu Knibergs Beobachtungen bei, dass das Spotify Model meistens wenig verändert, immerhin manchmal die Zustände verbessert und sie dafür nur sehr selten verschlechtert. Zwar bedeutet das, dass man mit ihm keinen "Grossen Sprung nach vorne" durchführen kann, das Risiko, dass es zu Widerständen kommt und die Wahrscheinlichkeit von versehentlichen Verschlimmbesserungen sind dafür aber gering.


Dem Spotify Model eine Chance zu geben kann daher eine gute Idee sein, und sei es nur als ein Zwischenschritt auf der Veränderungsreise. Es in Bausch und Bogen zu verdammen mag sich dagegen gut anfühlen, wirklich hilfreich ist es aber eher selten.

Montag, 12. Dezember 2022

40 Agile Methods in 40 Minutes

Dass es mehr agile Frameworks gibt als Scrum, SAFe und Kanban dürfte den meisten die sich mit diesem Thema beschäftigt haben klar sein, wie viele es sind ist aber doch immer wieder überraschend. Da es insgesamt zu viele sind um sie in einem einzigen Beitrag ausführlich zu behandeln wählt Craig Smith in diesem Vortrag das einzige passende Format: Stakkato. 40 Frameworks und Methoden in nur 40 Minuten.

 

 

Obwohl dieses Video nur sieben Jahre alt ist merkt man an ihm übrigens wie sehr sich die agile Methodenwelt in der jüngeren Vergangenheit geändert hat. SAFe ist nur eines unter vielen Skalierungsframeworks, Disciplined Agile ist noch eigenständig, Modern Agile und andere "neuere" Frameworks sind noch unbekannt (oder noch nicht erfunden). Dafür werden andere aufgeführt, die (zurecht?) völlig in Vergessenheit geraten sind, wie z.B. Nonban und ScrumPLOP oder Mikado. Times are a-changin'.

Donnerstag, 8. Dezember 2022

Organisierte Agilität

Bild: Pexels / Ketut Subiyanto - Lizenz

Wer bestimmt eigentlich was die Bedeutung und Inhalte der Agilen Produktentwicklung sind? Die Wissenschaft? Die Internationale Organisation für Normung? Das Bundessortenamt? Tatsächlich keine von denen, sondern eine historisch gewachsene Gruppe von Verbänden und Unternehmen bestimmt die öffentliche Wahrnehmung. Ihre Zusammensetzung hat sich in der Vergangenheit geändert und wird es in Zukunft vermutlich wieder tun, zur Zeit sind es aber diese hier:


Agile Alliance

Obwohl im deutschsprachigen Raum weitgehend unbekannt ist die Agile Alliance die älteste und in ihrem Gesamtwirken bedeutendste unter den "agilen Organisationen". Die Verfasser des Manifests für agile Softwareentwicklung bezeichneten sich bereits selbst als Agile Alliance und behielten diesen Namen bei als sie 2001 ihre Organisation formalisierten und für andere öffneten. Heute veranstaltet die Agile Alliance Konferenzen, fördert weltweit User Groups und kuratiert Literatur. Als eine von nur wenigen Organisation in dieser Liste verkauft sie keine Zertifizierungen und ist nicht mit einem bestimmten Framework verbunden.


"Scrum GbR"

Zugegeben, unter diesem Namen tritt die "Scrum GbR" nur auf dieser Seite auf. Die Zusammenarbeit der beiden Scrum-Erfinder Ken Schwaber und Jeff Sutherland hat keine explizite Rechts- oder Organisationsform, wodurch sie in Deutschland automatisch zu einer Gesellschaft bürgerlichen Rechts würde. Mit dem Scrum Guide verantworten und aktualisieren die beiden das neben dem Agilen Manifest wichtigste Dokument der agilen Bewegung, auf das sie mit jeweils separaten Organisationen aufbauen (siehe weiter unten).


Scrum Alliance

Die Scrum Alliance war 2001 die erste Organisation die nur einem Teilaspekt der Agilität gewidmet wurde: sie ist mit einem spezifischen Framework (Scrum) verbunden und sie hat im Jahr 2002 die ersten agilen Zertifizierungen überhaupt verkauft. Da sie als Verband gleichzeitig den Anspruch verfolgt Teil einer globalen Scrum-Community zu sein und hier auch viel Gutes tut, hat sie gleichermassen einen guten und zweifelhaften Ruf. Gut wegen ihrer Förderung von User Groups und Chapters auf der ganzen Welt, zweifelhaft weil der heutige agil-industrielle Komplex auf ihre regelmässig kostenpflichtig zu erneuernden Zertifizierungen zurückgeht.


Scrum.org

Der Verband Scrum.org wurde 2010 von Ken Schwaber, einem der beiden Erfinder von Scrum, als Reaktion auf die zunehmende Kommerzialisierung der Scrum Alliance gegründet. Zwar werden auch hier Zertifizierungen verkauft, sie sind aber deutlich billiger als die der Scrum Alliance und sie sind dauerhaft gültig, müssen also nicht immer wieder erneuert werden. Umgekehrt ist die Community-Förderung deutlich restriktiver als bei der Scrum Alliance, nur von zertifizierten Trainern organisierte Gruppen werden gefördert. Zusätzlich zum eigentlichen Scrum hat Scrum.org mit Nexus ein eigenes Skalierungsframework entwickelt.


Scrum Inc.

Die erste rein kommerzielle Organisation in dieser Liste. Die Scrum Incorporation ist die Firma von Jeff Sutherland, dem anderen der beiden Erfinder von Scrum. Es handelt sich um eine Unternehmensberatung die bei der Einführung von Scrum hilft und Zertifizierungs-Lehrgänge anbietet, ursprünglich für die Scrum Alliance, mittlerweile für eigene Zertifizierungen. Auch Scrum Inc. hat mit Scrum@Scale ein eigenes, auf Scrum aufsetzendes Skalierungsframework entwickelt, das aus dem 1996 eingeführten Scrum of Scrums-Meeting hervorgegangen ist und damit das älteste agile Skalierungsframework überhaupt darstellt.


"Spotify Model Complex"

Ein kurioser Fall. Das so genannte "Spotify Model" war ursprünglich nur als Erfahrungsbericht oder Fallstudie aus einem Einsatz des Agile Coaches Henrik Kniberg gedacht, da dieser Bericht aber "zu überzeugend" geraten ist wurde es von zahllosen Unternehmensberatungen kommerzialisiert und als Blaupause für agile Skalierung verwendet - obwohl seine Urheber immer wieder betonen, dass das nie so beabsichtigt war, und dass es selbst an seinem Ursprungsort schon nach kurzem nicht mehr in dieser Form eingesetzt wurde. Ungeachtet dessen hat das Spotify Model mittlerweile einen Verbreitungsgrad wie kaum ein anderes Skalierungsframework (vermutlich mit Ausnahme von SAFe, siehe unten).


Kanban University

In gewisser Weise die Kanban-Entsprechung der Scrum Alliance. Ursprünglich vom Manager und Berater David J. Anderson als Lean Kanban University gegründet, hat sich die Kanban University verdient gemacht indem sie die Methode aus der Hardware-Fertigung in die Wissensarbeit übertragen und zu diesem Zweck ausgebaut und mit einem Regelwerk versehen hat. Gleichzeitig ist sie ebenfalls in das Geschäft mit den Zertifizierungen eingestiegen, was auch ihr den Vorwurf übermässiger Kommerzialisierung eingetragen hat.


Flight Levels Academy

Zu Beginn eine Abspaltung der Kanban University hat sich die Flight Levels Academy nach und nach von ihrem Kanban-Ursprung gelöst und sich zu einem übergreifenden Business Agility Framework entwickelt, das den Schwerpunkt auf möglichst leichtgewichtige und flexible Interaktionen zwischen den einzelnen Unternehmensteilen legt und in grösseren Firmen langsam populärer wird. Aufgrund der Erfindung des Flight Level-Ansatzes durch Klaus Leopold hat die Flight Levels Academy als einzige "agile Leitorganisation" einen Ursprung im deutschsprachigen Raum. Und ja, Zertifizierungen gibt es auch.


Scaled Agile Inc.

Die kommerziell erfolgreichste Ausprägung organisierter Agilität überhaupt. Obwohl das dahinterstehende "Scaled Agile Framework" (SAFe) im Grunde sehr schlicht ist haben eine gekonnte Vermarktung und ein auf die Spitze getriebenes Geschäft mit teuren, schnell ablaufenden Zertifizierungen dafür gesorgt, dass Scaled Agile Inc. wahlweise anerkennend oder verabscheuend als die Verkörperung des agil-industrielle Komplexes schlechthin wahrgenommen wird (ein manchmal zweifelhaftes Geschäftsgebaren trägt sicher nicht zur Besserung dieses Rufs bei). Für viele Manager sind SAFe und agile Skalierung mittlerweile Synonyme.


Disciplined Agile

Ein Nachzügler. Disciplined Agile (früher Disciplined Agile Delivery) war ursprünglich eines der ersten agilen Frameworks, wurde aber 2019 vom Project Management Institute (PMI) gekauft und weitgehend umgebaut. Bis heute wirkt das Ergebnis noch stellenweise konfus und inkonsistent, durch die dahinterstehende PMI-Marketingmaschine wird das Framework aber nach und nach sichtbarer, selbst wenn man noch immer kaum Anwendungsfälle findet und kaum jemand die Zertifizierungen kennt. Dass es Disciplined Agile aber überhaupt schafft, sich neben den Platzhirschen Scrum, Kanban und SAFe zu platzieren ist bereits beachtlich, das ist im letzten Jahrzehnt fast keinem anderen gelungen.


---


Wie man es bewerten will, dass ausgerechnet diese zehn sehr unterschiedlichen Zusammenschlüsse und Organisationen zur Zeit weitgehend definieren was unter Agilität zu verstehen ist bleibt natürlich jedem selbst überlassen. Und wer es möglicherweise schaffen wird in diese Liga vorzustossen wird spannend zu beobachten sein, an aktuellen Beispielen wie The Flow System, FAST und unFIX und an älteren wie XP und Modern Agile kann man sehen wie schwer es ist, Sichtbarkeit zu gewinnen und zu behalten. Wenigstens ist die Landkarte der organisierten Agilität divers, das ist zumindest etwas Positives.

Montag, 5. Dezember 2022

Digitalisierung (VI)

Bild: Pixabay / Slon Pics - Lizenz

Im Kontext von agilem Arbeiten gilt Digitalisierung grundsätzlich als etwas Gutes. Die einfache Verfügbarkeit und Verarbeitbarkeit von Daten, die extrem beschleunigte Kommunikation und das Wegfallen der Aufwände für die physische Aktenlagerung und -verwaltung können entscheidend zur schnellen Reaktions- und Lieferfähigkeit beitragen. Allerdings kann auch das Gegenteil zutreffen, Die Digitalisierung kann die Agilität behindern und einschränken.


Dieses Phänomen tritt absehbar dann auf, wenn die Flexibilität einer digitalen Eingabe-Regulierung oder Prozess-Steuerung kleiner ist als die Varianz der eingehenden Parameter. Weniger technokratisch gesagt: Wenn digitalisierte Prozesse und Formatierungen nur für einen Teil der möglichen Anwendungfälle passend sind, für alle anderen aber nur noch eingeschränkt oder gar nicht, dann wird es für all diese anderen kompliziert und langwierig.


Das Bemerkenswerte an derartigen Konstellationen: in vielen Fällen sind sie nicht zufällig entstanden sondern sie sind explizit so gewollt. Das kann zum einen so sein, weil unreflektiert bestehende dysfunktionale Formate oder Prozesse digitalisiert werden (unvergessen ist das legendäre Zitat "Wenn sie einen Scheißprozess digitalisieren, dann haben sie einen scheiß digitalen Prozess."). Die funktionieren dann genauso schlecht wie vorher in analoger Form.


Zum anderen kann aber auch die irrige Annahme dahinterstecken, dass man durch eine Einschränkung von Handlungsoptionen im digitalisierten Prozess auch Komplexität und Ungewissheit einschränken könnte (was letztendlich nichts anderes als eine weitere Taylorismus-Phantasie ist). Da das meistens in der Realität nicht funktioniert führt es dazu, dass immer wieder falsche oder unnötig aufwändig erzeugte Ergebnisse zustandekommen, was auch hier auf Kosten der Agilität geht.


Aber selbst wenn derartige Hintergründe nicht gegeben sind kann Digitalisierung ein Hindernis für ein agiles Vorgehen sein. Dann nämlich, wenn die digitalisierten Systeme so umfangreich oder so technologisch so veraltet sind, dass selbst kleine Anpassungen unverhältnismässig viel Zeit und Geld erfordern. Schlimmstenfalls kann es sogar zum technischen Bankrott kommen, dem Zustand in dem Anpassungen gar nicht mehr möglich sind.


Heisst das im Ergebnis also, dass man Digitalisierung lassen soll wenn man agil arbeiten möchte? Natürlich nicht. Völlig analog würde ein agiles Vorgehen ebenfalls nur noch schwer möglich sein. Man sollte sich aber bewusst machen, dass Digitalisierungsvorhaben nicht nur Vorteile mit sich bringen sondern auch Einschränkungen und Risiken. Derer sollte man sich bewusst sein, sonst riskiert man, dass man zwar digital arbeitet, aber auch langsam und unflexibel ist.

Mittwoch, 30. November 2022

Kommentierte Links (XCIV)

Bild: Pixabay / Buffik - Lizenz
Das Internet ist voll von Menschen die interessante, tiefgründige oder aus anderen Gründen lesenswerte Artikel schreiben. Viele dieser Texte landen bei mir, wo sie als „Food for Thought“ dazu beitragen, dass auch mir die Themen nicht ausgehen. Wie am Ende jedes Monats gibt es auch diesesmal wieder eine kommentierte Übersicht über die erwähnenswertesten.

Kunal Bhalla: Eating Elephants

Mal wieder ein Artikel bei dem bereits der Entstehungsprozess interessant ist - Kunal Bhalla hat ihn nach und nach in einem öffentlich zugänglichen Google Doc verfasst und so bereits zu frühen Versionen Feedback erhalten können. Das seit diesem Monat weitgehend fertige Ergebnis ist ein ausführlicher Überblick über alle Aspekte die beim Starten und Durchführen grosser IT-Projekte zu beachten sind. Das ist z.T. etwas technisch, viele Passagen beschäftigen sich aber auch mit Organisations-, Kommunikations- und Denkmustern. Und obwohl das Wort Agile kein einziges mal vorkommt würde eine Umsetzung aller Empfehlungen definitiv dazu führen, dass das Projekt in dem sie umgesetzt werden weitgehend agil aufgestellt ist.

Liam Kane: Agile Portfolio Management

Ein häufiges Antipattern in agilen Teams und Projekten ist, dass zu wenig über den nächsten Sprint hinaus geplant wird. Die Motive dafür sind zwar grundsätzlich verständlich, schliesslich würde eine zu detaillierte Langfristplanung auf Kosten der Agilität gehen, zu wenig Planung führt aber oft zu "Fahren auf Sicht" und zu unnötig häufigen Kurswechseln. Liam Kane versucht hier aufzuzeigen wie sich Planungsvorlauf und Agilität kombinieren lassen. Dazu kombiniert er das Drei Horizonte-Modell mit Portfolio-Kanban und dem Weighted Shortest Job First-Modell. Wie immer in solchen Fällen ist zwar davon abzuraten seinen Ansatz unreflektiert zu kopieren, einen interessanten Impuls bieten kann er aber auf jeden Fall.

Kent Beck: Cloud Development Environments Tame Complexity By Reducing State

Noch einmal ein etwas technischeres Thema. Kent Beck, der Erfinder des Extreme Programming, teilt in seinem Blog seine Gedanken zu einem Thema, das selbst die meisten Experten vermutlich nicht als entscheidend für mehr oder weniger Agilität sehen würden: sollte sich die Entwicklungsumgebung eines Entwicklers auf seinem lokalen Rechner befinden oder in der Cloud? Basierend auf vier Faktoren die zu Kontrollverlust in Softwareentwicklungs-Vorhaben führen können (Variabilität, Vernetztheit, Status-(Un)eindeutigkeit, Irreversibilität) kommt er zu dem Ergebnis, dass Cloud-Umgebungen wesentlich besser geeignet sind um schnell arbeits-, liefer- und reaktionsfähig zu sein.

Michael Lloyd: Dysfunction Mapping; A tool for effective Agile Coaching

Wie oben bereits gesagt, methodische Ansätze und Werkzeuge sollten nicht unreflektiert kopiert werden, können aber wertvolle Inspirationen sein. Auch auf das Dysfunction Mapping von Michael Lloyd trifft das zu. Mit ihm hat er eine Möglichkeit gefunden mit Hilfe einer grafischen Zuordnung Dysfunktionen und ihre Symptome voneinander zu differenzieren und mit den verschiedenen Organisationsprinzipien zu verbinden, die von ihnen negativ beeinflusst werden. Auch ein Umsetzungsweg gehört dazu, der die Phasen Themensammlung, Verknüpfung, Zweck-Analyse und Lösungs-Hypothese umfasst. Mit ihm kann man das Dysfunction Mapping nach und nach vor sich entstehen lassen.

Jason Yip: “What improves developer productivity?” is the wrong question

Als letztes wieder ein Klassiker. Jason Yip nimmt sich einmal mehr des Themas an, warum es nicht zielführend ist Organisationen auf maximale Entwickler-Produktivität zu optimieren (was aufgrund des missverständlichen Slogans "Doing twice the work in half the time" immer wieder das Ziel agiler Transitionen ist). Mit Hilfe einer einfachen Wertstrom-Visualisierung zeigt er auf, dass die Effekte im Zweifel sogar das Gegenteil von dem sein werden was gewünscht ist. Die altbekannte Erkenntnis am Ende: wer eine bessere Systemleistung will muss auch das Gesamtsystem optimieren, nicht nur seine Einzelteile.

Montag, 28. November 2022

Chesterton's Fence

Bild: Rawpixel - CC0 1.0

Beim Navigieren und Unbestimmtheit und Komplexität ist es immer hilfreich, ein Set an hilfreichen Verhaltens- und Erkenntnis-Grundsätzen parat zu haben. Als Schutz vor Affekthandlungen und verzerrten Wahrnehmungen können sie dazu beitragen weniger voreilige und wenig durchdachte Entscheidungen zu treffen. Einer dieser Grundsätze ist Chesterton's Fence, benannt nach dem britischen Schriftsteller und Philosophen Gilbert Keith Chesterton.


Chesterton (dem man eine Vorliebe nachsagte, seine Erkenntnisse in Form von Sprichwörtern und Allegorien festzuhalten) wollte mit seinem Zaun-Vergleich seine Leser davor bewahren, bei Reform- oder Erneuerungsvorhaben vorschnell die bisher vorhandenen Regeln und Prozesse abzuschaffen, ohne darüber nachzudenken aus welchem (möglicherweise noch immer relevanten) Grund sie ursprünglich eingeführt wurden. Er lautet stammt aus seinem Buch The Thing und lautet folgendermassen:


In the matter of reforming things, as distinct from deforming them, there is one plain and simple principle; a principle which will probably be called a paradox. There exists in such a case a certain institution or law; let us say, for the sake of simplicity, a fence or gate erected across a road. The more modern type of reformer goes gaily up to it and says, 'I don't see the use of this; let us clear it away.' To which the more intelligent type of reformer will do well to answer: 'If you don't see the use of it, I certainly won't let you clear it away. Go away and think. Then, when you can come back and tell me that you do see the use of it, I may allow you to destroy it.


Was beim Lesen dieser Passage aus Chestertons Buch auffällt ist, dass er sich dem Phänomen der voreiligen Veränderung in zwei Dimensionen annähert. Zum einen der des zu reformierenden Sachverhalts. Wer die Gründe für die Einführung der vorhandenen Regeln und Prozesse nicht kennt nimmt nur einen Teil des Systems wahr das er verändern will, mit der Folge, dass die Veränderung unabsehbare Wechselwirkungen auslösen können, ggf. mit negativen Folgen.


Wichtiger ist aber die andere Dimension, die des Menschen der die Veränderungen anstösst. Die in solchen Momenten häufige Aussage "darin sehe ich keinen Sinn" zeigt für Chesterton eben nicht auf, dass dort keiner ist, sondern dass demjenigen der sie ausspricht ein Erkenntnis-Kurzschluss unterläuft: er geht davon aus, dass etwas das er selbst nicht wahrnimmt nicht existieren kann. Er unterliegt damit einem individualistischen Fehlschluss und baut seine weiteren Handlungen auf diesem auf.


Chesterton's Fence ist damit ein Aufruf zu mehr Selbstreflexion. Bevor man sich an die Reformierung eines komplexen Systems begibt sollte man sich immer fragen, ob die Wahrnehmung von dessen Ist-Zustand wirklich der Realität entspricht oder eher von eigenen Annahmen und gedanklichen Abkürzungen geprägt ist. Tut man das nicht besteht nicht nur das Risiko, dass ungewollte Ergebnisse eintreten, man wird auch von denen überrascht werden und ihre Entstehung nicht verstehen.

Donnerstag, 24. November 2022

Agile bureaucracy (and Hope)

Ich hätte schon früher eine Karriere als Vortragsredner anstreben sollen, die Ideen hätte ich gehabt. Vor über sechs Jahren habe ich über organisatorische Schulden geschrieben, und jetzt sind sie ein Ausgangspunkt auf den Jurriaan Kamer seinen hörenswerten Vortrag aufbaut. Zum Ansehen empfohlen.



Was man ihm hoch anrechnen muss ist, dass er es nicht beim Anprangern von Missständen belässt. Er versucht auch herauszuarbeiten was man besser machen kann, und das an konkreten Beispielen aus Firmen die ihre Arbeitsweisen bereits umgestellt haben.

Montag, 21. November 2022

Die häufigsten Fehler bei einer Kanban-Einführung (II)

Bild: Wikimedia Commons / Anick Marie - CC BY-SA 2.0

Dass es bei der Einführung von Kanban gibt es so einiges gibt, auf das man achten muss, dürfte hoffentlich klar sein, sowohl in Bezug darauf woran man auf jeden Fall denken sollte, als auch in Bezug auf das was man besser lassen sollte. In der letzten Kategorie findet sich aber auch etwas das viele überraschend finden - man sollte am Anfang besser keine Work in Progress-Limits (WIP-Limits) einführen. Wenn überhaupt ist das ein späterer Schritt, zu Beginn macht er fast nie Sinn.


Auf den Einen oder Anderen mag das verwirrend wirken. Sind WIP-Limits nicht ein zentraler Teil von Kanban? Und funktioniert die Einführung von Kanban nicht so, dass man alle Arbeit auf einem Board visualisiert und dann begrenzt wie viel davon gleichzeitig durchgeführt wird, damit das was begonnen wird dadurch schneller fertig werden kann? Die Antwort: ja und nein. Ja WIP-Limits sind zentral, und nein, man sollte sie nicht so früh einführen, selbst wenn das gut gemeint ist.


Am einfachsten zu verstehen ist das in dem Fall, in dem alle bisherigen Arbeitspakete einfach auf ein To Do-In Progress-Done-Board gepackt werden. Dann wird sich dort gleichzeitig Arbeit aus verschiedenen Be- oder Verarbeitungsphasen befinden, mit einem gemeinsames WIP-Limit für alle. Dieses würde aber einzelne Gruppen wie z.B. die UX-Designer in die Untätigkeit zwingen, wenn andere, etwa die Tester, so viel parallele Arbeiten durchführen, dass dadurch die Obergrenze erreicht ist.


Aber auch bei ausdifferenzierteren Systemen, wie z. B. Design-Umsetzung-Test-Rollout können frühe WIP-Limits kontraproduktiv sein. Es kann zwar nicht mehr der zuletzt genannte Fall vorkommen, in dem sich verschiedene Phasen gegenseitig blockieren, in einem System das seine Umstellung auf Kanban gerade erst begonnen hat wird es aber noch Abhängigkeiten nach aussen geben, z.B. zu einer Einheit die Testdaten so langsam bereitstellt, dass ein WIP-Limit auch hier Leerlauf erzwingen würde.


Man kann sich noch weitere vergleichbare Konstellationen vorstellen, die zentrale Erkenntnis ist aber klar: wenn eine Organisationseinheit ihre Rahmenbedingungen nicht selbst unter Kontrolle hat erzwingen Work in Progress-Limits im Zweifel nicht mehr Focus und schnelle Fertigstellung sondern führen zu erzwungener Untätigkeit und zu Konflikten mit anderen Einheiten, auf deren Zulieferung oder Beteiligung man angewiesen ist um die selbstgesetzte (den anderen ggf. gar nicht bekannte) Obergrenze zu halten.


Die bessere Reihenfolge im Rahmen einer Umstellung auf Kanban wäre daher, zuerst die Arbeit zu visualisieren (was schon schwieriger ist als man denken sollte), dann den Beteiligten das Wissen und die Berechtigungen geben um ihre Rahmenbedingungen zu verändern und dann erst über WIP-Limits nachzudenken. Es kann (und sollte) dann natürlich auch zu ihnen kommen, der Punkt an dem das passiert liegt dann aber nicht mehr am Anfang sondern deutlich später.


Um zuletzt ein häufiges Gegenargument gleich abzufangen: ja, man könnte es für eine Übergangszeit zulassen, dass die WIP-Limits regelmässig verletzt werden und währenddessen daran arbeiten, dass das irgendwann nicht mehr nötig ist. Das hätte aber eine (unbewusste) Erziehung zur Normverletzung zur Folge, und das ist etwas wovon man jeder Organisation nur dringend abraten kann, wenn sie nicht in ganz andere Probleme geraten will.

Donnerstag, 17. November 2022

Conway's Law

Bild: Pixabay / Succo - Lizenz

Wenn irgendwo über gute und schlechte Software-Architektur diskutiert wird, wird mit grosser Wahrscheinlichkeit früher oder später das so genannte Conway's Law erwähnt werden, und zwar entweder als Antipattern das man unbedingt vermeiden sollte oder als häufig anzutreffender Wildwuchs, der möglichst schnell zu beseitigen ist. Einigkeit besteht aber immer darüber, dass es etwas Schlechtes ist. Es lautet folgendermassen:


Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.

Auf Deutsch: Organisationen die IT-Systeme entwerfen neigen dazu, die System-Designs so zu gestalten, dass sie Kopien ihrer Kommunikationsstrukturen sind.


Dieses "Gesetz" verdanken wir Melvin Conway, einem amerikanischen Software-Entwickler, der die Beobachtung auf der es beruht bereits in den 60er Jahren machte. Popularisiert (und mit seinem heutigen Namen versehen) wurde Conway's Law erst ein Jahrzehnt später von Frederick Brooks in seinem bis heute häufig zitierten Buch The Mythical Man Month. Und gültig und in vielen Organisationen zu beobachten ist es bis heute.


Dass Conway's Law immer wieder auftritt erklärte Conway damit, dass in grossen Organisationen häufig eine nur eingeschränkte Sicht auf Abläufe und Strukturen vorliegt. Eine Abteilung erkennt zwar wer ihr Informationen übergibt (z.B. ein Manager) oder wer sie von ihr entgegennimmt (z.B. eine nachgelagerte Organisationseinheit), wo sie ursprünglich entstehen, wo sie letztendlich enden oder durch welche anderen Stationen sie gehen ist aber nicht nachvollziehbar.


Bedingt dadurch wird bei vielen Digitalisierungs- oder Automatisierungs-Vorhaben immer nur an den Bereichen gearbeitet die bekannt sind, also zwischen der eingehenden und ausgehenden Kommunikationsschnittstelle liegen. Da das nicht nur in einer Abteilung stattfindet, sondern tendenziell jede so vorgeht, entsteht nach und nach für jede der Abteilungen ein entsprechendes IT-System, so dass die Systemlandschaft am Ende dem Organisationsaufbau entspricht.


Dieser Effekt mag auf den ersten Blick unproblematisch erscheinen, er ist es aber nicht. Wenn z.B. zwei Abteilungen unabhängig voneinander eine Übersicht über die Firmenkunden erhalten, sie aufgrund von Conway's Law in verschiedenen Systemen ablegen und sie nur um die jeweils eigenen Informationen zu Verkäufen, Verträgen, Beschwerden, etc. erweitern, dann wird eine firmeweite Sicht auf die Kundenbeziehungen unmöglich.


Auch weitere Probleme sind leicht vorstellbar. Verschiedene Abteilungen können z.B. die selben Daten benötigen, die dadurch von Kunden oder Kollegen redundant in verschiedene Systeme eingegeben werden müssen, sie können unterschiedliche Dateiformate verwenden, die nicht in andere Systeme übertragbar sind oder sie können unterschiedliche Vorgaben für Datenmengen oder IT-Sicherheit haben, durch die die verschiedenen Systeme inkompatibel werden.


Zuletzt werden Änderungen von übergreifender Bedeutung schwierig und aufwändig. Soll etwa in alle personenbezogenen Datensätze das neue Information "Arbeitsadresse" eingeführt werden muss ermittelt werden an welchen Stellen das nötig ist und ob es überall gleich umgesetzt werden kann, dazu muss die zeitgleiche Umsetzung koordiniert werden, möglichweise einschliesslich der Auflösung von Planungs- und Priorisierungskonflikten. All das kostet Zeit und Geld.


Um diese Auswirkungen zu vermeiden sollte versucht werden die Ursachen für Conway's Law zu beseitigen, indem Digitalisierungs- oder Automatisierungs-Vorhaben immer aus einer übergreifenden Perspektive konzipert werden. Um das zu erreichen gibt es zwei grundlegend unterschiedliche Ansätze: man kann zentrale Kontroll- und Koordinationsinstanzen schaffen, oder die Code Ownership auflösen und allen Einheiten erlauben übergreifend am Gesamtsystem zu arbeiten.


Der klassische Weg in den meisten Organisationen ist der erste, also die zentrale Kontroll- und Koordinationsinstanz, die versucht den zentralen Überblick zu wahren. Aus einer "agilen Weltsicht" ist dagegen die zweite besser, die aber eine Reihe von Voraussetzungen erfordert: übergreifendes System- und Business-Verständnis der Entwicklungsteams, Clean Code, hohe Testabdeckung und eine Einigung auf gemeinsame Standards in Formatierung, Programmierung, etc.


Egal welche Variante (oder Kombination der beiden) man bevorzugt, auf Eines kann sich aber so gut wie jeder einigen: alles ist besser als Conway's Law einfach hinzunehmen - dafür sind seine negativen Auswirkungen zu offensichtlich und zu schwerwiegend.

Montag, 14. November 2022

Ein Bild sagt mehr als 1000 Worte (XXXIV)

Grafik: monkeyuser.com - License

Zugegeben, es sind zwei Bilder. Aber darüber sehen wir heute einmal hinweg. Was mir ein Entwickler-Team einmal zu diesen beiden auf den ersten Blick schlichten Zeichnungen gesagt hat: it keeps on giving, oder mit anderen Worten - man entdeckt immer weitere Details die erkennbar an Phänomene aus dem echten Leben angelehnt sind.

Freitag, 11. November 2022

Warum agil? Discovery, Delivery, Reparatur, Resilienz

Bild: Andy Mabbett / Wikimedia Commons - CC BY-SA 3.0

Sinn- und Zweck-Fragen sind immer wieder erhellend. Im Umfeld agiler Transformationen ist eine von ihnen ein grosser Klassiker: die nach dem Grund wegen dem dort überhaupt agil gearbeitet werden soll. Häufig gibt es die generische Antworten, dass mehr Flexibilität oder höhere Reaktionsgeschwindigkeit angestrebt würden. Auf die Folgefrage wofür genau die nötig sind kommt dann häufig nicht mehr viel. Dabei gibt es gleich mehrere gute Antwortvarianten, z.B. Discovery, Delivery, Reparatur und Resilienz.


Bevor wir dazu kommen aber eine schnelle Definition: als Agilität wird hier die Fähigkeit verstanden in kurzen Abständen reaktions- und lieferfähig zu sein, sonst nichts. Allen die noch mehr darunter verstehen, wie z.B. Humanismus, (Basis-)Demokratie, New Work oder Achtsamkeit, seien zuerst dieser und dieser Artikel empfohlen. Ihre Kernaussage: wie alle Begriffe sollte man auch den der Agilität nicht überfrachten, wenn er benutzbar bleiben soll. Und damit zurück zu den vier Varianten.


Discovery

Um es als Beispiel-User Story zu formulieren:1 Als Startup möchte ich in kurzen Abständen reaktions- und lieferfähig sein, um Kundenbedürfnisse die ich neu entdecke schnell bedienen zu können. Einer der grossen Klassiker unter den Anwendungsfällen der Agilität - ein neues Produkt entsteht erst nach und nach in zu Beginn noch rudimentären Umfängen, und erst wenn mit denen validiert wird, dass es Nutzungs- und Zahlungsbedeitschaft gibt, kommt die nächste Umfangs-Erweiterung. Wenn nicht wird die Entwicklung eingestellt. Umgekehrt kann es auch sein, dass die Neuentdeckung von Nutzern oder Bedürfnissen dazu führt, dass Produktentwicklungsziele schnell dorthin ausgerichtet werden. Das klassische Framework dafür ist Lean Startup.


Delivery

Beispiel-User Story: Als Unternehmen im gesetzlich regulierten Umfeld möchte ich in kurzen Abständen reaktions- und lieferfähig sein, um meine Produkte schnell an neue Vorschriften anpassen zu können. Zunächst weniger intuitiv verständlich, bei etwas Nachdenken macht es aber Sinn. Stark regulierte Branchen wie z.B. der Banken- und Versicherungs-Sektor müssen mitunter im Monatsrhythmus neue Vorschriften in ihren automatisierten Prozessen abbilden. Starre Planung und unflexible Umsetzung sorgen oft dafür, dass Stichtage nicht eingehalten werden können, mit Strafen durch die Aufsichtsbehörden als Folge. Ausgerechnet dort wo es starke Regulierungen gibt wird daher in immer mehr Firmen versucht agil zu arbeiten. Die Methoden-Klassiker sind dabei Scrum und SAFe.2


Reparatur

Beispiel-User Story: Als Konzern mit veralteter, fehleranfälliger Software möchte ich in kurzen Abständen reaktions- und lieferfähig sein, um die häufig auftretenden Fehlfunktionen schnell reparieren zu können. Man mag es sich kaum vorstellen, aber in vielen Behörden und Unternehmen gibt es Anwendungen die seit dreissig oder vierzig Jahren in Betrieb sind, oder noch länger. In den meisten derartigen Fällen führen unentdeckte Bugs, übersehene Seiteneffekte oder historisch gewachsene Komplexität zu ständig auftretenden Funktionsfehlern. Wenn zentrale oder profitable Geschäftsprozesse davon betroffen sind ist es von kritischer Bedeutung, dass Ressourcen schnell umgeplant und Reparaturen zeitnah und unbürokratisch stattfinden können. Methodisch können einige DevOps-Aspekte sehr hilfreich sein.


Resilienz

Beispiel-User Story: Als von ständigen Disruptionen betroffenes Unternehmen möchte ich in kurzen Abständen reaktions- und lieferfähig sein, damit ich die Schäden durch externe Störungen begrenzen kann. Ein mit dem letzten verwandter Fall, mit dem Unterschied, dass die Probleme nicht (versehentlich) selbst erzeugt wurden sondern von aussen kommen. Das kann der neue und innovative Wettbewerber sein, aber auch Naturkatastrophen, Hackerangriffe oder Netzausfälle. Die Agilität wird hier gebraucht um diese Störungen früh zu erkennen, ihre Auswirkungen schnell zu begrenzen und möglichst schnell Kompensations- und Wiederherstellungsmassnahmen einleiten zu können. Das vermutlich am besten geeignete agile Framework ist Chaos Engineering.


Im Zweifel wird es auch noch weitere Herausforderungen geben wegen denen Agilität erstrebenswert ist, der allergrösste Teil wird sich aber einer dieser vier zuordnen lassen. Und dort wo das nicht möglich ist, ist es eine gute Idee genau zu prüfen ob nicht eine eher unsinnige Motivation der eigentliche Treiber ist (z.B. "Ich als Manager möchte überall schnell durchregieren können, wenn ich eine meiner monatlichen spontanen Eingebungen habe." oder "Wir wollen Modernität vortäuschen um Bewerber anzulocken".).


Und natürlich wird es immer wieder vorkommen, dass gleich mehrere der hier genannten Gründe für das Streben nach Agilität vorliegen, und zwar parallel. Das macht das Leben zwar nicht einfacher, es bietet aber immerhin einen kleinen Trost: mit der Einführung passender agiler Arbeitsweisen kann man in mehreren dieser Bereiche gleichzeitig für Verbesserungen sorgen.



1Die Debatte ob man User Stories aus der Perspektive eines Unternehmens formulieren sollte (eigentlich nicht) ignorieren wir heute einfach.
2Es gibt natürlich noch andere Konstellationen in denen Delivery im Focus steht, das hier ist nur ein Beispiel

Dienstag, 8. November 2022

Überstunden

Bild: Unsplash / Jonas Leupe - Lizenz

Zu den unschönsten Momenten im Leben eines Angestellten (oder eines von einem Auftraggeber abhängigen Freiberuflers) gehört es, wenn er direkt oder indirekt zu Überstunden aufgefordert wird, schlimmstenfalls verbunden mit der Drohung, bei der Nicht-Erreichung eines in normaler Arbeitszeit nicht zu erreichenden Ziels gefeuert oder nicht weiterbeauftragt zu werden. Als Betroffener ist man maximal genervt und frustriert. 


Trotzdem kommt es immer wieder dazu, die aktuelle Deadline für die an Twitters Bezahlfunktion arbeitenden Teams dürfte z.B. jetzt schon ein Klassiker unter den derartigen Fällen sein. Je nachdem wie abhängig vom Job oder wie beeinflussbar die zu Überstunden aufgeforderten Menschen sind kann es in solchen Konstellationen nicht nur zu einem späten Feierabend kommen sondern sogar zum Extrem: zum Übernachten am Arbeitsplatz, um möglichst viel Zeit dort verbringen zu können.


Quelle: Twitter


Was manchmal in solchen Fällen diskutiert wird - ist das nicht ein notwendiger Teil einer agilen Arbeitsweise? Muss man nicht immer wieder Überstunden schieben, wenn es notwendig ist (oder versprochen wurde) regelmässig Ergebnisse abzuliefern? Die Antwort darauf kann nur ein sehr verhaltenes "kommt drauf an" sein, denn selbst wenn es Fälle geben mag in denen das so ist - in den meisten erreicht man eher den gegenteiligen Effekt.


Um mit dem Grundsätzlichen zu beginnen: Agil zu arbeiten bedeutet, dass man schnell und ergebnisorientiert auf Veränderungen reagiert (responding to change over following a plan). Das bedeutet aber gerade nicht, dass Liefertermine und Lieferumfänge auch bei sich unerwartet ändernden Rahmenbedingungen eingehalten werden müssen, im Gegenteil. Da diese Termine und Umfänge Teil des initialen Plans sind wäre ein Beharren auf ihnen sogar hochgradig un-agil.


Natürlich kann es Grenzfälle geben. Die Leitmesse zu der ein Produkt fertig sein muss, wenn es dieses Jahr noch auf den Markt soll, oder den Stichtag an dem eine gesetzliche Regulierung in Kraft tritt, der eine IT-gestützte Dienstleistung entsprechen muss. Wichtig ist dann aber, dass sie nur in Ausnahmen auftreten und dass sie tatsächlich derartig harte Ursachen haben. In den meisten Fällen trifft das aber nicht zu, da ist die zentrale Motivation, dass Planänderungen einfach nicht gewünscht sind.


Diese Änderungsunwilligkeit wird dann häufig (schein-)rationalisiert, und das auch noch mit Argumenten die scheinbar zur Idee der Agilität passen: die Lead Time oder Time to Market soll kurz sein, die Verzögerungskosten (Cost of Delay) gering, das Kundenfeedback möglichst früh verfügbar. All das sind auch gute Ziele, was in einer solchen Argumentation häufig übersehen wird, ist aber der Preis der zu zahlen ist, wenn man sie mit Überstunden zu erreichen versucht.


Wie vermutlich jeder aus eigener Erfahrung bestätigen kann neigen überarbeitete, übermüdete und gestresste Menschen dazu mehr Fehler zu machen als solche die ausgeschlafen und ausgeglichen sind. Und diese Fehler führen zwangsläufig zu einem von zwei Effekten: entweder muss alles vor dem Release wieder in Ordnung gebracht werden (wodurch Zusatzaufwände entstehen, die alles verlangsamen) oder fehlerhafte Produkte gehen live, mit Fehlfunktionen und Hotfixes auf Produktion als Folge.


Vor allem dort wo regelmässig Überstunden gemacht werden häufen sich derartige Mehraufwände, und das oft in einem derartigen Ausmass, dass der scheinbare Zeitgewinn durch Überstunden ausgeglichen oder sogar in sein Gegenteil verkehrt wird. Zieht man ausserdem in Betracht, dass regelmässige Überstunden fast immer zu Abwanderung der Mitarbeiter in andere Unternehmen führen (verbunden mit Zusatzkosten für Recruiting und Onboarding) verschwindet der Business Case fast völlig.


Jedem Entscheidungsträger kann man daher nur raten es sich dreimal zu überlegen was er tut bevor er zu Überstunden aufruft. So verlockend die Aussicht auch sein mag damit irgendetwas kurzfristig zu erreichen - langfristig werden diejenigen Unternehmen erfolgreicher sein, die ihren Mitarbeitern ein ruhiges, kontinuierliches und steressfreies Arbeiten ermöglichen.

Donnerstag, 3. November 2022

Before you Scale - Descale

Mir ist gerade aufgefallen, dass es auf dieser Seite noch kein Video von mir gibt - bis jetzt. Das hier ist mein Vortrag vom Scaling Agile Summit im letzten Sommer, den ich auf dem Telekom Agilista-Barcamp wiederholt habe, wo er freundlicherweise aufgenommen wurde. Das Thema ist eines das mich schon lange begleitet und beschäftigt, die agile Skalierung.



Ich weiss nicht ob es daran liegt, dass ich zu dem Zeitpunkt Corona-positiv und dadurch etwas unkonzentriert war, aber ich höre in meinem Vortrag viel zu viele Ähs. Da muss ich noch an mir arbeiten

Montag, 31. Oktober 2022

Kommentierte Links (XCIII)

Bild: Pixabay / Buffik - Lizenz
Das Internet ist voll von Menschen die interessante, tiefgründige oder aus anderen Gründen lesenswerte Artikel schreiben. Viele dieser Texte landen bei mir, wo sie als „Food for Thought“ dazu beitragen, dass auch mir die Themen nicht ausgehen. Wie am Ende jedes Monats gibt es auch diesesmal wieder eine kommentierte Übersicht über die erwähnenswertesten.

Alexander Schatten: Getting Nothing Done

Der Titel sagt es ganz passend - wir bekommen nichts mehr fertig, oder zumindest keine Grossvorhaben mehr. Das was Alexander Schatten hier an sich ewig hinziehenden Infrastruktur- und IT-Projekten zusammenträgt ergibt eine beeindruckende und bedrückende Liste. Nicht besser wird der Gesamteindruck durch die von ihm identifizierten Gründe: langsamer werdender technischer Fortschritt, Überregulierung, mutlose und politisch getriebene Entscheidungsfindung sowie die abnehmende Fähigkeit die nötigen Ressourcen für grosse Projekte zur Verfügung stellen zu können. Ich würde noch einen hinzufügen: die Unwilligkeit und Unfähigkeit einmal beschlossene Pläne nachträglich anzupassen.

Stefan Kühl: Komplexität – Das Irrtum der Vereinfacher

Ein interessanter, aber sicher auch kontroverser Artikel. Stefan Kühl geht in ihm davon aus, dass alle Massnahmen, die zur Vereinfachung eines komplexen Systems führen sollen, ihr Gegenteil erreichen und in Wirklichkeit alles nur noch komplexer machen, bis zum Kontrollverlust. Als Beschreibung der Realität ist das durchaus zutreffend, fast alle Vereinfachungsprogramme die man in grossen Organisationen vorfinden kann sind eher Verschlimmbesserungen. Widersprechen würde ich allerdings beim Determinismus - man kann Komplexität sehr wohl reduzieren, allerdings muss dafür versucht werden das angestrebte Ziel zu vereinfachen und nicht nur die zu seiner Erreichung eingesetzten Techniken und Prozesse.

Jason Yip: My take on why goal cascades are harmful and what to do instead

In diesem Blogpost fasst Jason Yip gut zusammen was die Probleme der so genannten "kaskadierenden Ziele" sind, die von ganz oben vorgegeben und dann durch alle Hierarchieebenen durchgereicht werden: Entkoppelung von Entscheidungskompetenz und Umsetzungskompetenz, langsame Durchführung, Ausblendung von (sinnvollen) Eigendynamiken der unteren Ebenen und Vernachlässigung von lokal wichtigen Nebenzielen. Sein Gegenvorschlag: von ganz oben sollten eher abstrakte Leitlinien und Produktvisionen kommen, die dezentral in Ziele heruntergebrochen werden, die dann regelmässig dezentral aufeinender abgestimmt werden können.
PS: Der Blogpost ist auch die Fortführung eines gleich benannten Artikels von John Cutler, der ebenfalls zum Lesen empfohlen ist.

Carl Rogers: The Five Orders of scaling agile teams

Die erste Regel der agilen Skalierung erfreut sich mittlerweile einer gewissen Popularität. Sie lautet schlicht Lass es sein. Für die möglichen weiteren Regeln gibt es zwar viele Ideen, eine Übereinkunft darauf welche es sein sollen existiert aber nicht. Diese Variante von Carl Rogers hätte das Potential zu weiter Verbreitung, weshalb ich hier zu ihrer Bekanntheit beitragen will:
1. Don’t scale
2. Create independence
3. Create interdependence between teams
4. Create interdependence between products
5. Manage dependencies between work to be done

Wichtig für das Verständnis - diese Regeln bilden eine Art Eskalationshierarchie: nach jeder von ihnen sollte man sich nur dann richten, wenn alle davor ausprobiert wurden und nicht funktioniert haben.

Chris Combe: Add skills not people to your cross-functional teams

Aus diesem Artikel von Chris Combe könnte man möglicherweise eine weitere Skalierungsregel ableiten: wenn in einem Team bestimmte Fähigkeiten fehlen füge erst dann neue Teammitglieder hinzu wenn die bestehenden sich das Wissen nicht aneignen können. Warum die Vergrösserung eine eher schlechte Idee ist erklärt er dabei mit Hilfe zahlreicher Referenzen und Verweise, die jeweils zu weiteren lesenswerten Texten führen.