Kommentierte Links (LXXXIII)

Bild: Pixabay / Buffik - 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.

Colin M. Fisher, Teresa M. Amabile, Julianna Pillemer: How to Help (Without Micromanaging)

"Ich wollte doch nur helfen" dürfte die häufigste Entschuldigung von Managern sein wenn ihre Untergebenen sich über übergriffiges Micromanagement beschweren. Man kann davon ausgehen, dass das in den meisten Fällen tatsächlich die zugrundeliegende Motivation ist, trotzdem liegt oft am Ende das Vertrauensverhältnis in Trümmern. Wie eine Konstellation aussieht in der eine Hilfestellung auch als eine solche empfunden wird arbeiten Colin M. Fisher, Teresa M. Amabile und Julianna Pillemer anhand von Fallstudien heraus: demjenigen dem geholfen wird muss klar sein, dass er alleine nicht weiterkommt, es muss bereits vor dem Hilfsangebot psychologische Sicherheit vorhanden sein und die Hilfe muss sich an der Verfügbarkeit und Aufnahmebereitschaft desjenigen dem geholfen wird ausrichten.

Emily Webber: Building a progression framework for a multidisciplinary organisation

Zu den grössten Herausforderungen vor denen agil arbeitende Organisationen stehen gehört die Entwicklung eines beruflichen Karriere-Modells. Klassische Karrierepfade stehen durch ihre Linearität und ihre Einbettung in organisatorische Silos im Widerspruch zum agilen Zielbild, die häufig anzutreffende "agile Alternative" einer Fachkarriere ohne feste Abteilungs-Zuordnung macht es dagegen schwer Weiterentwicklungen zu erkennen (und zu belohnen). Das von Emily Webber entwickelte Modell von Citizens Advice versucht beides möglich zu machen, mit einem Ansatz der die klassischen Junior/Mid-Weight/Senior-Pfade beibehält, es aber möglich macht mehrere parallel zu verfolgen und zwischen ihnen zu wechseln (hier ein Erfahrungsbericht der Einführung). Eine schöne Inspiration für ähnliche Versuche.

Simon Pitt: How IT Stopped Being Boring

In der allgemeinen Wahrnehmung ist die IT etwas noch immer Neues, Junges und Modernes. Was bei dieser (oberflächlichen) Betrachtung allerdings untergeht ist, dass auch dieser scheinbar moderne Zweig der Technik bereits mehr als ein halbes Jahrhundert alt ist. Diese lange Geschichte führt dazu, dass in den einstigen Pionier-Branchen (Telekommunikation, Banken, Versicherungen) mittlerweile Generationenkonflikte stattfinden, und zwar sowohl zwischen älteren und jüngeren Mitarbeitern als auch zwischen älteren und neueren Technologien. Am Beispiel eines fiktiven Systemadministrators erzählt Simon Pitt davon wie dieser Konflikt ausgetragen wird und die Arbeitswelt verändert.

Diana Kwon: Our Brain Typically Overlooks This Brilliant Problem-Solving Strategy

Es ist eine Erkenntnis die weitreichende Auswirkungen darauf hat wie Menschen Problemlösungen angehen sollten und darauf wie die Wirksamkeit dieser Lösungsbemühungen bewertet werden sollte: das menschliche Gehirn scheint eine natürliche Tendenz zu haben Problemlösungsstrategien darauf aufzubauen, dass dem problembehafteten Objekt etwas hinzugefügt wird - Features, Kontextinformationen, Restriktionen, Benutzergruppen, etc. Das findet selbst dann statt, wenn die gegenteilige Vorgehensweise, also das Weglassen sinvoller wäre. Diana Kwon fasst in diesem Text zusammen wie Forscher der Universität von Virginia diese Erkenntnis gewonnen haben, wer die Studie im Original lesen will findet sie hier.

Gaëtan Belbeoc'h: Tribal Leadership Techniques Through the Eyes of an Agilist

Seit Henrik Kniberg die Tribe-Organisation von Spotify bekannt gemacht hat ist die Wortwahl mit der über agile Skalierung gesprochen wird eine andere, bis zu dem Punkt, dass man das Gefühl haben kann mit einer Gruppe Ethnologen zu reden. Naheliegenderweise könnte man denken, dass auch einige echte Vertreter dieser Berufsgruppe in den Diskurs einbezogen werden sollten, doch das ist noch nicht passiert - bis jetzt. Gaëtan Belbeoc'h hat ein Jahr Feldforschung unter Eingeborenenvölkern am Amazonas betrieben und zusammengefasst welche Parallelen es zwischen ihrer Selbstorganisation und der in agilen Teams gibt. Spoiler: es sind einige.

Jessica Kerr: Those pesky pull request reviews

Ein eher technisches Thema. Pull Requests (Anfragen an einen anderen Entwickler neuen Code zu begutachten und freizugeben) sind in vielen Firmen verpflichtender Teil des Software-Entwicklungsprozesses und werden oft als State of the Art angesehen. Jessica Kerr hat da eine andere Meinung. Tatsächlich kann man die Probleme die sie beschreibt häufig beobachten: (zu lange) auf Freigabe wartende Arbeitspakete, Kontext-Switching zwischen eigener Arbeit und dem Reviewen von anderem Code, dadurch gestörte Konzentration, zwischenmenschliche Konflikte und vieles mehr können zu Ineffizienz, nachlassendem Engagement und schlechterem Betriebsklima führen. Die von ihr vorgeschlagene Alternative ist ein Klassiker unter den agilen Praktiken: Pair- und Mob-Programming.

Makoto Shiraishi, Hironori Washizaki, Daisuke Saito, Yoshiaki Fukazawa: Comparing Participants’ Brainwaves During Solo, Pair, and Mob Programming

Apropos Pair Programming. Auch diese Praktiken sind mittlerweile zum Gegenstand wissenschaftlicher Untersuchungen geworden, in diesem Fall in der Psychologie. In einem leicht nach Science Fiction klingenden Experiment wurden Softwareentwickler während der Durchführung von Solo-, Pair- und Mob-Programming an ein Gerät zur Messung von Gehirnaktivitäten angeschlossen. Die Ergebnisse: während Ruhezustände vor allem im Solo-Programming vorkamen führten Pair- und Mob-Programming zu höherer Konzentration und geringerem Schwierigkeitsempfinden. Die durchführenden Forscher geben selbst an, dass die Ergebnisse vor allem ein Anstoss zu weiterer Forschung sind, interessant sind sie aber auf jeden Fall.

Ellen Cushing: Slackers of the World, Unite!

Obwohl sich dieser Artikel von Ellen Cushing vor allem auf Slack bezieht lassen sich seine zentralen Punkte auch auf vergleichbare Dienste übertragen, z.B. auf HipChat oder MS Teams. Neben einer Optik und Bedienbarkeit die sich stark an Social Networks anlehnt und damit für eine niedrige Eingangshürde sorgt nennt sie vor allem die Dezentralität, Hierarchiefreiheit und allgemeine Zugänglichkeit. Abgeleitet daraus erkennt sie eine sehr starke Demokratisierung und Egalisierung der Kommunikation in allen Unternehmen die diese Programme bei sich einsetzen. Ein klarer Fall von "Function follows Form", den jeder bestätigen kann der schon einmal mit Slack & Co gearbeitet hat.

Kommentierte Links (LXXXII)

Grafik: Pixabay / The Digital Artist - Lizenz

Leicht verfrüht: die Kommentierten Links des Dezembers zu interessanten, kontroversen, tiefgründigen oder aus anderen Gründen lesenswerten Artikeln. Am letzten Tag dieses Monats folgt wie in den letzten Jahren eine weitere Ausgabe, dann mit den Artikeln die es zu Unrecht nicht in die Kommentierten Links der vergangenen Monate geschafft haben.

Marty Cagan: Product Ops Overview

Dieser Artikel ist Fortsetzung von Marty Cagans Process People-Debattenbeitrag vom letzten Oktober, der wegen seiner sehr kritischen Ausrichtung gegenüber der Product Ops-Bewegung zu einem kleinen Sturm im Produktmanagement-Wasserglas geführt hat. Bereits damals hatte er angekündigt seine Aussagen auszudifferenzieren und aufzuzeigen, dass es sowohl hilfreiche als auch schädliche Varianten gibt, hier ist jetzt das Ergebnis. Welche dieser Varianten sich langfristig als (mehr oder weniger) verbindliche Definition von Product Ops durchsetzen wird bleibt abzuwarten, als Momentaufnahme ist seine Übersicht aber hochinteressant.

Tim Ottinger: Managing Interruptions

Das was Tim Ottinger hier festgehalten hat ist eine überraschend naheliegende aber trotzdem im Prozess- oder Projektmanagement eher seltene Begründung dafür, dass man parallele Arbeit vermeiden sollte: dadurch dass mit jeder weiteren parallel durchgeführten Arbeit die Zahl der am Fortschritt interessierten Stakeholder steigt, steigt auch die Zahl der Störungen und Unterbrechungen denen man ausgesetzt ist, da immer mehr Menschen sich nach Zwischenständen erkundigen. Da diese Unterbrechungen Zeit in Anspruch nehmen und die Konzentration stören verlangsamt der Fortschritt sich. Das kann eigentlich keiner wollen.

Bob Marshall: All Agilists Are Unethical

