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.