An dieser Stelle folgt ein kurzer Exkurs in die Philosophie. Aufbauend auf den "Ethics of Belief" von William Kingdon Clifford ("It is wrong always, everywhere, and for anyone, to believe anything upon insufficient evidence") greift Bob Marshall einen der am häufigsten diskutierten Kritikpunkte an der agilen Produktentwicklung auf: es gibt kaum empirische Belege für ihre grundsätzliche Überlegenheit über die "klassischen Ansätze" (mehr dazu hier), weshalb man jeden Einzelfall gesondert betrachten muss. Diese Einzelfallbetrachtungen vermisst Marshall in den von ihm beobachteten agilen Transitionen, weshalb er ihnen (angelehnt an Clifford) unethische Beweggründe unterstellt. Ironischerweise wären auch seine eigenen Ausführungen bei konsequenter Anwendung der Ethics of Belief unethisch (da lediglich auf subjektiver Wahrnehmung beruhend), ein guter Denkanstoss sind sie aber trotzdem.

Karl Scotland: How to Measure the Predictability of Agile

Der Titel dieses Artikels ist leider etwas missverständlich. Anders als man ausgehend von ihm denken könnte beschreibt Karl Scotland hier nicht wie vorhersagbar Agilität ist (was alleine schon semantisch und grammatisch ein Ding der Unmöglichkeit ist) sondern welche Indikatoren Rückschlüsse darauf zulassen, dass die Anwendung agiler Praktiken und Frameworks zu Prozessverbesserungen geführt hat. Wichtig dabei ist, dass es sich bei den von ihm gesammelten Beispielen nicht um generalistisch anwendbare Regeln und Beweise handelt sondern eben um das was Indikatoren sind - hilfreiche Hinweise, die aber noch zusätzlicher Validierung bedürfen. Als solche verstanden können sie aber dazu beitragen den Erfolg agiler Transitionen überprüfbar zu machen.

Matt Philip: Kanban Myths

Dass Kanban als "Open Source-Methode" kein wirkliches Richtig und Falsch kennt hatte ich schon einmal aufgeschrieben, Auflistungen von "Kanban-Mythen" sollte man immer mit diesem Vorbehalt im Hinterkopf lesen. Trotzdem haben die von Matt Philip aufgeführten Punkte aber ihre Berechtigung, schliesslich sind sie so unsinnig, dass sie auch bei wohlwollender Betrachtung keinen Sinn ergeben. Um so bemerkenswerter ist ihre Verbreitung, jeder dieser Mythen ist auch mir bereits wiederholt begegnet.

An Agile Little Christmas

Lieder von Chad Beier habe ich schon zwei mal hier eingebunden, jeweils mit "agilen Coverversionen" von zeitlosen Pop/Rock-Klassikern. Auch dieses hier ist im Original zeitlos (Have Yourself a Merry Little Christmas von Judy Garland, bzw. von Frank Sinatra) in dieser Version aber wieder so umgedichtet, dass ein Bezug zur agilen Softwareentwicklung besteht.

Selbst wenn die Eingängigkeit ein bisschen dadurch verloren geht, dass die Ursprungsversion in Deutschland bei weitem nicht so bekannt ist wie in den USA, kann man sich das Ergebnis gut anhören. Und mit seinem Rauschebart wirkt Beier im Video auch sehr wie ein Weihnachtsmann.

North Star Metrics

Grafik: Pixabay / 5718714 - Lizenz

Die Idee sich auf ein einziges Ziel zu konzentrieren und focussiert daran zu arbeiten zieht sich durch zahlreiche Lean und Agile-Frameworks und findet sich u.a. in Sprint- und Produktzielen, im Single Piece-Flow, in OKRs oder in Work in Progress-Limits wieder. Wenn der Gegenstand dieser Focussierung ein schnell umsetzbares Arbeitspaket oder Nahziel ist kann man sich die Umsetzung auch gut vorstellen, aber wie würde das bei Fern- oder Dauerzielen gehen? Ein Ansatz sind die so genannten North Star Metrics.

Die dahinter stehende Idee ist es, eine einzige Messgrösse zu finden, die von so zentraler Bedeutung für die gesamte Organisation ist, dass ihre Optimierung Vorrang vor allem anderen hat. Das funktioniert natürlich nur dort, wo es ein klar umrissenes Geschäftsfeld gibt, das sich auf ein klar definertes Produkt (oder eine klar definierte Dienstleistung) ausrichtet, aber dort kann es ein interessanter Weg sein um focussiertes datengetriebenes Arbeiten zu ermöglichen.

Um Beispiele zu nennen: in Vermittlungsplattformen wie AirBnB oder MyHammer, die an jedem zustandegekommenen Geschäft mitverdienen, ist die Anzahl zustandegekommener Vermittlungen entscheidend. Lieferdienste wie die von Picnic und Rewe haben dagegen ein Interesse an möglichst grossen Warenkörben, um die Logistikkosten gering zu halten. Und für Social Networks wie Instagram und Twitter ist entscheidend wie viele Nutzer täglich durch Likes oder Shares interagieren.

Dort, wo derartige Zahlen den Nordstern bilden, an dem sich alles ausrichtet, kann eine ganze Reihe von Vorteilen genutzt werden. Zunächst helfen sie bei Investitionsentscheidungen: wenn es darum geht, wo ein zur Verfügung stehendes Optimierungs-Budget am besten eingesetzt werden sollte, können z.B. alle Einheiten oder Systeme nachrangig behandelt werden, die diese zentralen Werte nicht beeinflussen können. Und bei denen die es können kann überlegt werden wo die grösste Wirkung möglich ist

Sie helfen offensichtlicherweise auch bei der Erfolgsmessung. Bei jedem der weiter oben genannten Beispiele kann jederzeit überprüft werden ob die Zahlen stabil bleiben, zunehmen oder abnehmen. Und dadurch, dass sie schnell (ggf. sogar in Echtzeit) erhebbar sind ist auch ein schnelles Inspect & Adapt möglich wenn sie sich nicht so entwickeln wie gewünscht oder geplant. Auch eine wirtschaftliche Betrachtung kann stattfinden, indem man prüft wieviel welche Verbesserung gekostet hat.

Zuletzt können North Star Metrics intern wesentlich dazu beitragen, dass die Mitarbeiter die Ausrichtung des eigenen Unternehmens verstehen und ihre eigene Tätigkeit darauf ausrichten. Vor allem dort wo mit autonomen und agilen Teams gearbeitet wird, ist es kaum noch möglich, zentral zu steuern, woran im Tagesgeschäft gearbeitet wird, mit Hilfe des über allem schwebenden Leitsterns können die Teams aber selbst erkennen wie zielführend ihre Arbeit gerade ist.

Wie dieser Ansatz im jeweiligen Einzelfall umgesetzt wird kann (und muss) je nach Fall unterschiedlich sein, da auch die jeweiligen Unternehmen und Produkte unterschiedlich sind. Eine naheliegende Variante ist aber die Kombination mit OKRs. Es gibt auch Versuche ein eigenständiges North Star Framework zu entwickeln, das aber noch in seinen Anfängen steckt und wenig verbreitet ist. Vielleicht entwickelt sich aber hier noch etwas. Man sollte es im Auge behalten.

The agile Bookshelf: The (Delicate) Art of Bureaucracy

Bild: Pexels / Vlada Karpovic - Lizenz

Wer mal wieder nach einem Geschenk für irgendeinen im Dunstkreis der Agilität arbeitenden Menschen sucht kann dieses Buch ins Auge fassen: The (Delicate) Art of Bureaucracy von Mark Schwartz bringt das Kunststück fertig das auf den ersten Einruck unspannenste aller Themen - die Bürokratie - so aufzubereiten, dass es nicht nur informativ sondern sogar unterhaltsam ist. Und zahlreiche Bezüge zu agiler Produktentwicklung und DevOps gibt es obendrauf.

Was Schwartz schon früh unmissverständlich festellt ist, dass die Bürokratie durchaus ihren Zweck hat. Spätestens bei Grossunternehmen und -behörden mit tausenden von Mitarbeitern ist es unumgänglich Rollen zu vergeben, Verantwortlichkeiten festzuleen, Abläufe zu definieren und Hierarchien aufzubauen. Würde das unterbleiben wären diese Organisationen (genau wie die meisten kleineren) von Anfang an nicht handlungsfähig.

Auch wie es zu der Entartung dieser eigentlich sinnvollen Strukturen in Regel- und Dienstweg-Fetischismus kommt beschreibt er anschaulich, u.a. am Beispiel von Scrum Teams, die um ihre Sprints zu schützen dafür sorgen, dass Stakeholder nur noch einmal alle zwei Wochen mit ihnen interagieren können, und auch das nur in einem stark formalisierten Meeting-Format, dem Sprint Review. Derartige "versehentliche Bürokratisierungen" sind zwar gut gemeint, in den Auswirkungen aber schädlich.

Neben dem Scrum Framework (mit dessen Klassifizierung als Bürokratie er bei den meisten Scrum Mastern einen mittelschweren Schock auslösen dürfte) konzentriert er sich aber in erster Linie auf das was auch im Allgemeinverständnis als Bürokratie verstanden wird: die Arbeitswirklichkeit in Grossorganisationen, und hier speziell in der amerikanischen Einwanderungsbehörde, deren CIO er für einige Jahre gewesen ist und gegen deren rigide Regeln und Prozesse er in dieser Zeit ankämpfte.

Die Hintergründe für diese Auseinandersetzung dürften jedem der Politik und IT kennt bekannt vorkommen: auf der anderen Seite ein stetiger, durch äussere Umstände verursachter Handlungsdruck, auf der anderen Seite der verständliche Wunsch nach Sicherheit und Berechenbarkeit, der aber schnell zu Überregulierung führte. Um dieser zu entkommen entwickelte Schwartz drei Ansätze, den des Affen, den des Rasierers und den des Sumo-Ringers.

Der "Weg des Affen" ist inspieriert vom Chaos Monkey aus dem Chaos Engineering, einem Computer-Programm das ununterbrochen andere Programme Belastungsproben aussetzt um so Schwachstellen zu finden. In Analogie dazu besteht das Ziel darin, in den bürokratischen Regelungen Ausnahmen oder Regulierungslücken zu finden in denen man sich freier bewegen kann. Dass das nicht nur gegen sondern auch zusammen mit den Regelhütern stattfinden kann ergibt sich für ihn aus dem nächsten Ansatz.

Der "Weg des Rasierers" ist abgeleitet von Hanlon's Razor, einem Erkenntnismodell das von dem Grundsatz ausgeht nicht mit Bosheit erklären zu wollen was sich auch damit erklären lässt, dass dem Urheber die Konsequenzen seines Tuns nicht bewusst waren. Die daraus abgeleitete Prämisse ist, dass die Verfasser und Überwacher strikter Regeln gar kein Interesse daran haben andere zu behindern, man also durchaus vertrauensvoll mit ihnen zusammenarbeiten kann.

Der "Weg des Sumo-Ringers" basiert schliesslich auf einer Grundtechnik asiatischer Kampfsportarten, die daraus besteht die kinetische Energie eines stärkeren Gegners gegen ihn selbst zu verwenden. Auf die Bürokratiebekämpfung kann das übertragen werden indem man die Regulierung bestimmter Bereiche explizit untersagt und das zum Gegenstand regelmässiger Überprüfungen macht. Die Bürokratie richtet sich so gegen sich selbst und dämmt sich selbst ein.

Alleine diese Inhalte würden das Buch bereits lesenswert machen, es gibt aber noch eine zweite Ebene wegen der sich der Kauf lohnt, die erzählerische. Schwartz ist sehr gut darin trockene Sachverhalte durch Anekdoten und Analogien unterhaltsam zu machen, ausserdem zieht sich ein Feuerwerk an Zitaten und Referenzen durch das ganze Buch, von Franz Kafka und Herrman Melville über Napoleon, Georg Hegel, Karl Marx, Max Weber, Frederick Taylor und Peter Drucker bis hin zu Jeff Sutherland.

Wer diese grossen Denker und ihre Werke kennt wird übrigens schon ahnen auf welchen von ihnen ganz am Anfang und ganz am Ende verwiesen wird: auf Kafka, der mit "Der Prozess" den Bürokratie-Roman schlechthin geschrieben hat. Mark Schwartz hätte sich keine bessere Klammer für seine Ausführungen suchen können.

Langfristige Retrospektiven

Bild: Wikemedia Commons / Louis Moeller - Public Domain

Es ist eines der grossen Verdienste der agilen Frameworks (und im Besonderen von Scrum), dass sie mit den Retrospektiven einen regelmässig stattfindenden Rückblick-Termin auf die unmittelbar zurückliegende Vergangenheit etabliert haben. Erst durch sie wird Agilität im Sinn eines kontinuierlichen Inspect & Adapt möglich. Was in diesem Arbeitsmodus dagegen seltener stattfindet sind langfristigere Rückblicke. Schade eigentlich, denn langfristige Retrospektiven können in vielen Kontexten von Mehrwert sein. Hier sind einige von ihnen:

Zum Jahresende

Dieser Rhythmus macht vor allem da Sinn wo noch mit Jahresplanungen gearbeitet wird, deren Ergebnisse man gemeinsam unter die Lupe nehmen kann. Auch dort wo das nicht der Fall ist bietet es sich aber an, schliesslich ist der Jahreswechsel mit seinen Feiertagen eine Zäsur die sich für einen gemeinsamen Blick zurück anbietet. Im Normalfall sorgen diese Feiertage auch dafür, dass solche Retrospektiven nicht genau am Jahresende stattfinden sondern eher Mitte Dezember.

(Ungefähr) Halbjährlich

Der nächstkürzere Zeitraum, und direkt einer der etwas Anpassung und Erklärung benötigt. Auch im Sommer gibt es mit den Sommerferien, in denen die meisten Menschen in den Urlaub fahren, eine grosse Zäsur - allerdings liegen diese in der Regel bereits im dritten Quartal. In Kombination mit dem de facto-Ende des Arbeitsjahres vor Weihnachten ergibt sich so ein längerer Retrospektiv-Zeitraum im ersten Halbjahr und ein kürzerer im zweiten.

Quartalsweise

Nicht nur der wiederum nächstkürzere Zeitraum, sondern auch einer der sich (halboffiziell) in zwei agilen Frameworks wiederfindet. In den meisten Implementierungen des Scaled Agile Framework (SAFe) sind die mehrere Sprints umfassenden Pogramm Incremente drei Monate lang, genau wie die Zyklen in denen in der Regel mit Objectives and Key Results (OKRs) gearbeitet wird. Quartals-Retrospektiven können aber natürlich auch Framework-unabhängig sein.

Nach Ende eines (Teil-)Projekts

Die vermutlich älteste Variante langfristiger Retrospektiven, denn es handelt sich hier im Grunde um nichts anderes als um das im klassischen Projektmanagement schon seit langem übliche so genannte "Post Mortem". Aus diesem Namen ergibt sich auch das grösste Problem dieses Vorgehens: Erkenntnisse werden erst generiert wenn alles vorbei ist, womit eine Optimierung des laufenden Vorhabens nicht mehr möglich ist. Stattdessen lernt man hier für zukünftige Vorhaben.

Nach einem Go Live

Egal ob in der Produkt- oder in der Organisationsentwicklung, viele Unternehmen scheuen sich (aus guten und schlechten Gründen) davor regelmässige Veränderungen an einem laufenden System vorzunehmen. Verkaufsbeginne oder Umstrukturierungen finden dort erst statt wenn sich eine relevante oder kritische Menge angesammelt hat. Die dafür nötige Zeit kann immer wieder anders sein, weshalb es für solche Retrospektiven keinen festen Rhythmus gibt.

Zeitlich versetzt nach einem Go Live

Ähnlich, aber nicht ganz das gleiche. Der entscheidende Unterschied dieser Variante ist, dass auf etwas anderes zurückgeblickt wird. Im zuvor genannten Fall steht der Erstellungs-Zeitraum im Focus des Rückblicks, in diesem Fall sind es Erfolg und Akzeptanz der Ergebnisse bei Kunden und anderen Betroffenen. Es kann daher Sinn machen auch Vertreter dieser Gruppen einzuladen, falls mit Onsite Customern gearbeitet wurde ist das sogar sehr naheliegend.

Nach Übergabe eines Liefergegenstandes

Vor allem in Grossprojekten kommt es vor, dass Gewerke, Teilumfänge oder andere Arten von Liefergegenständen separat ausgeschrieben werden. Da diese Ausschreibungen während der gesamten Projektlaufzeit immer wieder stattfinden und in der Regel auch die selben Bieter an ihnen teilnehmen kann es hilfreich sein nach Übergabe eines Liefergegenstandes gemeinsam zu überlegen wie die Ausschreibung und Erbringung des nächsten Leistungspakets verbessert werden könnten.

Bei Bedarf

Anlässe für bedarfsgetriebene Retrospektiven gibt es viele, vom schlechter werdenden Betriebsklima über das Aufstauen technischer Schulden bis zu nachlassendem Erfolg am Markt. Erscheint einer von ihnen wichtig genug kann eine Retrospektive bei der Ursachenanalyse und Verbesserungsmassnahmen helfen. Ähnlich wie bei den Jenga-getriebenen Retrospektiven kann es auch Sinn machen zu warten bis genug Themen zusammengekommen sind, wenn die einzelnen für sich genommen zu unwichtig sind.

---

Natürlich ist diese Aufzählung nicht abschliessend, im Zweifel werden sich noch viele andere Möglichkeiten finden langfristige Retrospektiven zu planen und durchzuführen. Wichtig ist dabei vor allem, dass überhaupt Überlegungen dazu stattfinden ob und wenn ja auf welche Weise sie stattfinden sollten. Sobald sie erstmal etabliert sind kann man sie schliesslich so lange bedarfsgerecht anpassen bis sie ihren Zweck erfüllen. Mit kontinuierlichem Inspect & Adapt, wie eben in Retrospektiven üblich.

Die Gemeinsamkeiten von Softwareentwicklung und Politik

Bilder: Flickr / OSCEPA - CC BY-SA 2.0 + Pexels / Christina Morillo - Lizenz

Dass die Berufe des (agilen) Softwareentwicklers und des Politikers mehr Verbindendes haben als man auf den ersten Blick denken sollte hatte ich am Beispiel des "agilen Redens" schon einmal erwähnt, die Parallelen gehen aber weit über derartige Einzel-Aspekte hinaus. Sobald man diese beiden Tätigkeiten abstrahiert betrachtet zeigen sich grosse Gemeinsamkeiten in Herausforderungen, Rahmenbedingungen und Lösungsansätzen - sogar so grosse, dass der eine Beruf eine Analogie des anderen sein kann.

Zunächst finden beide in einem Umfeld statt das bestenfalls komplex und oft genug sogar chaotisch ist. In beiden Fällen müssen Systeme verändert werden die hochgradig unübersichtlich, vernetzt und durch schwer vorhersehbare Dynamiken geprägt sind, was in beiden Fällen dazu führt, dass die Folgen der eigenen Handlungen nur eingeschränkt absehbar sind. Um sicherzugehen, dass die eigenen Ziele erreicht werden ist daher eine kontinuierliche Validierung und Anpassung des Vorgehens nötig.

Sowohl die Politik als auch die Softwareentwicklung erfordern weitgehende Spezialisierungen, z.B. in Wirtschafts-, Innen- und Finanzpolitik oder in Frontend-, Backend- und Middleware-Entwicklung. Zwar gibt es Idealvorstellungen wie den in allen Fachgebieten bewanderten Politiker oder den Fullstack-Developer, in der Realität sind es aber praktisch immer Teams von mehr oder weniger ausgeprägten Spezialisten, die nur gemeinsam Ergebnisse liefern können.

Darüber hinaus haben beide Berufe ein Problem mit Legacy Code. Sowohl der Quelltext (englisch Source Code) in der IT als auch die Gesetzestexte (englisch: Law Code) in der Politik sind in einer z.T. weit zurückligenden Vergangenheit von Personen geschrieben worden die sich mittlerweile in Rente befinden oder den Job gewechselt haben. Sowohl die ursprüngliche Intention als auch die Lesbarkeit, die Ausführung oder die Verknüpfung zu anderen Code-Stellen sind häufig eine Herausforderung.

Die vielleicht grösste Gemeinsamkeit der beiden Berufswelten ergibt sich aber in ihrer Aussenwahrnehmeng. Beide werden kontinuierlich umlagert von einer Vielzahl an unterschiedlichsten Interessenvertretern, die mit nicht nachlassender Vehemenz darauf bestehen, dass ihr jeweils aktuelles Problem das wichtigste von allen wäre und sofort gelöst werden müsste. Und bekommen sie nicht ihren Willen sind sie im Zweifel schnell bereit zur Eskalation.

In meinen fünf Jahren in der politischen Verwaltung und meinen über 10 Jahren in der Softwareentwicklung ist mir im Rahmen dieser regelmässig stattfindenden Eskalationen eine weitere Übereinstimmung immer wieder aufgefallen: wenn Interessenvertreter ihre Wünsche nicht sofort erfüllt bekommen neigen viele dazu, den Grund dafür in einer Unfähigkeit des anderen zu sehen - "die Politik" oder "die IT" werden dann beschuldigt ihren Job nicht machen zu können oder zu wollen.

An dieser Stelle ist es dann Zeit für die finale Pointe: sobald Politiker (als Auftraggeber) ein Anliegen an eine Softwareentwicklungs-Abteilung haben oder Softwareentwickler (als Wähler) Wünsche an eine politische Institution, werden sie regelmässig selbst zu den ungeduldigen Interessenvertretern, die der jeweils anderen Seite Unvermögen unterstellen. Vermutlich würde es beiden Berufsgruppen sehr helfen ihre Gemeinsamkeiten wahrzunehmen um hier eine entspanntere Sicht zu entwickeln.

Speed trumps perfection

Eigentlich hätte ich ja gehofft, dass das Covid19-Virus zwei Jahre nach seinem Auftreten nicht mehr als aktuelles Beispiel dafür herhalten muss wie man mit einer unberechenbaren und riskanten Situation umgeht, aber naja - hier sind wir nun einmal. Dementsprechend hat dieses Video von Mike Ryan, dem Executive Director des WHO Health Emergencies Programm, nichts von seiner Aktualität eingebüsst.

Die von ihm genannten Punkte sind von ihm zwar aus der Perspektive der Pandemiebekämpfung vorgebracht, treffen aber auch auf andere komplexe Change-Vorhaben zu: man muss aus der Vergangenheit lernen, versuchen so gut wie es geht vorbereitet zu sein, in der Lage sein schnell zu reagieren (auch um den Preis sich manchmal zu irren), man muss Systemzusammenhänge erkennen können und die von den Massnahmen Betroffenen möglichst früh mit einbeziehen.

Hanlon's Razor, Stein's Razor und die Prime Directive

Bild: Wikimedia Commons / Frank Schulenburg - CC BY-SA 3.0

Selbst wenn sich nicht mehr genau rekonstruieren lässt ob sich das Sprichwort "Hanlon's Razor" auf Robert J. Hanlon oder (versehentlich falsch geschrieben) auf Robert A. Heinlein zurückzuführen ist (siehe Wikipedia für mehr Details), es hat mittlerweile eine weite Verbreitung erreicht und wird immer wieder zitiert wenn Streit darüber entsteht warum etwas schiefgelaufen ist. Für alle die es nicht kennen sind hier sein Hintergrund, seine gute Seite, seine Problematik und eine bessere Alternative.

Zunächst zum Namen. Als "Razor" (Rasiermesser) kann im Englischen ein Vorgehensmodell des Erkenntnisgewinns bezeichnet werden, bei dem man überflüssige oder verwirrende Elemente von einer Überlegung "abrasiert". Das was danach übrigbleibt soll klarer und verständlicher sein als der Ausgangszustand. Der Bekannteste ist vermutlich Occam's Razor ("The simplest explanation is usually the best one."), der zweitbekannteste der nach Hanlon oder Heinlein benannte, um den es hier geht.

Never attribute to malice that which can be adequately explained by stupidity.

Hanlon's Razor

Ins Deutsche übersetzt: "Erkläre nicht mit Bosheit was sich auch mit Dummheit erklären liesse." Das klingt zunächst eher passiv-agressiv, hat aber bei näherer Betrachtung einen fast schon humanistischen Hintergrund - statt dem Verursacher eines Fehlers oder Schadens niedere Beweggründe zu unterstellen wird davon ausgegangen, dass er die Konsequenzen seines Handelns einfach nicht überblicken konnte und sie nur darum nicht unterlassen hat.

Das Schwierige an dieser Betrachtungsweise ist allerdings, dass der Betrachtete doch wieder herabgesetzt wird, nur auf eine andere Art. Er wird zwar nicht mehr als bösartig bezeichnet, dafür aber als geistig minderbemittelt, worin implizit mitschwingt, dass jeder durchschnittlich intelligente Mensch sich anders verhalten hätte. Das ist zum einen eine sehr anmassende Haltung, zum anderen hat es aber auch Folgen die den Folgen der Zuschreibung von Bösartigkeit sehr ähnlich sind.

Beide Erklärungsansätze führen dazu, dass im Nachgang eines Fehlers oder Schadens eher nach Schuldigen als nach Lösungen gesucht werden wird. Dass das geschieht ergibt sich zwingend daraus, dass in beiden Fällen das Problem in der geistigen Verfassung des Verursachers gesehen wird. Dieser Logik folgend muss man nur alle als böse oder dumm wahrgenommenen Menschen aus Entscheidungspositionen entfernen um zu verhindern, dass der Vorgang sich wiederholt.

Die Realität ist aber meistens vielschichtiger. In einer komplexen Umgebung liegen so viele verschiedene Faktoren vor (die sich dazu auch noch gegenseitig beeinflussen), dass es kaum möglich ist sie alle im Blick zu behalten. Und selbst dann wenn das noch irgendwie möglich wäre wird das in der Regel dadurch erschwert, dass zeitgleich andere, ähnlich komplexe Sachverhalte ebenfalls beobachtet werden müssten um sicherzugehen, dass nicht dort gerade etwas aus dem Ruder läuft.

Die Erkenntnis, dass derartige Zusammenhänge nicht vollständig beherrschbar sind hat in den agilen Frameworks dazu geführt, dass versucht wird die Aufarbeitung von Zwischenfällen möglichst ohne Schuldzuweisungen durchzuführen (man spricht hier von "Blame-free Retrospectives"). Bekannt geworden ist in diesem Zusammenhang die sogenannte "Prime Directive", also die oberste Verhaltensregel die in derartigen Situationen zu beachten ist:

Regardless of what we discover, we must understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.

the Prime Directive

Und damit kommen wir zum kreativen Teil. Abgeleitet von der obersten Verhaltensregel für agile Retrospektiven ist es möglich Hanlon's Razor so umzuformulieren, dass er nicht mehr dazu führt einen Schuldigen zu suchen sondern stattdessen die Unbeherrschbarkeit einer komplexen Welt anerkennt. Das soll jetzt passieren. Und da das Ergebnis einen neuen Namen braucht möchte ich für einen Moment unbescheiden sein und es nach mir benennen. Hier ist "Stein's Razor":

Erkläre nichts durch Bosheit oder Dummheit was auch durch fehlende Informationen oder gestörte Konzentration erklärbar ist.

Stein's Razor

Ob sich dieser Name durchsetzt und mich berühmt werden lässt wird sich zeigen, aber unabhängig von der Benennung lege ich diese Richtlinie allen ans Herz die an der Aufarbeitung von Fehlern oder Schadensfällen beteiligt sind. Sie zu befolgen führt in der Regel zu konstruktiveren Diskussionen, lösungsfokussierteren Verbesserungsprozessen und bereitwilligerer Beteiligung, also zu eigentlich allem was in solchen Situationen nötig und wünschenswert ist.

Kommentierte Links (LXXXI)

Grafik: Pixabay / The Digital Artist - 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.

Jeff Gothelf: Why does planning require a “season"?

Aus einem neuen Blickwinkel betrachtet kann sich die Absurdität scheinbar normaler Vorgänge offenbaren. Der den Jeff Gothelf hier einnimmt ist so einer, verbunden mit einem schönen neuen Begriff: der "Planungs-Saison". Die dahinter liegende Idee ist es, aufzuzeigen, dass es für Planungen (ähnlich wie für Erdbeeren, Ski-Urlaub oder Monsun-Stürme) eine bestimmte Jahreszeit gibt in der sie besonders häufig auftreten. Es sind die Wochen vor Weihnachten, in denen intensiv an Budgets, Feature-Wunschlisten, Zieldaten und ähnlichen Planungselementen gearbeitet wird. Während aber die anderen Saisons nachvollziehbare und kaum änderbare Ursachen in der Biologie, den Schulferien und der Metereologie haben ist die Entscheidung eine Planungs-Saison durchzuführen keineswegs zwangsläufig. Wäre nicht eine kontinuierliche Aktualisierung der Planungen viel sinnvoller für eine Welt in stetiger Bewegung?

Brian Milner: The Product Owner’s Second Team

Apropos neuer Blickwinkel: das was Brian Milner hier gelingt ist einer der seltenen neuen Blicke auf Scrum. Was er dabei entdeckt ist etwas was sich zwar aus dem offiziellen Regelwerk nicht ablesen lässt, was aber in der Realität häufig vorkommt und bei konsequenter Anwendung agiler Prinzipien extrem naheliegend ist - ein zweites Team in dem der Product Owner Mitglied ist, das Stakeholder-Team. Die Idee dahinter ist, dass die Stakeholder eines Scrum Teams ein gemeinsames Interesse haben (die Weiterentwicklung des gemeinsamen Produkts), einen gemeinsamen Ansprechpartner für dieses Interesse (den Product Owner) und einen gemeinsamen Arbeitszyklus, an dessen Ende ein gemeinsames Meeting steht (den Sprint, bzw. das Sprint Review). Das sind deutlich mehr Gemeinsamkeiten als viele andere Organisationseinheiten haben die sich Team nennen.

Stefan Kühl: Selbstorganisation – Von den hierarchischen Grenzen eines verklärten Konzeptes

Das hier ist der etwas verquere Fall eines Artikels der irgendwie sein Thema verfehlt aber trotzdem interessant und erkenntnisreich ist. Was Stefan Kühl hier beschreibt ist Delegation von oben nach unten unter Vorbehalt. Mit anderen Worten: ein Vorgesetzter erlaubt es seinen Untergebenen über bestimmte Sachverhalte selbstorganisiert zu entscheiden, aber nur so lange bis er einen guten Grund hat diese Kompetenz wieder an sich zu ziehen. Der durchschlagendste dieser Gründe liegt dann vor, wenn er fürchten muss für die ausbleibenden oder nicht erwartungsgemässen Ergebnisse zur Verantwortung gezogen zu werden - sein Micro-Management erfolgt dann aus versuchtem Selbstschutz. Das alles ist hier anschaulich und eloquent beschrieben, allerdings mit einem etwas schrägen Twist. Der Vorgesetzte wird zu einem Teil der sich selbstorganisierenden Organisationseinheit erklärt, die damit auch im Fall des hierarchischen Durchgriffs als selbstorganisiert gilt. Nun ja. Wie Kühl selbst scheibt: jede und jeder kann Worte so bestimmen, wie sie oder er es möchte.

Bill Wake: Backroom/Frontroom to Smooth Releases

Eine nützliche Analogie die ich noch nicht kannte. Bill Wake vergleicht die Prozesse der Produktentwicklung mit denen in einem Restaurant. In ihm gibt es den vorderen Bereich, in dem Speisen und Getränke bestellt, aufgetischt, konsumiert und bezahlt werden und den hinteren Bereich in dem die Lagerung der Zutaten und ihre Zubereitung erfolgt. Das Besondere an diesem Vergleich ist, dass das Auftragen und Konsumieren im Vorderbereich in einer signifikant anderen Reihenfolge stattfinden kann als die Zubereitung im Hinterbereich. Je nach Bestellung muss die Zubereitungsreihenfolge sogar von der Konsumreihenfolge abweichen damit alles zum richtigen Zeitpunkt fertig ist. Wer seine Produkte ohne ein ständig wachsendes und Kapital bindendes Zwischenlager noch nicht benutzbarer Teilergebnisse erstellen möchte, der sollte sich an den Küchen ein Beispiel nehmen und seine Planung an der Integration der Einzelteile ausrichten statt am Auftragseingang.

Clive Thompson: 13 Ways Of Looking at a Post-It Note

Selbst die immer populärer werdende Heimarbeit hat nichts daran ändern können, dass der Post-It-Zettel die ikonische Manifestation agiler und leaner Arbeitsweisen ist. Sogar viele der gängigen Tools wie Miro oder Jira versuchen mit unterschiedlichem Erfolg sich an seine Funktionsweise anzulehnen. Clive Thompsons zählt einige Gründe dafür auf wie es zu diesem Status gekommen ist.

Resource Utilization Trap

Dieses Video zeige ich seit Jahren immer wieder in Workshops oder verschicke es an Kunden von denen ich glaube, dass sie etwas zu sehr der Idee anhängen, dass sie ihre Mitarbeiter möglichst voll auslasten müssten. Für alle die keine Lust auf längere Texte haben ist es eine gute Möglichkeit um herauszufinden welche negativen Folgen eine Auslastungsfixierung haben kann.

Auf einer zweiten Ebene zeigt sich hier sehr schön, dass man für wirkungsvolle Lehrvideos weder ein grosses Budget noch professionelle Schauspieler oder eine grosse Bearbeitungs-Talent braucht. Wenn die Botschaft sehr klar und einleuchtend ist (so wie in diesem Fall) kommt man schon mit geringen Mitteln sehr weit.

Der Vorteil von SAFe (II)

Dass das Scaled Agile Framework (SAFe) in der agilen Community eher kritisch gesehen wird dürfte sich mittlerweile herumgesprochen haben. Es zu bashen gehört mittlerweile fast schon zum guten Ton, was dazu führt, dass es leider nur noch sehr einseitig betrachtet wird. Man kann ihm nämlich auch positive Aspekte abgewinnen, darunter einen der auf den ersten Blick überraschend wirkt - SAFe ist einfach zu erklären und zu verstehen.

Überraschend ist das deshalb weil in der öffentlichen Wahrnehmung vor allem das grosse Wimmelbild auf der Startseite von scaledagileframework.com bekannt geworden ist. Das als Grundlage einer einfachen Erklärung zu nutzen wäre tatsächlich eine Herausforderung. Was dabei allerdings oft übersehen wird ist, dass diese Übersicht stark mit Elementen überladen ist die optional sind oder bei denen es sich um Implementierungsdetails handelt. Um SAFe zu verstehen braucht man nur wenige.

Fangen wir oben an, bei einem Teil der zentral ist und in keiner Umsetzungen vernachlässigt werden sollte: dem Portfolio Kanban. Sein Design kann sich zwar je nach Fall unterscheiden, wichtig ist aber, dass hier die grossen Arbeitspakete (Epics) der zur Zeit umgesetzten Initiativen von links nach rechts wandern. Idealerweise wird diese Übersicht genutzt um zu verhindern, dass zu viele gleichzeitig begonnen werden, so dass mehr Focus und weniger Multitasking entstehen.

Bei der Organisation der Umsetzung tritt eine zentrale Annahme von SAFe in den Vordergrund: die, dass es einzelnen Team in kurzen Zeiträumen nicht möglich ist Arbeitspakete von relevantem Wert abzuschliessen. Aus diesem Grund wird eine doppelte Gruppierung vorgenommen - jeweils mehrere Teams arbeiten über mehrere aufeinanderfolgende Kurz-Zeiträume an einem solchen Arbeitspaket. Der Name einer solchen Gruppierung ist Release Train, die Zeitspanne nennt sich Program Increment (PI).

Damit die Teams eines Release Trains nicht nur gemeinsame Umsetzungszeiträume haben sondern auch an zusammengehörigen Themen arbeiten (und dabei die untereinander bestehenden Abhängigkeiten berücksichtigen) findet zu Beginn jedes Program Increments eine gemeinsame Planung statt, das PI Planning, bzw. Big Room Planning. Ggf. können begleitend dazu auch Retrospektiven stattfinden, entweder davor (für das letzte PI) oder danach (für das PI Planning selbst).

In der Theorie arbeiten die einzelnen Teams zwischen zwei PI Plannings nach Scrum (in mehreren Sprints), de facto ist dieser Arbeitsmodus aber stark beschnitten, da die Integration in einen Release Train dafür sorgt, dass die eigentlich vorgesehene Team-Autonomie nur noch eingeschränkt möglich ist. Vor allem die Kompetenzen des Product Owners und Scrum Masters werden zum Teil auf entsprechende Koordinationsrollen im Release Train übertragen, den Product Manager und den Release Train Engineer.

Und das ist sie auch schon, die einfache Erklärung von SAFe in nur vier Absätzen. Wendet man diesen Erklärungsansatz an hat das zwei Vorteile: zum Ersten den, dass erkennbar wird, dass sich hinter dem unübersichtlichen offiziellen Übersichtsbild eigentlich nur ein relativ einfacher Skalierungsansatz verbirgt. Hat man den erfasst wird es auch einfacher zu beurteilen welche der zahlreichen anderen Elemente man nutzen will und welche nicht.

Zum anderen kann man die zentrale Annahme von SAFe herausstreichen: die, dass es einzelnen Team in kurzen Zeiträumen nicht möglich ist Arbeitspakete von relevantem Wert abzuschliessen, weshalb sie in Release Trains und Program Incrementen zusammengekoppelt werden. Und an dieser Stelle wird diese einfache Erklärung auch für die SAFe-Skeptiker interessant - wenn sie belegen können, dass die Teams dazu doch in der Lage sind, entfällt die Notwendigkeit SAFe einzuführen.

Umgekehrt betrachtet: dort wo einzelne Teams nicht in der Lage sind in einzelnen Sprints Mehrwert abzuliefern ist SAFe zumindest eine Option. Ob es die richtige ist muss sich im Vergleich mit anderen Skalierungsframeworks klären, deren Befürworter dann in der Lage sein sollten sie ähnlich einfach zu erklären wie das bei SAFe möglich ist.

Welches Kanban darfs denn sein?

Bild: Flickr / Paul Downey - CC BY 2.0

"Wir machen Kanban" ist eine Aussage die man mittlerweile von sehr vielen Teams hören kann. Schaut man sich einzelne davon näher an lassen sich allerdings grosse Unterschiede erkennen, zum Teil sogar so grosse, dass praktisch keine Vergleichbarkeit mehr gegeben ist. Das hat mit dem Fehlen eines offiziellen Regelwerks zu tun (sorry, Kanban University), mit Missverständnissen und mit Cargo Cult, selbst wenn man das in Betracht zieht bleibt aber noch eine erstaunliche Vielfalt übrig. Der Grund dafür - es gibt mehrere Varianten von Kanban, die sich z.T. deutlich unterscheiden:

Irgendetwas Sichtbares

Da Japanisch und Deutsch sich stark unterscheiden ist eine wörtliche Übersetzung schwierig, je nach Auslegung lautet sie aber "visuelles Signal", "sichtbare Information" oder etwas Vergleichbares. Damit können zum Beispiel die farbigen Signallampen an Fabrikstrassen oder an Warteschlangen als Kanban bezeichnet werden (was aber fast ausschliesslich japanische Muttersprachler tun). Zur Abgrenzung: nicht in diese Kategorie fallen Zahlen, Buchstaben und Diagramme, für die es eigene Bezeichnungen gibt.

Irgendetwas mit Karten oder Post-Its

Ein spezifischerer Übersetzungs-Versuch ist Signal-Karte oder Informations-Karte (Kan = Sichtbare Information, Ban = Karte oder Post-It). Das ist enger gefasst als die wörtliche Übersetzung, umfasst aber noch immer recht viel, neben den verbreiteten Boards oder Wänden auf denen Post-Its hin und her geschoben werden z.B. auch Kamishibai-Visualisierungen, Planning Poker-Karten und ggf. sogar aus Papierzetteln erstellte Kunstwerke.

Durchfluss-Visualisierungen

Die vermutlich am weitesten verbreitete Definition. In ihr wird unter einem Kanban-System oder Kanban-Board eine Darstellung aufeinanderfolgender Arbeitsschritte verstanden, die von den einzelnen Arbeitspaketen durchlaufen werden (hier ein Beispiel). Dargestellt werden diese Pakete durch Post-Its (physisch) oder Kacheln (digital). Auch hier gibt es eine Abgrenzung: werden keine Arbeitsschritte abgebildet sondern To do, Doing und Done ist es ein Task Board, kein Kanban-Board.

Erweiterte Durchfluss-Visualisierungen

Hier beginnt es für die Tool- und Methoden-Nerds interessant zu werden. Häufige visuelle Elemente in erweiterten Kanban-Systemen sind Work in Progress-Limits (sowohl für die Unter- als auch für die Obergrenzen), Zähl-Punkte für die Messung von Lead Time und Cycle Time und "Parkplätze" für blockierte oder wartende Arbeit, es gibt aber noch zahllose weitere. Für viele "Überzeugungstäter" darf sich nur Kanban nennen was solche Erweiterungen enthält.

Eine Change Management-Methodik

Die vermutlich engste Definition von allen. In ihr hat sich Kanban weitgehend von seinen Ursprüngen in der Visualisierung, bzw. Informations-Übermittlung gelöst und ist zu einer Methode des Change Managements geworden. Die Darstellung eines Arbeitsflusses durch aufeinanderfolgende Arbeitsschritte ist nur noch ein Mittel zum Zweck, und der ist die kontinuierliche und behutsame Optimierung und Effizienzzsteigerung des Gesamtsystems.

Grober Unfug

Wie oben erwähnt, Cargo Cult gibt es überall, also auch hier. Eine seiner häufigsten Manifestationen ist der Glaube Kanban wäre "Scrum mit weniger Meetings" (mitunter auch "Scrum ohne Sprints" oder "Scrum ohne Rollen"). Dahinter steckt meistens guter Wille, falsch ist es aber trotzdem (und auch die Wortschöpfung "Scrumban" macht es nicht besser). Das heisst nicht, dass man das nicht machen könnte, es hat dann aber mit Kanban ähnlich wenig zu tun wie mit Scrum.

Und noch mehr ...

Bei weiterem Suchen würde man mit Sicherheit noch weitere Varianten von Kanban finden, gute, schlechte und viele die irgendwo in der Mitte sind. Wichtig ist es dabei sich über die jeweiligen Unterschiede im Klaren zu sein, denn eines ist angesichts dieser Vielfalt sicher: "Wir machen Kanban" ist zu wenig Information um zu erkennen was genau da gemacht wird.

Story Points sind Schweine

Bild: Wikimedia Commons / Nela König /Hot Action Records - CC BY-SA 3.0

Eine Anekdote aus der Musik: einer der grössten Hits der legendären Band Die Ärzte trägt den schönen Namen Männer sind Schweine. Das Besondere an ihm ist, dass die Ärzte bereits kurz nach seiner Veröffentlichung 1998 aufhörten ihn aufzuführen - seine Beliebtheit auf Volksfesten, Schlager- und Ballermann-Partys führte dazu, dass sie als Punk-Gruppe mit diesem Umfeld nicht in Verbindung gebracht werden wollten. Sie verstiessen daher dieses "kontaminierte" Lied aus ihrem Repertoire.

Die Tragweite dieser Entscheidung wird klar wenn man sich vor Augen hält, dass "Männer sind Schweine" bis heute das komerziell erfolgreichte und (über alle Bevölkerungsgruppen hinweg) vermutlich auch bekannteste Werk der Ärzte ist. Das nicht mehr aufführen zu wollen ist ein bemerkenswertes Statement und lässt Rückschlüsse darauf zu, wie stark ihre Abscheu vor der Schlager- und Ballermann-Szene sein muss und was sie bereit waren zu opfern um zu ihr auf Abstand zu bleiben.

Um die Anekdote zu beenden und wieder zum Hauptthema dieser Seite zurückzukommen: vergleichbare Abstossungs-Vorgänge wie den gerade beschriebenen gibt es auch im Umfeld der agilen Frameworks. Auch hier gibt es extrem populäre Konzepte die wegen ihrer Beliebtheit bei einer als unpassend empfundenen Zielgruppe von vielen kaum noch genutzt werden. Und wer die Geschichte der "agilen Bewegung" kennt wird die "unpassende Zielgruppe" ahnen - es ist das Management.

Das vielleicht bekannteste (weil verbreitetste) Beispiel dafür sind die aus dem Extreme Programming stammenden Story Points. Selbst ihr (Mit-)Erfinder Ron Jeffries bedauert mittlerweile sie erfunden zu haben, auch von anderen bekannten Agilisten wie z.B.  Allen Holub, Troy Magennis und Joshua Kerievski werden sie kritisch gesehen. Der Grund dafür ist die Gewohnheit vieler Manager (v.a. im SAFe-Kontext) sie zu normieren, vorzuschreiben und als Grundlage für langfristige Detailplanung zu benutzen.

Ein weiteres ist das so genannte Spotify Model, ein bei der gleichnamigen schwedischen Firma entwickelter Skalierungsansatz. Auch hier hat mit Joakim Sundén einer der Erfinder mittlerweile eine eher kritische Einstellung, genau wie andere bekannte agile Practitioner, z.B. Ben Linders und Willem-Jan Ageling. Und auch hier ist die Ursache für die Ablehnung eine Begeisterung bei "den falschen Menschen", in diesem Fall Managern die den Ansatz unreflektiert als Blaupause benutzen wollen.

Neben diesen weit verbreiteten gibt es zusätzlich zahllose weitere eher lokale Beispiele dafür, dass agile Teams und Enthusiasten von bestimmten Frameworks und Praktiken abwenden weil sie "den falschen Menschen" in die Hände gefallen sind. Abstossungen die ich in verschiedenen Firmen gesehen habe betrafen unter anderem Burndown Charts, Scrum, Kanban, OKRs, Communities of Practice, Definition of Done, Definition of Ready und sogar die Begriffe Agile und Lean.

Auf einen ersten Blick kann ein solches Aufgeben "kontaminierter" Begriffe und Konzepte Sinn ergeben. Man erspart sich Konflikte und Prozessdiskussionen und kann das was man eigentlich erreichen will stattdessen unter einem anderen anderen Namen unverändert vorantreiben (z.B. DevOps statt Agile oder T-Shirt Size statt Story Points). Das Ausweichen in derartige Fluchtvarianten ist damit ein scheinbar bequemer Ausweg.

Auf den zweiten Blick werden allerdings Probleme sichtbar. Da die aufgegebenen Begriffe und Konzepte nicht verschwinden sondern von den "falschen Menschen" weiterhin verwandt werden kann es zu Auseinandersetzungen zwischen den Befürwortern verschiedener Ansätze kommen. Und das möglicherweise sogar wiederholte Ausweichen auf andere Benennungen kann zur so genannten "Euphemismus-Tretmühle" führen (mehr dazu hier).

Wesentlich zielführender ist es, den Konflikt anzunehmen und auf zivilisierte Weise auszutragen. Ein erster Schritt kann dabei sein zu erkennen, dass es gar keine "falschen Menschen" gibt sondern auch diese im Regelfall guten Intentionen und rationalen Erwägungen folgen. Auf dieser Basis herauszuarbeiten, dass die "Originalversionen" der agilen Frameworks eher zum Ziel führen als Blaupausen und Abkürzungen kann anstrengend sein, im Zweifel ist es aber der nachhaltigere Weg.

Selbst wenn das Ausweichverhalten stattgefunden hat ist ein Umsteuern noch möglich. Da die Deutungshoheit über die agilen Begriffe und Buzzwords mittlerweile ausserhalb der Unternehmen und Unternehmensberatungen liegt lässt sich eine missverstandene oder verdrehte Bedeutung auf Dauer kaum aufrechterhalten und kann korrigiert werden. Und auch dafür, dass es dafür nie zu spät ist sind die Ärzte ein gutes Beispiel: nach mehr als 10 Jahren Pause wird Männer sind Schweine mittlerweile wieder von ihnen gespielt.

10 Jahre #NoEstimates (I)

Bild: Pixabay / Geralt - Lizenz

Die vermutlich kontroverseste unter den agilen Bewegungen hat Geburtstag: #NoEstimates (übersetzbar mit #KeineAufwandsschätzungen) wird 10 Jahre alt. Ein Jahrzehnt nach ihrer Gründung ist sie noch immer weit davon entfernt im Mainstream angekommen zu sein und wird das vermutlich auch in absehbarer Zeit nicht. Trotzdem hat sie leidenschaftliche Anhänger, so dass davon auszugehen ist, dass sie in ihrer Nische noch lange weiterbestehen wird.

Um diese Bewegung besser zu verstehen muss man sich eines bewusst machen: trotz ihres Namens wendet sie sich nicht explizit gegen Aufwandsschätzungen, lediglich gegen solche in Vorhaben die so sich so unvorhersehbar entwickeln, dass es sich nicht mehr um Schätzungen sondern um wildes Herumraten handelt. Woody Zuill, der Schöpfer von #Noestimates bezeichnete das im November 2011 in seinem ersten Artikel zu diesem Thema als "Wild Ass Guessing" (WAG), was inhaltlich deckungsgleich ist.

Um das plastischer zu machen: es gibt tatsächlich Vorhaben in denen derartige Rahmenbedingungen vorliegen, dass realistische Schätzungen nahezu unmöglich sind. Ein Beispiel wäre die Entwicklung eines neuartigen Online-Produkts bei dem nur die intensiv genutzten neuen Features weiterentwickelt, die weniger genutzten aber ausgebaut werden. Ein anderes, später von Zuill selbst erwähntes wäre die Reparatur eines uralten Systems mit hunderten von Bugs.

Jeder Versuch diese oder ähnliche Projekte mit Aufwandsschätzungen zu versehen würde lediglich in einem Haufen Datenmüll enden, da die Wissensgrundlage auf der die Aufwandsschätzungen stattfinden ständig wegbricht und sich in veränderter Form neubildet. Verhindern lässt sich das nicht, schliesslich lassen sich weder die Nutzungsintensität eines noch nicht gebauten Features noch der Reparaturaufwand eines noch nicht genau analysierten Bugs voraussagen. Und derartige Beispiele gibt es viele.

Es ist aber nicht nur so, dass Aufwandsschätzungen in solchen Fällen keinen Mehrwert bringen, sie können sogar schädliche Auswirkungen haben. Am offensichtlichsten dadurch, dass die für sie aufgewendete Zeit nicht mehr in die Umsetzung fliessen kann, aber auch durch zunehmenden Verwaltungsaufwand - verfehlte Schätzungen führen in vielen Organisationen zu Korrekturversuchen in Form von noch mehr Reporting und Planung, was nochmal mehr Arbeitszeit bindet.

Zielführender ist es in einem solchen Szenario einfach so lange weiterzuarbeiten bis das Ziel erreicht ist, etwa dann wenn die Interaktions- oder Zahlungsbereitschaft der Kunden ausgeschöpft ist (im Fall einer volatilen Produktentwicklung) oder dann wenn alle Bugs und Performanceprobleme der kritischen Systeme behoben sind (im Fall der Reparaturarbeiten am Altsystem). Natürlich nur im Rahmen eines verfügbaren Budgets, das aber bis zur Zielerreichung immer wieder verlängert werden kann.

Die Moral der Geschichte ist also, dass es bestimmte Vorhaben gibt in denen Aufwandsschätzung keinen Mehrwert bringen und stattdessen das Potential haben Schaden anzurichten, weshalb man sie besser ganz lassen sollte. Allerdings ist das nur der eine Teil von #NoEstimates, der andere ist (Überraschung!) eine Methode zur Schätzung von Aufwänden. Das ist nochmal eine eigene Geschichte und geht auch nicht mehr auf Zuill zurück, mehr dazu im bald folgenden Teil II (hier ist er).

PS: Natürlich gibt es noch eine andere, destruktive Art von "No Estimates", bei der es sich um die Verweigerung aller Aufwandsschätzungen handelt, also auch dann wenn sie möglich oder sinnvoll wären. Zur Abgrenzung davon erfolgt die Schreibweise seit 2012 in einem Wort und mit Hashtag.

Siehe auch:

• 10 Jahre #NoEstimates (II)
  
• The Principles of No Estimates
  

Scaled Agile: Big Room Planning

Bild: Flickr / Marco Verch - CC BY 2.0

Es gilt als eines der Erkennungsmerkmale von SAFe, ist aber als verbreitete Praktik auch in anderen agilen Skalierungsframeworks zu finden, und sogar in manchen klassisch aufgestellten Organisationen als Teil ihrer Jahres- oder Quartalsplanung. Die Rede ist vom Big Room Planning oder BRP (mittlerweile in SAFe in PI Planning umbenannt), einer Veranstaltung die genutzt wird um die Backlogs oder Roadmaps der beteiligten Teams aufeinander abzustimmen.

Wichtig zu seinem Verständnis ist, dass es aus puristisch agiler Sicht eigentlich Ausdruck einer Dysfunktion ist, bzw. diese kompensiert. Agil arbeitende Teams sollen möglichst crossfunktional sein, d.h. alle zum Abschluss ihrer Vorhaben nötigen Fähigkeiten und Berechtigungen selbst besitzen. Dort wo das gegeben ist gibt es für übergreifende Planungsstrukturen keine Notwendigkeit. Da das in der Realität oft aber nicht gewollt oder möglich ist wurde das Big Room Planning erfunden.

Als eine agile Praktik wird es deshalb angesehen, weil es zwei Sachen anders macht als traditionelle Planungspraktiken. Zum einen werden von einander abhängige Arbeitspakete nicht sequentiell abgearbeitet (wie häufig in Gantt-Charts zu sehen) sondern weitgehend parallelisiert. Die zusammengehörigen Aufgaben werden dabei von den Teams in den selben Sprints oder Wochen eingeplant um bereits in ihnen zusammengeführt und integriert zu werden.

Das zweite agile Merkmal der Big Room Plannings ist, dass die Koordination der Teams nicht von einem dafür zuständigen Management übernommen wird sondern von den jeweiligen Teammitgliedern selbst. Um das möglich zu machen führen die beteiligten Teams ihre Planungsaktivitäten gemeinsam in einem grossen Raum durch (daher der Name)¹ um sich bei Bedarf schnell besuchen und unbürokratisch miteinander abstimmen zu können.

Ein typischer Ablauf sieht so aus, dass bereits im Vorfeld grob geklärt wurde welche Arbeitspakete externe Zulieferungen benötigen (ggf. in teamübergreifenden Refinements). Basierend darauf können diese in einer initialen teamübergreifenden Vorstellungsrunde hervorgehoben werden, wodurch der Bedarf klargemacht wird. Zusätzlich können alle anderen überprüfen ob auch sie ebenfalls davon betroffen sein könnten.

In einer ersten Planungsrunde erarbeitet und priorisiert danach zuerst jedes Team für sich die eigenen Anforderungen und Zulieferungen, in einer zweiten Phase werden diese Ergebnisse den anderen Teams mitgeteilt und diesen wird die Möglichkeit zu Feedback und Änderungsvorschlägen gegeben, in einer dritten passt jedes Team basierend darauf seine Pläne an. Dieser Wechsel von Einzelplanung und Abstimmung kann so lange wiederholt werden bis ein gemeinsamer Plan herauskommt.

Als zusätzlicher Effekt können durch ein Big Room Planning nicht nur die Umsetzungs- sondern auch die Planungszeiträume deutlich verkürzt werden. Die teamübergreifend gemeinsame Terminierung, die direkte Kommunikation und die kurzen Wege können in Stunden oder Tagen ermöglichen, was vorher mitunter Wochen und Monate gedauert hat.² Natürlich unter der Voraussetzung, dass alle Mitglieder aller beteiligten Teams für die gesamte Dauer der Veranstaltung zur Verfügung stehen.

Bereits für eine effizientere Durchführung der Planungen für bestehende Teams kann ein Big Room Planning auf diese Weise einen erheblichen Mehrwert liefern, zu einer nachhaltigen Agilisierung des Unternehmens trägt es aber paradoxerweise dadurch bei, dass es sich selbst nach und nach abschafft. Die in ihm offensichtlich werdenden Abhängigkeiten lassen sich nämlich festhalten und auf langfristige Muster untersuchen, die dann grundlage für Prozessverbesserungen sein können.

Wenn beispielsweise alle Teams jedesmal von einem einzelnen abhängen kann überlegt werden dessen Skills und Berechtigungen auf die anderen zu übertragen (wenn es ein Spezialistenteam ist) oder seine Systeme für die Bearbeitung durch andere zu öffnen (wenn es ein Komponententeam ist). Andere denkbare Verbesserung wären die Vergrösserung von Flaschenhals-Teams oder das Aufteilen eines Teams (und seiner Systeme) analog zu fachlichen Domänen.

Als Folge derartiger Optimierungen werden Big Room Plannings häufig mit der Zeit kleiner oder teilen sich in voneinander unabhängige "Small Room Plannings" auf. Umgekehrt kann ein mit der Zeit immer grösser werdendes Big Room Planning ein Zeichen dafür sein, dass die Zahl der Abhängigkeiten zwischen den Teams wächst und die Gesamtorganisation dadurch schwerfälliger wird. Sicherlich eine weitere interessante Transitionsmetrik.

¹Eine Durchführung in Video Calls ist auch möglich, ist erfahrungsgemäss aber weniger effizient.
²Ich habe einen Fall erlebt bei dem in zwei Tagen geklärt wurde was zuvor immer ca. ein dreivierteljahr gedauert hatte.

The agile Bookshelf: Cultish

Bild: Pxfuel - Lizenz

Ein Wort der Warnung vorweg: das hier ist ein düsteres Buch. In dem schlicht Cultish genannten Werk von Amanda Montell (hier geht es zu ihrer Website) geht es um Selbstmord-Sekten, Pyramidenspiele, Fitness-Besessenheit und um Fans im wahrsten Wortsinn (Fanatiker die ihrem Idol bedingungslos folgen, selbst wenn das nur ein Social Media-Sterchen ist). Dass all das irgendeine Gemeinsamkeit mit agilem Produkt- und Projektmanagement haben soll klingt zuerst abwegig - und doch gibt es eine.

Das was für Montell ein entscheidendes Erkennungsmerkmal eines Kults ist (egal ob es ein religiöser Kult ist oder die Anhängerschaft eines Kult-Produkts oder einer Kult-Figur) ist die Sprache. An zahlreichen Beispielen zeigt sie auf nach welchen Mustern sich diese entwickelt und immer stärker ausdifferenziert, bis zu dem Punkt an dem normale Menschen sie nicht mehr verstehen. "Kultisch" ist für sie kein Adjektiv sondern eine Sprachen-Bezeichnung, wie Spanisch oder Schwedisch.

Diese Sprache wird (oft bewusst aber häufig auch unbewusst) entwickelt um bestimmte Zwecke zu erfüllen. Einer davon ist es zum Beispiel, die eigene Bewegung cool oder mysteriös erscheinen zu lassen und damit attraktiv für Neumitglieder. Häufig dafür eingesetzte Stilmittel sind Abkürzungen und Wörter aus exotischen Sprachen, wobei beide möglichst selbstverständlich und ohne Erklärung in die tägliche Alltagssprache integriert werden.

Neben dieser Aussenwirkung entfaltet sich gleichzeitig auch eine zweite, die nach innen gerichtet ist. Die Abkürzungen und Fremdwörter als einzige zu kennen kann ein Gefühl der Zusammengehörigkeit und der Abgrenzung nach aussen erzeugen. In der Soziologie spricht man in diesem Zusammenhang von "In Groups" und "Out Groups" wobei sich innerhalb einer In Group nochmal weitere, kleinere In Groups befinden können, mit noch exklusiverem Wortschatz.

Diese Verschachtelung hilft wiederum dabei Neumitglieder und bestehende Mitglieder möglichst lange an die eigene Gruppe zu binden. Das Entdecken und Erlernen immer neuer Fach- und Fremdbegriffe sorgt nicht nur für eine möglichst lange und intensive Beschäftigung der Angehörigen mit ihrem Kult sondern kann darüber hinaus eine spannende und informative Lernreise sein. An dieser Stelle gibt es also durchaus positive Effekte, die Grenzen zwischen Kult und Didaktik verschwimmen.

Neben diesen positiven oder neutralen Begriffen (gering ausdifferenzierte In Groups sind etwas Alltägliches, z.B. Familien und Schulklassen) stehen aber auch kritischer zu sehende, wie z.B. "Loaded Language". Dabei erhalten alltägliche Begriffe eine abwertende oder verdrehte Bedeutung die nur Eingeweihte kennen. Sowohl als (wertende) Zusatzinformation als auch als Ersatz für den bisherigen Begriffsinhalt laden sie eine scheinbar nomale Unterhaltung mit Subtext auf.

Vollends ins Negative kippt die kultische Sprache schliesslich bei den "Thought-terminating Clichés", womit Aussagen mit sehr einfacher und eindeutiger Botschaft gemeint sind die nicht bezweifelt werden können ohne dass die Gefahr besteht von den anderen Kultmitgliedern als Abtrünniger angesehen zu werden. Ein Beispiel wäre "alle wahrhaft Gläubigen erkennen, dass diese Aussage wahr ist". Das kann nicht mehr hinterfragt werden ohne den eigenen Status angreifbar zu machen.

Wer sich häufig in der agilen Community aufhält wird an dieser Stelle bereits vieles wiedererkannt haben. Selbst wenn Amanda Montell selber nicht auf die Buzzwords der agilen Frameworks und Denkschulen eingeht - die von ihr beschriebenen Phänomene (nicht nur die gerade erwähnten sondern noch viele weitere) lassen sich problemlos von den anderen Kulten hierher übertragen. Falls daran noch Zweifel bestehen - bitte, gehen wir ins Detail.

Abkürzungen und Fremdwörter? Gibt es, zu den bekannteren gehören OKRs und Kanban. In Group und Out Group? Natürlich, dass sind die agil und "klassisch" arbeitenden Menschen. In Groups in der In Group? Finden sich z.B. bei Team die nicht nur Scrum machen sondern "sogar Extreme Programming". Loaded Language? Ausserhalb der "agilen Filterblase" ist Wasserfall eine neutrale Beschreibung. Thought-terminating Clichés? Finden sich u.a. in der Zu- und Absprechung des "Agilen Mindset".

Das heisst natürlich nicht, dass alle Agilisten verblendete Fanatiker mit einer sektenartigen Sprache sind, das wäre dann doch übertrieben. Aber etwas das man aus Cultish in die "agile Alltagswelt" mitnehmen kann ist die Erkenntnis, dass fast alle dort beschriebenen Bewegungen harmlos angefangen haben, sich dann aber durch eine Wechselwirkung aus immer kultischer werdender Sprache und immer extremeren Ansichten radikalisiert haben.

Bis zu einem bestimmten Grad kann kultische Sprache noch Kommunikation effektiver machen, Zusammengehörigkeitsgefühl erzeugen, hip sein und sogar selbstironisch benutzt werden, bis dahin ist das auch noch völlig unproblematisch. Was bleibt ist aber die Warnung davor es nicht zu übertreiben. Selbst wenn die agile Bewegung ganz sicher nie zu einer Selbstmord-Sekte werden wird - bereits das bewusste oder unbewusste Ausgrenzen anderer Menschen wäre schon nicht mehr im Sinn der Idee.

Kommentierte Links (LXXX)

Grafik: Pixabay / The Digital Artist - 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.

Steve Denning: Why ‘Big Bang’ Agile Transformations Are A Bad Idea

Die meisten Menschen die schon einmal in einer agilen Transformation mitgearbeitet haben werden Steve Denning vermutlich zustimmen: ein gesamtes Unternehmen in einem einzigen Grossprojekt umzubauen ist eine eher schlechte Idee, vor allem wenn damit ein einziger Stichtag verbunden ist, ab dem auf einmal alles anders funktionieren soll als vorher. Die Realität ist aber, dass es immer wieder versucht wird, derartige Vorhaben passen einfach zu gut zu den Planungs- und Budhetierungs-Routinen grosser Organisationen. Denning macht etwas Verdienstvolles und versachlicht diese Diskussion indem er reale Fälle betrachtet, darunter auch den der ING, der in den letzten Jahren häufig als Beispiel für eine gelungene Transformation genannt wird.

Bent Flyvbjerg: Make Megaprojects More Modular

Ein häufiges Argument gegen kleine, flexible Planungs- und Durchführungsprozesse ist, dass diese nur in eher kleinen Vorhaben möglich wären, in grossen gäbe es zu viele zu berücksichtigende Faktoren und Abhägigkeiten, die einen langem Planungsvorlauf und eine sich eng daran orientierende Ausführung erfordern würden. Bent Flyvbjerg, ein Oxford-Professor dessen Forschungsschwerpunkt Grossprojekte sind, widerspricht dem deutlich. An drei Beispielen (dem Bau einer Autofabrik, dem Bau einer Ubahn-Linie und der Entwicklung eines Satelliten) zeigt er auf, dass die in vielen agilen Teams üblichen Praktiken auch im Grossen anwendbar sind - wenn man es denn will.

Marty Cagan: Process People

Die aufkommende Product Operations-Bewegung scheint irgendetwas bei Marty Cagan getriggert zu haben. Mit Verweis auf sie eröffnet er eine alte Debatte erneut - braucht man wirklich diese ganzen Leute die sich nur um Projekt- und Prozessmanagement kümmern und keine "echte Arbeit" machen? Jenseits dieses steilen Aufhängers ist der Artikel durchaus ausgewogen (er macht am Ende klar, dass man diese "Prozessmenschen" trotz allem braucht), er zeigt aber drei zentrale Probleme der eher prozesslastigen Ansätze auf: 1.) in vielen Firmen sind Prozessmanager (oder Scrum Master, ProductOps, etc) eher Management-unerfahren, was der Bedeutung nicht gerecht wird, 2.) häufig werden dorthin nur Tätigkeiten abgeschoben die anderen Managern lästig sind, und 3.) formalisierte Prozesse neigen dazu ein Eigenleben zu entwickeln. Man kann ihm da nur schwer widersprechen.

Mike Cohn: Are Fixed-Price Projects Agile?

Irgendwann ist mal der Mythos in die Welt gesetzt worden, dass agile Produktentwicklung und fester Preisrahmen nicht kompatibel wären. Im agilen Vorgehen müsste man sich schliesslich immer anpassen können wenn die Realität sich ändert, was mit einem Fixpreis nicht möglich wäre. Mike Cohn zeigt in seinem Blog auf, dass das sehr wohl möglich ist, und das nicht nur auf praktischer sondern auch auf theoretischer Ebene. Zuerst macht er die richtige Feststellung, dass der kategorische Auschluss bestimmter Finanzierungskonstellationen selbst nicht sonderlich agil wäre, danach untersucht er das Gründungsdokument der agilen Softwareentwicklung, das agile Manifest, nach Unvereinbarkeitserklärungen. Spoiler: er findet keine.

Jeff Patton: Keep actual effort and outcome visible

Man könnte denken, dass irgendwann alle Möglichkeiten ein Board zu gestalten (das Informations-Werkzeug, nicht das Gremium) entdeckt worden sind. Tatsächlich gibt es aber immer wieder neue Ideen, die der Anwendung zusätzliche Dimensionen hinzufügen können. Diesesmal von Jeff Patton, mit dem Ziel im Produktmanagement Aufwand und Ergebnis miteinander zu verknüpfen.