Montag, 4. Juli 2022

Kultur

Bild: Unsplash / Richard Tao - Lizenz

Man kann fest davon ausgehen - wann auch immer eine Organisation sich in Richtung New Work, agile Produktentwicklung oder Vergleichbares verändern will wird sehr bald jemand anmerken, dass man dafür auch an der Kultur arbeiten müsste. Das ist auch grundsätzlich richtig, stösst aber schnell auf ein Problem: nur die wenigsten Menschen können beschreiben was sie unter Kultur verstehen. Da ein gemeinsames Verständnis aber die Grundlage der weiteren Schritte ist sollte man es zuerst herstellen.


Der Begriff Kultur definiert sich ursprünglich lediglich durch seine Abgrenzung zu einem anderen: zur Natur. Die Natur ist alles was auch ohne die Existenz Menschen vorhanden wäre, von der Plattentektonik über das Wetter bis hin zu Pflanzen und Tieren. Alle vom Menschen vorgenommenen Veränderungen an der Natur und alle menschlichen Erfindungen und Ideen sind dagegen Kultur, von der Sprache und der Landwirtschaft über die Musik und die Architektur bis hin zur Betriebswirtschaft und Informatik.1


Aus diesen Beispielen wird klar, dass es die eine einheitliche Kultur nicht gibt. Sie zerfällt in zahllose Subkulturen, die einer geografischen Region, einer historischen Epoche, einer Ethnie, einer Altersgruppe oder einer sozialen Gruppe entsprechen können. Zu der letzten gehören dann u.a. Gruppen mit gleicher Bildung, gleichem Einkommen, gleicher Religion, gleichem Beruf oder gleicher Zugehörigkeit zu einer Firma oder Organisation. Diese zuletzt genannte Subkultur ist die um die es in Change-Prozessen geht.


Eine solche Firmenkultur besteht dann aus verschiedenen Dimensionen. Zum einen den sichtbaren Artefakten wie Architektur, Dresscode und Corporate Design, aber auch Glaubenssätzen wie "ohne Vorschriften würde hier Chaos ausbrechen", Handlungsmaximen wie "im Zweifel eher anrufen als Emails schreiben" oder Gefühlen und Emotionen wie "wir sind hier alle eine grosse Familie". Je nach Einzelfall können noch weitere Dimensionen dazukommen.


All diese Dimensionen sind prägend für die Art wie in einer Firma oder Organisation mit Arbeit und mit den anderen Mitarbeitern umgegangen wird. Herrscht beispielsweise eine Untertanenkultur vor ("ich bin unwissend und machtlos, Veränderungen müssen von anderen kommen") wird ein auf Eigeninitiative und Verantwortungsübernahme basierender Arbeitsmodus kaum funktionieren, in einer Partizipativen Kultur ("ich kann Veränderungen bewirken, aber wenn ich sie will muss ich es selbst tun") dagegen schon.


Was mittlerweile ebenfalls klar geworden sein dürfte: es ist extrem schwierig eine Unternehmenskultur zu verändern, da sie im Wesentlichen in den Köpfen der Menschen existiert. Das heisst nicht, das es nicht ginge, es gibt bekannte Beispiele dafür. Eines des bekanntesten dürfte z.B. das Automobil-Werk im kalifornischen Fremont sein, das nacheinander von GM, Toyota und Tesla betrieben wurde und in der Zeit jeweils eine spürbar andere Firmenkultur (und dadurch bedingte Produktivität) gehabt haben soll.


Wie ein solcher Kulturwandel aussehen könnte ist nochmal eine eigene Geschichte, bevor derartige Schritte angegangen werden ist es aber wie gesagt eine gute Idee sich zuerst ein gemeinsames Verständnis dessen zu erarbeiten was man unter "Kultur" versteht. Erst dann ist es möglich zu überlegen ob sie überhaupt geändert werden kann, und wenn ja wie.



1Die Beschränkung des Kulturbegriffs auf die "schönen Künste" wie Schauspiel, Musik und Literatur ist lediglich eine alltagssprachliche Verkürzung

Donnerstag, 30. Juni 2022

Kommentierte Links (LXXXIX)

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.

Mary Poppendieck: When Demand Exceeds Capacity

Die Lean Essays von Mary Poppendieck sind leider selten geworden, dieser hier ist der erste seit über zwei Jahren. Wie immer hat sich das Warten aber gelohnt, was wir hier bekommen ist ein langes Stück über das Phänomen, dass in vielen Unternehmen durchgehend mehr zu tun ist als abgearbeitet werden kann. Neben einer Analyse der Ursachen (Spoiler: es hat mit fehlender Effizienz und der fehlenden Bereitschaft Nein zu sagen zu tun) nennt sie drei mögliche Wege dieser Situation zu entkommen - eine Priorisierung der Abarbeitung bestehender Aufträge über der Annahme von neuen, eine Optimierung des Gesamt-Arbeitsflusses statt einer Beschleunigung von Einzelaufgaben und die Einrichtung von alleinverantwortlichen Teams, die (Teil-)Produkte möglichst ohne Abhängigkeiten und Zulieferungen erstellen können.

Tim Ottinger: How To Understand Refactoring

Das Erklären von technischen Schulden und Refactoring für Menschen ohne technisches Verständnis dürfte eine der grössten Herausforderungen in IT-Projekten oder Software-nutzenden Organisationen sein. Tim Ottinger stellt hier eine von ihm verwendete Analogie vor: eine "historisch gewachsene" Eingabe-Maske einer Anwendung, der immer weitere Felder hinzugefügt wurden, die in immer komplizierteren Beziehungen zueinander stehen und dadurch immer fehleranfälliger werden. Wer irgendwann mit grossen, über längere Zeit entstandenen Anwendungen gearbeitet hat wird ahnen, dass diese Erklärung einen Ursprung in einem real existierenden Beispiel haben dürfte, aber auch für Menschen ohne derartige Erfahrungen sollte sie verständlich und nachvollziehbar sein.

John Cutler: Scaled Feature Factories

John Cutlers Feature Factory-Analysen ziehen sich mittlerweile durch mehrere Jahre. Nach dem mittlerweile legendären Auftakt-Artikel 12 Signs You’re Working in a Feature Factory aus dem Jahr 2016 und der Fortsetzung 2 Signs You’re Working in a Feature Factory — 3 Years Later aus dem Jahr 2019 ist diesen Monat der dritte Teil erschienen: Scaled Feature Factories (bei gleichbleibendem Rhythmus kommt Teil Vier dann 2025). Die Kern-Aussage: Feature Factories (IT-Organisationen die auf "Akkord-Programmierung" optimiert sind um feste Lieferdaten zu erreichen) entstehen nicht aus einer Laune oder aufgrund problematischer Menschenbilder, sondern haben systemische Ursachen, die man verstehen muss wenn man versuchen will etwas zu verändern.

Willem-Jan Ageling: Scrum Teams are often Coached to Death, while the Problems are With Management

Apropos systemische Ursachen. Was Willem-Jan Ageling hier zusammenträgt zeigt deutlich auf, wie Umgebungsfaktoren dazu beitragen können, dass Scrum Teams nicht in der Lage sind ihre Leistung zu erbringen. Micro-Management durch Manager ausserhalb der Teams, ein Fokus auf Planerfüllung statt auf Nutzer-Bedürfnisse, Untergraben der Teamziele durch abweichende Ziele für Einzelpersonen, Untergrabung der Moral durch häufige Einforderung von Überstunden, Multitasking durch Starten zu vieler paralleler Projekte und Nicht-Beseitigung externer Störfaktoren können in Summe derartig behindernd auf die tägliche Arbeit einwirken, dass selbst die bestmöglich durchgeführten teaminternen Meetings und Abläufe kaum noch zu brauchbaren Ergebnissen führen.

Anthony Mersino: Agile on Trial, Or, How Not to Write an Agile Contract

Zuletzt ein Klassiker: wie in einem agil arbeitenden Umfeld Verträge gestaltet sein sollten, bzw. wie man es besser nicht machen sollte. Anthony Mersino zeigt einige der Fehler auf die häufig gemacht werden und verweist auf zwei der wichtigsten Ansätze für eine bessere Durchführung - Money for Nothing and Change for Free von Jeff Sutherland und den Agile Contracts Primer von Tom Arbogast, Craig Larman und Bas Vodde. Obwohl beide schon über zehn Jahre alt sind haben sie noch nichts von ihrer Aktualität eingebüsst.

Montag, 27. Juni 2022

One way Door und Two way Door-Entscheidungen

Bild: Unsplash / Phil Hearing - Lizenz

Nicht auf ein Vorgehen festgelegt zu sein sondern sich bei Bedarf schnell umentscheiden zu können ist einer der Kernaspekte von Agilität. Das setzt allerdings einen Sachverhalt voraus über den eher selten gesprochen wird: den, dass bereits getroffene Entscheidungen überhaupt veränderbar sind. Ist das nicht der Fall hat es tiefgreifende Folgen, sowohl auf das was derartige Entscheidungen bewirken als auch darauf wie sie vorbereitet werden müssen.


Im Business-Englisch spricht man in diesem Zusammenhang von "One way Door-Entscheidungen" und "Two way Door-Entscheidungen". Beim zweiten Typ kann man wieder zum Zustand vor der Entscheidung zurückgehen und eine andere treffen. Ein Beispiel dafür wäre die Frage wie ein Gebäude genutzt werden soll. Beim ersten Typ ist das nicht möglich, die Entscheidungen sind (in mindestens einer ihrer Optionen) endgültig. Ein Beispiel dafür wäre die Frage ob ein Gebäude abgerissen werden soll.


Im Umgang mit diesen beiden Entscheidungstypen  führt der erste, nicht reversible, in der Regel zu deutlich höheren Vorbereitungs-Aufwänden und deutlich längerer Vorlaufzeit, da Korrekturmassnahmen nachher nicht mehr möglich sind. Umgekehrt (und das wird häufig vergessen) kann der zweite, bei Bedarf wieder umkehrbare, Typ auch mit wenig Aufwand und Vorlaufzeit getroffen werden, schliesslich ist er ja korrigierbar. Popularisiert wurde diese Unterscheidung durch den Amazon-CEO Jeff Bezos.


Some decisions are consequential and irreversible or nearly irreversible – one-way doors – and these decisions must be made methodically, carefully, slowly, with great deliberation and consultation. If you walk through and don’t like what you see on the other side, you can’t get back to where you were before. We can call these Type 1 decisions. But most decisions aren’t like that – they are changeable, reversible – they’re two-way doors. If you’ve made a suboptimal Type 2 decision, you don’t have to live with the consequences for that long. You can reopen the door and go back through. Type 2 decisions can and should be made quickly by high judgment individuals or small groups.


Selbst wenn er den Begriff hier nicht benutzt, das was Bezos als "Two way Door-Entscheidung" beschreibt ist Teil der agilen Vorgehensmodelle. Statt nach einer möglichst perfekten Lösung suchen zu müssen (was mitunter gar nicht machbar ist) kann in Kauf genommen werden danebenzuliegen, schliesslich kann später noch reagiert und korrigiert werden. Aber umgekehrt betrachtet - bedeutet das, dass es andere (One way Door-)Entscheidungen gibt, für die Agilität ungeeignet ist?


Die Antwort darauf ist ein Klassiker: Ja, aber. Ja, es gibt nicht rückgängig machbare Entscheidungen, deren Tragweite so gross ist, dass sie besser sehr gründlich vorbereitet werden sollten. Aber dass diese Entscheidungen eine derartige Natur haben ist in einem Grossteil der Fälle kein Naturgesetz. Bei näherer Betrachtung liessen sich viele dieser Einweg-Türen auch in beide Richtungen benutzen oder so umbauen, dass das zukünftig möglich ist.


Der offensichtliche dieser Fälle ist der erste. Ein grosser Teil der Entscheidungen die in grossen Organisationen nicht reversibel ist, ist es nur deshalb nicht, weil irgendeine Genehmigung fehlt. Das kann die Erlaubnis eines uneinsichtigen Vorgesetzen sein, sehr häufig ist es aber lediglich die fehlende Berechtigung in irgendeinem Tool einen abgeschlossenen Vorgang wieder zu editieren1. Hier kann alleine das Erteilen dieser Berechtigung die Entscheidung umkehrbar machen.


Weniger offensichtlich ist der zweite Fall. Viele Entscheidungen können durch geändertes Prozess- oder System-Design von One way Door-Entscheidungen zu Two way Door-Entscheidungen werden. Das kann zum Beispiel dadurch geschehen, dass Budgets nachträglich anpassbar gemacht werden oder dadurch, dass Software-Anwendungen modularisiert werden, so dass Änderungen nicht mehr weitreichende Auswirkungen auf alle Benutzer haben müssen.


Derartige Umbauten führen aber in der Regel zu einem Rückgang von Detail-Kontrolle oder sie kosten Geld, weshalb viele grosse Organisationen sie (bewusst oder unbewusst) scheuen. Sie zu unterlassen führt dann zu One way Door-Entscheidungen, auch an den Stellen an denen es dafür eigentlich keine Notwendigkeit gibt. Und das hat deutlich spürbare negative Folgen, die auch bereits von Jeff Bezos in seinem oben erwähnten Text beschrieben wurden.


As organizations get larger, there seems to be a tendency to use the heavy-weight Type 1 decision-making process on most decisions, including many Type 2 decisions. The end result of this is slowness, unthoughtful risk aversion, failure to experiment sufficiently, and consequently diminished invention.1 We’ll have to figure out how to fight that tendency.


Aus einer "agilen Perspektive" betrachtet bedeutet das, dass sich die agilen Vorgehensmodelle keineswegs auf die Two way Door-Entscheidungen beschränken sollten. Sie sollten auch die One way -Entscheidungen angehen, mit dem Ziel sie so zu verändern, dass sie ihre Einwegartigkeit verlieren.



1Ein Fall dieser Art den ich bei einem Kunden beobachten durfte: aufgrund fehlender Berechtigungen liess sich in einem System ein einmal eingetragenes Veröffentlichungs-Datum eines Produkts nicht mehr ändern.

Donnerstag, 23. Juni 2022

Keynesianismus und Austerität in der Softwareentwicklung

Bild: Wikimedia Commons / TM - CC BY-SA 2.0

Dass technische Schulden eine Analogie aus dem Finanzwesen sind, mit deren Hilfe man die Folgen unterlassener Software-Modernisierung und -Instandhaltung beschreiben kann, dürfte zwar weitgehend bekannt sein, welche Ideen genau hinter dem Begriff stehen ist aber nur noch wenig bekannt. Eine nähere Beschäftigung damit wäre dabei durchaus lohnend, denn die Analogie geht weiter als man denken könnte - auch ein weiterer Ansatz der Haushaltsführung kann darin enthalten sein, der Keynesianismus.


Zur Auffrischung: von der Aufnahme technischer Schulden spricht man, wenn in der Software-Entwicklung schnelle Lösungen gesucht werden, die dann dadurch erreicht werden, dass eigentlich wichtige Dinge wie klare Architektur, das Einspielen von Updates oder Test-Absicherung auf später verschoben werden. Dadurch wird man kurzfristig schneller, dafür werden alle Weiterentwicklungen schwieriger. Diese Mehraufwände sind die "Zinsen", die zusätzlich zu den Schulden abzubezahlen sind.


Der in diesem Zusammenhang ebenfalls analogiefähige Haushaltsführungs-Ansatz des nach John Maynard Keynes benannten Keynesianismus (bzw. dessen Konjunkturtheorie) geht davon aus, dass es grundsätzlich sinnvoll sein kann Schulden aufzunehmen wenn Zeit- oder Ressourcenknappheit gegeben sind. Wenn diese Notlage mit dem durch Verschuldung gewonnenen Kapital bewältigt wurde kann die Rückzahlung stattfinden, so dass bis zur nächsten Notlage wieder die Schuldenfreiheit gegeben ist.


Auch auf die Softwareentwicklung kann der Keynesianismus angewendet werden. Um in Druckphasen (z.B. vor dem Weihnachtsgeschäft) schneller zu werden können eigentlich wichtige Aufgaben verschoben werden, sobald der Druck nachlässt finden Refactorings, Updates und nachträgliche Herbeiführung von Testabdeckung statt um die technischen Schulden zurückzuzahlen. Kurzfristige Handlungsfähigkeit wird so im wahrsten Sinn des Wortes erkauft.


Das Problem dabei: in der Realität funktioniert die keynesianistische Konjunkturtheorie nur extrem selten, sowohl in der Wirtschaft als auch in der Softwareentwicklung. Das Aufnehmen von (technischen) Schulden findet zwar statt, deren Rückzahlung in Entspannungsphasen aber nur eingeschränkt. Beim Eintreffen der nächsten Notlage besteht der Schuldenberg daher noch und wird jetzt weiter erhöht, mit dem Risiko eines (technischen) Bankrotts (Software die nicht mehr wartbar und weiterentwickelbar ist).


Die Alternative dazu besteht in einem anderen Haushaltsführungs-Ansatz: der Austerität. In ihm wird auf die Aufnahme von Schulden kategorisch verzichtet, selbst wenn das schrumpfende Haushalte zur Folge hat. Übertragen auf die Softwareentwicklung würde das bedeuten, dass auf die Aufnahme technischer Schulden auch dann verzichtet wird wenn dadurch gewünschte Funktionen erst verspätet oder deutlich verkleinert geliefert werden können.


Welcher der beiden Ansätze (Keynesianismus oder Austerität) von einer Softwareentwicklungs-Einheit gewählt werden sollte ist nicht klar zu sagen, je nach Kontext kann es sogar sinnvoll sein zwischen den beiden zu wechseln. Bei Teams die immer wieder falsch verstandenen Keynesianismus anwenden (Schulden aufnehmen aber nicht zurückzahlen) besteht aber irgendwann nur noch die Auswahl zwischen technischem Bankrott und Austerität.


Um es nicht dazu kommen zu lassen sollten keynesianische Teams sich regelmässig fragen was John Maynard Keynes sagen würde wenn er ihnen zusehen würde. Gegebenenfalls eine schöne Übung für die nächste Retrospektive.

Montag, 20. Juni 2022

Skunk Works

Wer schon einmal in einem amerikanischen Unternehmen gearbeitet hat könnte dort den Begriff "Skunk Works" gehört haben, mit dem kleine, crossfunktionale Teams bezeichnet werden, die mit grossen Freiheiten an wichtigen Innovationsprojekten arbeiten (in der Regel mit Praktiken die man heute als agil bezeichnen würde). Von Nickolas Means kann man in diesem Vortrag erfahren wo dieser Begriff herkommt, nämlich von einer Einheit die in den 40er und 50er Jahren die Entwicklung neuartiger Flugzeuge verantwortete.



Was an dieser Geschichte interessant ist, ist dass sie zwei scheinbaren Gewissheiten über die agile Produktentwicklung widerlegt. Zum einen, dass damit erst im späten 20. Jahrhundert begonnen wurde und zum anderen, dass sie zuerst im Rahmen von Software-Projekten stattfand. Was damals noch nicht existierte war aber lediglich der Begriff "agil", die Praktiken wurden bereits verwendet.

Donnerstag, 16. Juni 2022

DevOps

Bild: Pexels / Jep Gambardella - Lizenz

Wir müssen uns über DevOps unterhalten. Über jene Idee also, die seit einiger Zeit parallel, überlappend oder ergänzend zur Agilität auftritt und von dieser auch nicht klar zu trennen ist. Zum einen weil es sich um ein gutes und wichtiges Konzept handelt, das jeder der in der IT arbeitet kennen sollte, zum anderen aber auch weil es leider immer mehr verkompliziert und mystifiziert wird, bis zu dem Punkt an dem kaum noch klar ist was es sein soll. Dabei ist es eigentlich ganz einfach.


DevOps bedeutet, dass Entwicklung (Development) und Betrieb (Operations) einer Software nicht mehr von unterschiedlichen Einheiten verantwortet wird sondern von einer gemeinsamen. Das reduziert Übergaben und Wartezeiten und beschleunigt damit die Prozesse, es führt durch seinen Grundsatz "you build it, you run it" aber auch zu besserer Wartbarkeit, da kaum ein Entwickler übermässig komplex zu betreibende Software erstellen wird, wenn er weiss, dass er selbst darunter leiden würde.


Was dazukommt ist noch eine kleine aber feine Begriffs-Nuancierung. DevOps ist nicht etwa nur Dev und Ops, es bedeutet alles von Dev bis Ops. So arbeitende Teams müssen daher auch sämtliche Tätigkeiten durchführen können mit denen neu entwickelte Features in die Betriebsumgebungen kommen, also auch Integration, Test und Release sowie ggf. Rollbacks, Wiederherstellungen und Anwender-Support. Der Verantwortungsbereich wird dadurch nochmal grösser und vielfältiger.


Ein Grossteil der DevOps-Befürworter wird dieser Erklärung zwar zustimmen, gleichzeitig aber betonen, dass sie unvollständig ist. Je nach Person wird er ergänzen, dass ausserdem noch bestimmte Praktiken, Phasenmodelle,1 Tools oder Mindsets dazugehören. Das ist zwar gut gemeint, trägt letztendlich aber nur zu der oben erwähnten Verkomplizierung und Mystifizierung bei, denn so hilfreich all das auch ist - es ist nur Mittel zum Zweck, und der Zweck bleibt das Zusammenführen von Dev, Ops und Zwischenschritten.


Werfen wir einen näheren Blick darauf. Ein DevOps-Team in dem nur die bisherigen Verantwortlichen für Entwicklung, Integration, Test, Release, Betrieb und Support zusammengefasst werden wird von Anfang an eine Unwucht haben, in der die Entwicklung neuer Funktionen nur der kleinere Teil der Aufgaben ist, die um die bestehenden Funktionen kreisenden Tätigkeiten dagegen den grösseren ausmachen. Es besteht das Risiko, dass immer mehr Kapazität dorthin verlagert wird. Aus DevOps wird nur noch Ops.


Um dem zu begegnen ist es nötig diesen grösseren Teil so zu organisieren, dass er nur einen möglichst kleinen Teil der Arbeitskapazität benötigt. Dieses Kunststück kann nur vollbracht werden indem möglichst viele Tätigkeiten aus diesem gösseren Bereich automatisiert werden und dann entweder ununterbrochen durchlaufen (z.B. Regressionstests und Monitoring) oder auf Knopfdruck durchgeführt werden können (z.B. Deployments und Rollbacks).


An dieser Stelle wird die Differenzierung offensichtlich - Praktiken, Phasenmodelle, Tools oder Mindsets können Teil von DevOps sein wenn sie dazu beitragen den Arbeitsaufwand von Nicht-Entwicklungs-Tätigkeiten zu begrenzen und zu reduzieren - was je nach Einzelfall sehr unterschiedlich aussehen kann. Dort wo sie aber zu einem grundsätzlich vorgegebenen Bestandteil erklärt werden bilden sie an vielen Stellen eine Lösung ohne Problem, die den Sinn des ganzen Ansatzes unklar werden lässt.


Das Fazit ist also: DevOps bedeutet die effektivitätssteigernde Zusammenfassung aller Tätigkeiten von Dev bis Ops, unter optionalem Einschluss weiterer Elemente, sofern die dafür sorgen, dass der Nichtentwicklungsteil so wenig aufwändig ist wie möglich. Eine schlichte Erklärung, unkompliziert, unmystisch und sofort nachvollziehbar.



1Auch wenn es manchmal bestritten wird: ja, der oft abgebildete DevOps Flow ist ein Phasenmodell

Montag, 13. Juni 2022

Agilität kommt mit einem Preis

Bild: Wikimedia Commons / Elvey - CC0 1.0

Wenn agiles Arbeiten irgendwo zum ersten Mal vorgestellt wird klingt es meistens zu schön um wahr zu sein. Alles wird schneller, besser, kundenorientierter und Mitarbeiter-freundlicher, dazu ist es irgendwie modern und hip - wer würde das nicht wollen? Irgendwann während der Umsetzung kommt dann aber das unschöne Erwachen: auf einmal ist vieles anstrengend und ungewohnt. Und vor allem gibt es plötzlich eine lange Liste von bisher gewohnten Praktiken die man nicht mehr machen soll.


Es ist dabei normalerweile nicht so, dass im Vorfeld irgendetwas bewusst verschwiegen worden wäre. Für einen überzeugten Agilisten sind die meisten dieser gewohnten Praktiken Notlösungen, die nur da sind weil es bisher nicht Besseres gab, weshalb sie auch niemand vermissen wird. Für viele andere Menschen sind sie aber wichtig und geben Sicherheit, weshalb voher klar kommuniziert werden sollte: der Preis der Agilität ist, dass es einige andere Dinge nicht mehr geben kann.


Was mit der Einführung agiler Arbeitsweisen zum Beispiel verschwindet ist die Möglichkeit langfristige Detailpläne zu machen. In einem Arbeitsmodus der davon ausgeht, dass es sinnvoll und richtig ist seine Pläne regelmässig an Veränderungen anzupassen kann man nicht mehr festlegen woran ein Team im zweiten Sprint des vierten Monats des übernächsten Jahres arbeiten wird. Ziele müssen abstrakter werden und auf unterschiedlichen Wegen erreichbar sein.


Zusammenhängend damit verschwindet auch die Möglichkeit einer detail-Budgetierung. Lange im Voraus Tätigkeiten bestimmte Buchungsnummern zuzuordnen und festzulegen, dass Arbeitsstunden nur noch auf diese gebucht werden dürfen nähme der Organisation jegliche schnelle Reaktionsfähigkeit (Anpassungen der Budgets sind zwar möglich, in der Regel aber mit Bürokratie verbunden). Budgetiert werden müssen stattdessen jeweils ganze Produkte oder Projekte.


Während der Umsetzung ändert sich, dass man Ressourcen (→ Menschen) nicht mehr so effizient einsetzen kann, dass sie tage- oder stundenweise zwischen Team und Projekten hin- und hergeschoben werden, je nachdem wo es gerade dringend ist. Würde das gemacht hätte jede Planänderung sofort Auswirkungen quer durch die Organisation, da neue Ressourcenverschiebungen nötig würden. Nötig ist stattdessen eine feste Zugehörigkeit zu langlebigen Teams.


Am Ende der Verarbeitungsketten muss schliesslich auf die Synergie-Effekte gemeinsamer Gross-Integrationen, Gross-Abnahmen und Gross-Releases verzichtet werden, genauso wie auf die (scheinbare) Sicherheit nachgelagerter Testphasen. Um auf Änderungen reagieren zu können muss man diese früh entdecken und daher möglichst oft integrieren, testen und releasen. Statt das in späten Phasen zu tun muss das früher und häufiger stattfinden.


Es liessen sich noch viele weitere Beispiele finden, die Botschaft ist aber klar: vieles von dem was im bisherigen Organisationsmodell richtig und wichtig war kann nicht weiter beibehalten werden wenn der Arbeitsmodus agil wird. Es abzuschaffen bringt so grosse Vorteile mit sich, dass es lohnt das zu machen, für die Menschen die bisher so gearbeitet haben (und deren Stelle mitunter davon abhängt) kann es aber anstrengend und schmerzhaft sein.


Diese Änderungen und damit verbundenen Schmerzen sind der Preis den man dafür zahlen muss agil zu werden. Und dort wo die strategische Entscheidung ansteht in Zukunft agil werden zu wollen sollte dieser Preis klar und deutlich genannt werden. Unterbleibt das werden die gegenläufigen Arbeitsweisen ständig Störungen und Widerstände erzeugen. Wird es klar benannt klingt der Zielzustand zwar nicht mehr zu schön um wahr zu sein, man kann aber deutlich besser daran arbeiten dorthin zu kommen.

Donnerstag, 9. Juni 2022

Agility over the Air

Bild: Unsplash / Joonyeop Baek - Lizenz

Es gibt Zusammenhänge die bei näherer Betrachtung offensichtlich sind, auf die man aber auch erst einmal kommen muss. Einer davon ist der, dass der Durchbruch der agilen Frameworks in den Mainstream zeitgleich zur Verbreitung des Internets statt gefunden hat, zunächst zum stationären (mit Telefonkabel in der Wand) und später zum mobilen (über Funk, bzw. W-Lan). Man kann sogar die These wagen, dass ohne das Internet Agilität heute einen wesentlich geringeren Verbreitungsgrad hätte.


Die Verbindung von Internet und Agilität beruht dabei auf mehreren Faktoren. Zum einen hat das World Wide Web zu einer noch nie dagewesenen Zugänglichkeit von Wissen geführt. Ob über Wikipedia, Youtube, Blogs oder kommerzielle Angebote - nie zuvor war es so einfach so viele Informationen zu jedem möglichen Themengebiet zu finden. Das betrifft auch Scrum & Co, die man online in beliebiger Tiefe erkunden kann, auch ganz ohne Schulungen, Zertifizierungen oder User Groups.


Mindestens genauso wichtig sind aber auch weitere Aspekte: sowohl Product Discovery als auch das incrementell-iterative Ausliefern neuer Funktionalitäten und das Sammeln von Benutzer-Feedback und Nutzungsdaten sind erst über das Internet in einer Geschwindigkeit und Qualität möglich geworden, die alles in den Schatten stellt was man sich noch bis in die 90er Jahre vorstellen konnte. Bei näherer Betrachtung kann man es in jedem dieser Bereiche erkennen.


Product Discovery gibt es zwar unter verschiedenen Namen schon lange, in einer analogen Durchführung aber nur mit eingeschränkter Reichweite und Geschwindigkeit (verlangsamt durch Papier-Post, Anreisewege von Focusgruppen und Ähnliches). Online ist es dagegen möglich Fragebögen, MVPs und Prototypen schnell weltweit zur Verfügung zu stellen und die Antworten und Reaktionen auch in Echtzeit auszuwerten.


Noch offensichtlicher sind die Vorteile bei der incrementell-iterativen Auslieferung. In den frühen Tagen von Scrum und Extreme Programming erfolgte das zur Verfügung Stellen neuer Features noch über den Versand von Disketten oder CDs, die tagelang unterwegs sein konnten. Mit dem Aufkommen von Web-Anwendungen entfiel diese Verzögerung, auf einmal war es möglich direkt am Tag der Veröffentlichung mit der Nutzung zu beginnen.


Mit leichtem Verzug ist diese Beschleunigung auch für Betriebssysteme und Apps möglich geworden. Windows, Android oder die Apps der Mobilgeräte erhalten heute ständige kleine Updates, die über Kabel oder W-Lan (over the Air) heruntergeladen werden und sich beim nächsten Neustart des Geräts selbst installieren, das Selbe trifft mittlerweile auf Staubsauger, Autos und sonstige Geräte zu (solange der Hersteller nicht darauf beharrt Updates nur in der Werkstatt einzuspielen).


Natürlich erfolgt auch das Sammeln von Benutzer-Feedback und Nutzungsdaten heute schneller als früher. Am offensichtlichsten durch die Kommentare und Bewertungen in Web-Shops und App-Stores die sofort eingesehen werden können, aber auch durch die von den Geräten an den Hersteller übertragenen Daten zu Häufigkeit, Dauer und Art der Nutzung. Mit Hilfe von A/B-Tests ist sogar ein Live-Vegleich verschiedener Produktversionen möglich.


Zuletzt gibt es bestimmte agile Vorgehensmodelle die durch das Internet nicht nur beschleunigt werden sondern ohne es gar nicht denkbar wären, z.B. Chaos Engineering oder FinOps, die darauf beruhen, dass Online Anwendungen ganz in die Cloud gewandert sind, wo es möglich ist die Reaktionen auf Störungen und Änderungen wahlweise zu automatisieren oder zu automatisiert zu begrenzen, um so Schäden oder Kosten möglichst klein zu halten.


Natürlich ist es auch weiterhin möglich "Offline-Agilität" zu haben, so wie es in den 90ern noch der Fall gewesen ist. Die Vorteile der Vernetzung über das Internet sind aber so gross, dass "Online-Agilität" mit Updates und Feedback over the Air heute der Standard geworden ist. Und für alle die nach dem Jahr 2000 beginnen haben agil zu arbeiten dürfte eine Arbeit ohne das Internet kaum noch vorstellbar sein.

Montag, 6. Juni 2022

Woher die Sprints in Scrum ihren Namen haben

Bild: Pexels / Run4FFWPU - Lizenz

Dass der Ursprung von Scrum sich irgendwo im Dunkel der Geschichte verliert hat zur Folge, dass sich Vieles nicht mehr genau nachvollziehen lässt. Da nicht absehbar war welche Popularität das Framework einmal erreichen würde wurden z.B. Entscheidungen und Entwicklungen nicht dokumentiert, weshalb bei vielen Begriffen nicht mehr genau zu sagen ist warum sie damals gewählt wurden. Zumindest bei einem ist jetzt aber Licht ins Dunkel gekommen - beim Sprint.


Verdanken tun wir das Mike Cohn, einem der ersten Scrum-Pioniere. In der ersten Folge seines Agile Mentors Podcast erzählt er, dass er bereits im Jahr 1994 mit Scrum in Berührung gekommen ist, also noch bevor es 1995 auf der OOPSLA-Konferenz erstmals der Öffentlichkeit vorgestellt wurde. Er hat es damit in seiner frühesten Form erlebt, und in der sah es noch deutlich anders aus als heute. Das betrifft auch die Sprints, deren Ursprung er wie folgt beschreibt:

 

In den ersten Jahren hatte Scrum (bzw. dessen Vorformen) noch starke Züge von Wasserfall. Anders als heute folgte nicht unmittelbar ein Sprint dem nächsten, stattdessen waren die Sprints lediglich die Umsetzungsphasen im Anschluss an vorgelagerte längere Planungs- und Konzeptionszeiträume. In diesen vorgelagerten Schritten wurde bereits vieles vordefiniert was danach nur noch abzuarbeiten war, und dieses finale Abarbeiten erfolgte möglichst schnell - als Endspurt, oder auf Englisch als Sprint.1


Im Rahmen der methodischen Weiterentwicklung wurde die vorgelagerte Planung und Konzeption in den 90ern dann nach und nach als eigenständige Phase abgeschafft und in die Sprints integriert, heute findet sie sich dort in den Planning- und Refinement-Meetings wieder. Infolgedessen rückten die Sprints immer näher aneinander, bis zu der heute üblichen Regelung, in der sie nur noch durch eine logische Sekunde voneinander getrennt sind.


Man könnte argumentieren, dass man die Sprints irgendwann in dieser Zeit hätte umbenennen müssen um semantisch korrekt zu bleiben, da sie durch den Wegfall der vorgelagerten Planungsphasen ihren Endspurt-Charakter verloren haben. Andererseits liesse sich sich aber auch der Standpunkt vertreten, dass ein Sprint weiterhin der Umsetzungs-Endspurt nach den vorgelagerten Backlog Refinements ist, die jetzt während oder parallel zu den früheren Sprints stattfinden.

 

Der Grund für die Nicht-Umbenennung ist aber vermutlich banal: der Begriff der Sprints ist bereits früh so stark mit Scrum assoziiert worden, dass seine Aufgabe die Anwender zu stark irritiert hätte. Und wirklich wichtig scheint der Benennungs-Hintergrund für die Scrum-Gründer Ken Schwaber und Jeff Sutherland auch nicht zu sein, jedenfalls haben sie ihn in keinem ihrer Grundlagenwerke thematisiert. Um so dankbarer kann man Mike Cohn dafür sein, dass er sein "historisches Wissen" geteilt hat.



1Im OOPSLA-Konferenzpapier finden sich diese Planungs- und Umsetzungsphasen noch abgeschwächt als "Pre-Game" und "Game" wieder

Freitag, 3. Juni 2022

If you have a dependency - you are a silo!

Seit einiger Zeit bin ich der Meinung, dass alle agilen Mindsets und Methoden zwar schön und gut sind, dass der wahre Schlüssel zu mehr Agilität aber in der Auflösung der Abhängigkeiten zwischen Teams, Abteilungen und anderen organisatorischen Silos liegt (zumindest ab Grössenordnungen von 50 Mitarbeitern oder mehr). Jim Benson vom Modus Institute schlägt hier in die gleiche Kerbe und fügt dem Ganzen noch einige originelle Gedanken hinzu.



Ein Sekundär-Nutzen dieses Videos: wir haben mit ihm ein schönes Beispiel dafür, wie man mit minimalen Mitteln (Miro, einer Webcam und einem einfachen Editierprogramm) ein vernünftiges Erklär-Video inclusive Visualisierungen hinbekommen kann.

Dienstag, 31. Mai 2022

Kommentierte Links (LXXXVIII)

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.

Roman Pichler: Product Teams in Scrum

Vor einiger Zeit hatte ich in den kommentierten Links über Brian Milner geschrieben, der der Meinung ist, dass jeder Product Owner ein zweites Team neben seinem Scrum Team hat, sein Stakeholder Team nämlich. Roman Pichler geht hier noch einen Schritt weiter und rät dazu, das Scrum Team durch die Integration der (zentralen) Stakeholder zu einem Product Team auszubauen. Das hat seinen Charme, und wie er richtigerweise schreibt sollte es durch die Einbeziehung der Stakeholder in Sprint Reviews und anlassbezogene Meetings ohnehin gegeben sein. Die Frage für mich ist aber: hat eine derartig vergrösserte Gruppe dann nach die Charakteristiken eines Teams?

Chris Combe: Untangling Organizational Dependencies

Es ist eine Falle in die viele Organisationen getappt sind während sie versucht haben sich in Richtung Agilität zu transformieren - mit der Absicht Bürokratie abzubauen werden mittlere Management-Schichten gestrichen, aber statt die Teams zu befreien werden diese dadurch mit zusätzlicher Abstimmungs- und Koordinationsarbeit überhäuft, die sie jetzt selbst machen müssen. Den Grund darin sieht Chris Combe in einem Denkfehler: der Annahme, dass es sich bei diesen Management-Schichten um Wildwuchs handeln würde, während sie in Wirklichkeit die notwendige Folge einer zu stark arbeitsteiligen Organisation mit Mehrfach-Zuständigkeiten sind. Vor einem Hierarchieabbau empfiehlt er daher mehr Empowerment der Teams.

Robert Galen: Key Differences for Internal vs. External Agile Coaches

In diesem Artikel habe ich vieles aus meinem Arbeitsalltag wiedergefunden, in dem ich als externer Agile Coach immer wieder mit (Kunden-)internen Gegenübern zusammenarbeite. Robert Galen hat eine gute Übersicht über die Unterschiede in Wahrnehmung, Ansehen, Einfluss und weiteren Kategorien zusammengestellt. Was er aufbauend darauf für sinnvoll hält ist die Einbindung beider Typen in den Agile Coaching-Chaptern oder -Gilden von Unternehmen. Die Externen können immer wieder neue Impulse und an anderen Orten gemachte Erfahrungen einbringen, die Internen können langfristig wirken und Netzwerke aufbauen, ausserdem ist durch sie eine langfristige Identifikation mit der Firma gegeben.

Robert Falkowitz: Using 5S to Keep your Kanban Board Organized in Practice

Bei Kunden deren Projekte einen Hardware-Anteil haben bin ich bereits mit 5S in Berührung gekommen, dort wird es u.a. für die Standardisierung, das Aufräumen und das Sauberhalten von Arbeitsplätzen genutzt. Robert Falkowitz schlägt hier einen weiteren Verwendungszweck vor, der bei näherer Betrachtung hochgradig naheliegend ist: den Betrieb von Kanban-Boards. Auch die haben bei nachlässiger Disziplin die Tendenz schnell unaufgeräumt und unübersichtlich zu wirken, genau wie es bei Arbeitsplätzen der Fall ist. Und mit den selben Methoden in denen man dort für Ordnung sorgt können auch Kanban-Boards (wieder) in den Zustand kommen übersichtlich und selbsterklärend zu sein.

Matt K. Parker: Getting Started with Radical Collaboration

Einfache Zusammenarbeit war gestern, jetzt kommt die radikale Zusammenarbeit! Das klingt zwar etwas marktschreierisch, hat aber Substanz. Matt K. Parker versucht unabhängig von den gängigen methodischen Frameworks zentrale Faktoren für die Ein- und Durchführung intensiver Zusammenarbeit zu nennen. Gerade für die den Einsatz bei "Methoden-Muffeln" eine gute Zusammenstellung.

Freitag, 27. Mai 2022

Chaos Engineering

Bild: Public Domain Pictures - CC0 1.0

Unter den verschiedenen agilen Frameworks gehört das Chaos Engineering zu den weniger bekannten, was vermutlich auch so bleiben dürfte. Es gibt keine bekannten Gründer-Figuren wie im Fall von Scrum, keine dahinterstehende kommerzielle Organisation wie im Fall von SAFe und (leider ein wesentlicher Punkt) keine Zertifikate, durch die der agil-industrielle Komplex zu seiner Verbreitung beitragen würde. Dafür hat Chaos Engineering etwas ganz Anderes: praktische Relevanz.


Entwickelt wurde der Ansatz ca. 2010 bei Netflix, dem amerikanischen Video-Streamingdienst. Den Entwicklern dort wurde über die Zeit schmerzhaft klar, dass sie auf ihren Test-Umgebungen weder das Systemverhalten noch das Anwenderverhalten genau so simulieren konnten wie es in der unberechenbaren Realität auftrat. Wiederholt kam es dort daher zu Fehlern. Ihre Lösung: die Verlagerung einer Grossteils der Qualitätssicherung in den Live-Betrieb.


Die dahinterstehende Logik: wenn Störungen der Live-Umgebungen schon nicht zu vermeiden sind, dann sollten sie zumindest schnell entdeckt werden können und sofort behebbar sein. Und wenn möglich sollten Fehler während der Arbeitszeit auftreten, wenn jemand da ist der sie schnell beheben kann und nicht irgendwann in der Nacht. Um das zu erreichen sollten die Systeme tagsüber ständigen Stresstests ausgesetzt werden, um diese Fehler so auslösen und beheben zu können.


Since we knew that server failures are guaranteed to happen, we wanted those failures to happen during business hours when we were on hand to fix any fallout. We knew that we could rely on engineers to build resilient solutions if we gave them the context to expect servers to fail. If we could align our engineers to build services that survive a server failure as a matter of course, then when it accidentally happened it wouldn’t be a big deal. In fact, our members wouldn’t even notice. This proved to be the case.


Der technische Kern des Chaos Engineering ist die so genannte Affen-Armee, eine Gruppe von Programmen die diese Tests durchführen. Die bekanntesten unter ihnen sind der Chaos Monkey, der nach Zufallsprinzip Live-Server kurzzeitig abschaltet und der Chaos Gorilla, der das Gleiche mit ganzen Rechenzentren macht. Darüber hinaus existieren u.a. der Latency Monkey, der Conformity Monkey und der Security Monkey, die meisten von ihnen als Open Source veröffentlicht.


Den Methodischen Rahmen um die Technik bilden die Principles of Chaos Engineering, die ein grober Leitfaden für die Anwendung des Frameworks sind. Im Kern stehen dabei die vier Grund-Prinzipien:

  1. Start by defining ‘steady state’ as some measurable output of a system that indicates normal behavior.
  2. Hypothesize that this steady state will continue in both the control group and the experimental group.
  3. Introduce variables that reflect real world events like servers that crash, hard drives that malfunction, network connections that are severed, etc.
  4. Try to disprove the hypothesis by looking for a difference in steady state between the control group and the experimental group.

Mit anderen Worten: definiere einen messbaren, stabilen Ausgangszustand, lass die Affen-Armee auf ihn los und wenn etwas kaputtgeht finde heraus warum. Wichtig ist an dieser Stelle, dass in diesen Prinzipien von dem bei Netflix im Mittelpunkt stehenden Testen auf der Live-Umgebung noch nicht die Rede ist. Dadurch wird Chaos Engineering auch für kritische Anwendungen nutzbar, etwa den Betrieb von Stromnetzen, die man nicht testweise abschalten sollte.


Für andere Anwendungen, bei denen eine Ausfallzeit von wenigen Sekunden oder Minuten unkritisch ist gibt es die "Advanced Principles", deren Umsetzung schwieriger ist, dafür aber auch einen deutlich  höheren Mehrwert bringt:

  1. Build a Hypothesis around Steady State Behavior.
  2. Vary Real-world Events.
  3. Run Experiments in Production.
  4. Automate Experiments to Run Continuously.
  5. Minimize Blast Radius.

Auch das in vereinfachten Worten: definiere in der Live-Umgebung einen messbaren, stabilen Ausgangszustand, lass die Affen-Armee in immer neuen Variationen auf ihn los und arbeite daran, dass die Auswirkungen immer geringer werden. Der letzte Punkt ist dabei das grosse Ziel - durch immer bessere Ausweichmanismen und immer grösser werdende Unabhängigkeit von Komponenten und Regionen wird die Auswirkung von Fehlern und Ausfällen immer kleiner (hier ein Beispiel).


Wie zu Beginn gesagt, der grosse Hype wird Chaos Engineering nicht werden, dafür ist es für die HR-Ressorts, Unternehmensberatungen und Trainings-Provider zu technisch und zu wenig profitabel. In den meisten Entwicklungseinheiten wird man dagegen auf Interesse oder sogar auf Begeisterung stossen, da dort sofort klar ist welcher Beitrag zu Agilität und Resilienz von diesem Framework geleistet werden kann.

Montag, 23. Mai 2022

Podcasting

Bild: Pixabay / Connie_SF - Lizenz

Wer wissen möchte was ich denke und wie ich schreibe kann das auf dieser Zeite in ausreichendem Ausmass erfahren. Mehrere hundert Texte sind über die Jahre zusammengekommen, das sollte für einen halbwegs soliden Eindruck reichen. Auch wie ich aussehe ist mittlerweile klar, auf mehrfachen Wunsch habe ich auch ein Bild hochgeladen. Nur wie ich mich anhöre blieb unklar - bis dieses Jahr. In den letzten Monaten war ich in zwei Podcasts zu Gast, natürlich auch in Folgen zum Thema Agilität.


Der neuere der beiden Auftritte fand bei den Produktwerkern statt, wo ich mit Oliver Winter über Agilität im Konzern sprechen durfte. Mein Spezialgebiet gewissermassen, den Grossteil meiner Einsätze als Berater, Agile Coach und Scrum Master hatte ich in Banken, Versicherungen, Handelskonzernen und den Herstellern von Strom und Autos. Ohne den Inhalt vorwegnehmen zu wollen - es ist nicht alles so schlimm wie viele denken, in einigen Aspekten ist Agilität im Konzern sogar einfacher als in kleinen Firmen.


Auch der zweite, schon etwas zurückliegende, Podcast-Auftritt dreht sich um dieses Thema. In André Claassens OKR-Podcast habe ich darüber gesprochen welche Metriken man benutzen könnte um in agilen Transitionen nicht nur die Effektivität der Teams zu messen sondern auch die Wirksamkeit des Managements. Das Thema war ursprünglich ein Text auf dieser Seite, daraus wurde später ein Konferenz-Vortrag auf der Manage Agile und darüber dann eine Podcast-Folge bei André.


In meiner Firma haben wir schon mehrfach darüber nachgedacht selbst einen Podcast zu produzieren. Das Thema wäre (Überraschung!) wohl Agilität im Konzern, schliesslich sind auch die anderen in diesem Bereich tätig. Mal sehen ob wir irgendwann dazu kommen.

Donnerstag, 19. Mai 2022

Open Space-Meetups

Bild: Wikimedia Commons / Plain Schwarz - CC BY-SA 2.0

Wer öfter in der agilen Community im Raum Köln/Bonn unterwegs ist wird herausgefunden haben, dass ich hier regelmässig auf verschiedenen lokalen Meetups und Konferenzen anzutreffen bin. Und wer noch genauer hinschaut wird merken, dass die alle eine Gemeinsamkeit haben. Es ist nicht das Thema Agilität (obwohl das zumindest bei den meisten der Fall ist) sondern etwas Anderes: praktische alle Events auf denen man mich trifft sind als Open Space organisiert.


Diese in den 80er Jahren vom Amerikaner Harrison Owen entwickelte Methode ist anders als die meisten anderen, da sie auf zentrale Elemente verzichtet die sonst auf jeder halbwegs organisierten Zusammenkuft anzutreffen sind: es gibt keine vorher feststehende Agenda (mitunter nicht einmal ein festgelegtes Thema), keine Pausen und keine klar erkennbare Trennung zwischen passiven und aktiven Teilnehmern (bzw. Besuchern/Zuhörern und Rednern/Referenten).


Die Inhalte und die Agenda entstehen stattdessen selbstorganisiert. Nach einer kurzen Erklärung des Vorgehens (oft durch eine spontan im Raum ermittelte Person die es kennt) kann jeder vortreten, sein Vortrags- oder Diskussions-Thema vorstellen und es an eine Sammelwand hängen. In einem anschliessenden "Marktplatz" können die Themen Zeit-Fenstern und Räumen zugeordnet und ggf. zusammengelegt werden. Auch das geschieht hierarchiefrei durch eine Gruppendiskussion (wobei Themen nur von ihrem Verfasser bewegt werden sollten). Das Ergebnis sieht dann z.B. so aus:



An diesem Fall (aufgenommen auf dem Scrumtisch Bonn) ist gut zu sehen was im Marktplatz passieren kann: Themen-Zusammenlegungen, Uhrzeit-Änderungen und das spontane Hinzufügen eines weiteren Raumes ("Woanders") um noch ein zusätzliches Thema unterbringen zu können. Auch die einfache und schnelle Organisation mit Flipcharts (oder Wänden), Post-Its und Filzstiften ist typisch, sie ist eine Reminiszenz an die Entstehung des ersten Open Space in einer Kaffeepause einer Tagung.


Während der Vorträge gilt dann das Gesetz der zwei Füsse: jeder Teilnehmer kann und darf jederzeit zwischen den Räumen wechseln egal ob es nur zum Zuhören ist (dann spricht man von einem "Schmetterling") oder um Ideen und Impulse hin- und herzutragen (dann spricht man von einer "Hummel"). Auch das dauerhafte Verbleiben in einem Raum ist aber möglich, und sogar das durchgehende Führen von Spontangesprächen im Flur oder vor der Tür.


Der einzige formale Teil auf den in der Regel geachtet wird ist das Closing am Ende, in dem alle Teilnehmer aus ihren Runden berichten können, wobei es egal ist ob es in diesem Bericht um Ergebnisse, Eindrücke, offen gebliebene Fragen oder neue Erkenntnisse geht. In Firmen-internen (oder aus sonstigen Gründen in langfristige Prozesse eingebundenen) Open Spaces können hier auch Folge-Aktivitäten vereinbart werden, auf Meetups und Konferenzen ist das eher selten.


Warum das Open Space-Format auf die agile Community so anziehend wirkt dürfte offensichtlich sein, in beiden Fällen nimmt die Selbstorganisation von Gruppen einen zentralen Platz ein. Und auch eine problemlose Skalierung ist möglich, neben den Scrumtischen, die hier im Rheinland meistens eine Teilnehmerzahl im niedrigen oder mittleren zweistelligen Bereich haben, ist auch die Agile Cologne-Konferenz mit hunderten Teilnehmern ein Open Space.


Jedem der diese Art von Veranstaltung noch nicht kennt kann ich sie wärmstens empfehlen, sie sind eine beeindruckende Demonstration dessen was Selbstorganisation bewirken kann. Und wer das im Raum Köln/Bonn macht kann sich gerne von mir vor Ort erklären lassen welche vielen weiteren Vorteile sie hat.

Montag, 16. Mai 2022

Esoterik

Bild: Wikimedia Commons / M. Pierre Morissoneau - CC BY 4.0

Für die meisten Menschen dürfte das jetzt überraschend kommen, aber wenn wir über Projekt- oder Produktmanagement sprechen müssen wir uns auch über Esoterik unterhalten. Anders als man denken könnte wird dieser Themenkomplex nämlich nicht nur von harten Zahlen, überprüfbaren Berechnungen und empirischer Kontrolle geprägt, in weiten Teilen ist das genaue Gegenteil der Fall - selbst weitreichende Entscheidungen beruhen auf etwas was man nur als Esoterik bezeichnen kann.


Zum besseren Verständnis eine kurze Begriffserklärung: Esoterik ist ursprünglich vom altgriechischen ἐσωτερικός (Esōterikós) abgeleitet und bedeutet in etwa "nur von innen verstehbar", man könnte es mit "Geheimlehre" übersetzen. In einer moderneren Interpretation versteht man darunter alle möglichen Glaubenssätze die zwar für sich genommen wenig Sinn ergeben, denen aber unterstellt wird, dass das nur daran liegt, dass sie nicht gut genug erklärt oder verstanden wurden.


Derartige Glaubenssätze bestehen sowohl im Umfeld klassischer Management-Lehren als auch in den New Work- und Agile-Bewegungen. Da Menschen aber dazu neigen derartige Phänomene vor allem bei anderen wahrzunehmen und bei sich selbst zu verdrängen (man spricht vom Blind Spot Bias) tritt oft das kuriose Phänomen auf, dass die Vertreter der alten und neuen Vorgehensmodelle sich gegenseitig Esoterik vorwerfen, sich selbst aber als nicht betroffen ansehen.


Ein Beispiel für esoterische Glaubenssätze im klassischen Management ist die Überzeugung, dass Menschen in grossen Organisationen nicht in der Lage sind ohne Anleitung und Überwachung zu arbeiten. Obwohl schon seit Jahrhunderten von der Realität widerlegt bildet sie die Grundlage dafür, dass der Führungsstil des Top-Down-Management immer wieder hartnäckigt verteidigt oder unter neuem Namen wiederbelebt wird (z.B. "Führung" statt "Management").


Auch in den neueren, eher hierarchiefreien Ansätzen kann man Esoterik antreffen, zum Beispiel in Form des umgekehrten Glaubenssatzes, dass man einer Gruppe von Menschen nur Selbstorganisation ermöglichen muss um die optimale Lösung aller Probleme zu erhalten. Dass das ohne Vorbereitung und Begleitung in den vielen Fällen in die Autonomie-Falle oder zu Kompetenzüberschreitungen (mit nachfolgenden Konflikten) führt wird dabei ignoriert oder sogar in Abrede gestellt.


Bei näherer Betrachtung gibt es zahllose weitere Beispiele für esoterische Überzeugungen im Projekt- oder Produktmanagement. Von detaillierten Umsetzungsplänen als Vorbeugung für ungeplante Veränderungen über Retrospektiven als universales Heilmittel für alles bis hin zu "magischen Gegenständen" wie Status-Reports oder Kanban-Boards die alleine durch ihre blosse Existenz schon zu Verbesserung führen sollen.


Dass es sich bei diesen Grundsätzen um Esoterik handelt kann man deutlich an ihrer üblichen Begründung (bzw. Nicht-Begründung) sehen. Statt mit Fakten oder empirischen Belegen wird hier in der Regel mit inneren Erkenntnissen argumentiert die man eben hat oder nicht hat. Im Rahmen eher klassischer Vorgehensweisen ist das "der gesunde Menschenverstand", bei den neueren "das (agile) Mindset". Was genau das ist wird in beiden Fällen praktisch nie erklärt. Es ist einfach da.


Die Realität ist natürlich deutlich komplexer als das. Kein einfacher Glaubenssatz kann die zahlreichen Wechselwirkungen und Dynamiken in grossen Systemen abbilden, alleine deshalb nicht weil es kaum zwei gibt die wirklich gleich sind (selbst bei gleichgrossen Unternehmen des selben Branche). Was stattdessen vorkommt sind Mischtypen und Annäherungswerte, die ständigen Veränderungen unterliegen und daher ständig neu betrachtet und behandelt werden müssen.


Natürlich ist das aufwändiger, anstrengender und verwirrender als die (scheinbar) einfachen Lösungen, die die esoterischen Glaubenssätze bereithalten. Und natürlich wird es immer wieder Menschen geben die diese einfachen Lösungen der komplexen Realität vorziehen (dieser Wunsch nach einfachen Lösungen und Erklärungen ist schliesslich der Grund dafür, dass es Esoterik überhaupt gibt). Das ist auf einer menschlichen Ebene auch verständlich. Nur - zielführend ist es nicht.

Freitag, 13. Mai 2022

Technische Schulden (II)

Bild: Pixabay / Raten-Kauf - Lizenz

Wir müssen noch einmal über das Thema der technischen Schulden sprechen, genauer gesagt über eines der grössten damit verbundenen Probleme: die Unklarheit darüber was mit diesem Begriff eigentlich gemeint ist. Wie bereits gesagt ist nicht jeder Fehler oder jeder Qualitätsmangel im Code automatisch eine technische Schuld, das ist nur dann der Fall wenn diese Missstände bewust in Kauf genommen wurden um ein anderes Ziel zu erreichen. Aber auch das ist noch nicht alles.


Tatsächlich kann es auch technische Schulden geben die nicht bewusst "aufgenommen" wurden sondern mehr oder weniger versehentlich entstanden sind oder von jemand anderem (einem anderen Team, einem Zulieferer, einem aufgekauften Wettbewerber, etc) übernommen wurden. Das Entscheidende ist in diesen Fällen nicht mehr der Entstehungskontext sondern etwas Anderes - der Beschluss die Behebung in die Zukunft zu verschieben.


Um das besser zu verstehen ein kurzer Einschub: eigenlich ist es Best Practice Good Practice Fehler in der Software sofort zu beheben sobald sie entdeckt werden (🡪 Zero Bug Policy). Unterbleibt das besteht ein erhebliches Risiko, dass es zu einem "Jenga-Effekt" kommt: weitere, neue Funktionen bauen (bewusst oder unbewusst) auf den bestehenden, fehlerhaften auf, und wenn diese repariert und dadurch verändert werden stürzt das ganze Konstrukt in sich zusammen.


Es kann  aber Gründe dafür geben diese Reparaturen nicht sofort vorzunehmen, vor allem dann wenn ein wichtiger Liefertermin anliegt und für die entdeckten Fehler ein kurzfristiger Workaround möglich, eine sofortige Behebung dagegen relativ aufwändig wäre. Um den Termin einhalten zu können kann es in solchen Situationen Sinn machen die mit einer späteren Reparatur verbundenen Mehraufwände zu akzeptieren - und genau das ist nichts anderes als das Aufnehmen technischer Schulden.


Ist das ein realistisches Szenario? Es kommt darauf an, wie so oft. Bei stabilen Teams die langfristig an einem Produkt arbeiten ist diese Art der technischen Schuld eher ein Ausnahmefall, in Organisationen in denen Software in einer Abfolge von Projekten mit wechselnder Personalbesetzung entwickelt wird ist es eher die Regel, genauso in Systemlandschaften mit vielen Legacy-Anwendungen. Und seien wir ehrlich, die beiden letzten Typen sind in Konzernen der Normalfall.


Das Ergebnis dieser "Normalität" ist eine Art von Generationenvertrag - die aktuelle Entwicklergeneration hält ihre Systeme durch die Aufnahme technischer Schulden irgendwie am Laufen und kann sie so (mehr oder weniger) funktionierend an ihre Nachfolger übergeben, die dann vor der Wahl stehen sie in Form von Reparatur- und Aufräumarbeiten abzubezahlen oder noch mehr aufzunehmen und das Problem an die übernächste Generation weiterzugeben.


Und nochmal, auch dieses Weitergeben von immer schlimmer werdenden technischen Schulden über mehrere Generationen hinweg ist leider nicht unrealistisch, verbunden mit Wassermelonen-Projekten und Arschkarten-Lücken tritt es immer wieder auf. Um aber auch die andere Option zu nennen: ich habe es auch erleben dürfen, dass "geerbte" technische Schulden nach und nach abgebaut wurden. Das war anstrengend und fühlte sich ungerecht an, dafür wurde ab diesem Zeitpunkt alles wieder leichter.

Dienstag, 10. Mai 2022

Agilität, dort wo man sie nicht vermutet (II)

Bilder: Wikimedia Commons / Lambert van Kleef / U.S. Information Agency - Public Domain

Zu den Texten von mir die auch nach Jahren noch zuverlässig Diskussionen und Unglauben auslösen gehört Agilität, dort wo man sie nicht vermutet, in dem ich erwähnt habe, dass ich in einer deutschen Behörde agile Arbeitsweisen vorfinden konnte (wenn auch unter anderen Namen). Die bei den meisten Menschen verbreiteten Vorstellungen der Art wie dort gearbeitet wird gehen anscheinend komplett in die andere Richtung. Aber - sind staatliche Verwaltung und Agilität tatsächlich solche Gegensätze?


In Diskussionen zu diesem Thema mache ich mittlerweile zu Beginn eine noch weitgehendere Aussage: die ersten Organisationseinheiten die im modernen Europa agil gearbeitet haben waren Teile der staatlichen Verwaltung. Und nicht nur das, viele dieser Einheiten haben diesen Arbeitsmodus bis heute durchgehend beibehalten und setzen ihn mindestens genauso konsequent um wie die an den modernen agilen Frameworks orientierten Softwareentwicklungsteams.


Ein erstes Beispiel dafür ist die preussische Armee, die im 19. Jahrhundert die Auftragstaktik einführte, bei der zwar übergreifende Ziele vorgegeben werden, für deren Umsetzung die einzelnen Einheiten aber autonom vorgehen können. Dieser Führungsstil wurde später von fast allen westlichen Armeen übernommen und beibehalten, u.a. ist er anscheinend ein zentraler Grund für die Erfolge der ukrainischen Armee gegen die im Frühling 2022 gestartete russische Invasion.


Ein zweites Beispiel sind die modernen Berufs-Feuerwehren, die erstmals im 17. Jahrhundert in Wien gegründet wurden und sich im Folgenden überall in Europa und Amerika und später im Rest der Welt etablierten. Die Löschzüge als kleinste Feuerwehr-Einheit haben von Beginn an alle Charakteristiken agiler Team gehabt: klein, crossfunktional, im Brandfall zu schnellen Reaktionen in der Lage, autonom und selbstorganisiert (zumindest während der Einsätze).


Ein weiterer Fall sind die Teams in den Notaufnahmen und Operationsräumen der modernen Krankenhäuser, die ebenfalls seit dem 17. Jahrhundert in Europa entstanden sind. Auch sie sind klein, crossfunktional, reaktionsfähig, autonom und selbstorganisiert. Eine andere Arbeitsweise wäre auch nicht vorstellbar, im Fall von Herzstillständen oder akuten Blutungen würden Befehlsketten oder Aufgabenteilung schliesslich den Tod der Patienten zur Folge haben.


Es liessen sich noch weitere Beispiele finden, vom Katastrophenschutz über die Stromnetz-Dispatcher, die Presse-Referate und die Einsatzgruppen der Polizei bis zur Flugverkehrskontrolle, die zentrale Erkenntnis ist aber klar: dort wo Dezentralisierung, Selbstorganisation, Autonomie, und Reaktionsgeschwindigkeit von Bedeutung sind ist auch (und gerade!) die staatliche Verwaltung dazu in der Lage, und das nicht nur seit Kurzem sondern bereits seit Jahrhunderten.


Dass es auf der anderen Seite auch viele schwerfällige, bürokratische, unnötig hierarchische und unflexible Stellen in der staatlichen Bürokratie gibt stimmt natürlich auch, und bemerkenswerterweise sind einige der im Einsatz mustergültig agilen Einheiten ausserhalb der Einsätze das genaue Gegenteil. Klar ist aber: die von vielen Menschen angenommene Unvereinbarkeit der öffentlichen Verwaltung mit agilen Arbeitsweisen ist falsch. Man muss nur genauer hinsehen.

Freitag, 6. Mai 2022

Scaling with Scale-free Networks

Mal wieder ein origineller Blick darauf wie in Organisationen Agilität skaliert werden kann. Die hier von Jim Coplien vorgetragene Sichtweise beruht auf der Idee, dass in einem weitgehend hierarchiefreien System netzwerkartige Verbindungen zwischen den einzelnen Einheiten bestehen, die auf den jeweils kommunikativsten Teammitgliedern beruhen. Diese bilden die Knotenpunkte eines organisationsweiten Netzwerks und formen gleichzeitig mit ihren weniger kommunikativen Kollegen kleinere lokale Netzwerke, in denen jeweils die Wertschöpfung stattfindet.



Was Copliens Ausführungen besonders macht ist ihre wissenschaftliche Fundierung. Seit den frühen 90er Jahren erforscht er Organisationen und verdichtet die in diesem Rahmen erhobenen Daten zu wiederkehrenden Mustern. Das auch auf die eigene Organisation anzuwenden könnte spannend sein, das Tool stellt er zur Verfügung.

Dienstag, 3. Mai 2022

Der Sog der Addition

Bild: Wikimedia Commons / Tony Hisgett - CC BY 2.0

Jeder der mit einer Gruppe von "Agilisten" zu tun hat, von der Scrum Master-Gilde eines beliebigen Unternehmens bis hin zu den Teilnehmern eines beliebigen Agile Meetups, kann einen Versuch wagen: wenn man mit den Gruppenmitgliedern in den Gedankenaustausch geht über die Themen für deren Verwirklichung sie sich einsetzen - werden alle von ihnen einen wirklichen Agilitäts-Bezug haben? Die Antwort ist in den meisten Fällen nein, und dafür gibt es auch Gründe.


Bevor wir auf diese eingehen eine kurze Erklärung: Agilität im Sinn der Verfasser des Agilen Manifests dreht sich um eine schnelle Liefer- und Reaktionsfähigkeit in der Produktentwicklung. Das Verständnis das man in Firmen und Communities antrifft umfasst oft wesentlich mehr: Innovations- und Kreativitäts-Förderung, Diversität, Inklusion, New Work (was auch immer darunter verstanden wird), betriebliche Mitbestimmung, Ablehnung bestimmter Management-Praktiken und vieles mehr.


Die Ursache für dieses Phänomen liegt darin, dass die Vertreter der agilen Arbeitsweisen zu Beginn ihrer Tätigkeiten meistens eine kleine Minderheit sind und später zwar zahlreicher werden, in vielen Fällen aber in die Thukydides-Falle tappen und sich einen Abnutzungskampf mit den Vertretern des "klassischen Managements" liefern. Um Gehör und Mehrheiten für ihre Ideen zu finden liegt es daher nahe Koalitionen mit den Vertretern ähnlicher Ideen einzugehen.


Diese Koalitionen kommen allerdings mit einem Preis: um für ihre verschiedenen Fraktionen attraktiv zu sein muss jede von ihnen bereit sein die Interessen des jeweils anderen zu unterstützen. Bedingt dadurch weitet sich das Themenspektrum der "agilen Bewegung" - zu dem Wunsch nach schlankeren und flexibleren Strukturen kommt z.B. der nach neuen Produktideen, einem Recht auf Heimarbeit oder der Förderung gesellschaftlicher Minderheiten.


Zu Beginn haben diese zusätzlichen Themen in der Regel noch gemeinsame Schnittmengen mit der Agilität, irgendwann kann die Koalition aber so gross werden, dass Teile von ihnen Ziele aus völlig anderen Bereichen verfolgen und auf die gemeinsame Agenda setzen, z.B. Anti-Kapitalismus.1 Der Soziologe Sven Hillenkamp, der derartige Tendenzen in der Klima-Bewegung untersucht hat, nennt sie den "Sog der Addition", durch den immer weitere Ziele entstehen und ggf. sogar die alten überlagern.


Eine derartige fortlaufende Erweiterung des Themenspektrums hat Folgen: zum einen kommt es zu der zu Beginn beschriebenen Begriffsüberfrachtung, durch die es immer unklarer wird was eigentlich gemeint ist wenn jemand den Begriff der Agilität benutzt. Zum anderen werden die Vertreter des agilen Vorgehens in Konflikte hineingezogen an denen sie eigentlich gar nicht interessiert sind, z.B. zwischen dem Top-Management und dem Betriebsrat.


Um sich nicht in derartigen, für das eigene Anliegen eigentlich unwichtigen, Konflikten aufzureiben und um dieses eigene Anliegen wieder klarer und trennschärfer beschreiben zu können, macht es Sinn regelmässig zu überprüfen ob die Koalition in der man als agile Bewegung gelandet ist noch immer die Richtige ist oder ob es eine nicht länger nötige Zweckgemeinschaft war. Ein Beispiel: man mag den Kampf für mehr Home Office für sinnvoll halten, zwingend verbunden mit Agilität ist er aber nicht.


Natürlich kann eine derartige Refocussierung zu Streitigkeiten und Trennungsschmerzen führen, schlimmstenfalls verbunden mit persönliche Zerwürfnissen zwischen Kollegen und Freunden. Dieser Schritt sollte also nicht unüberlegt gegangen werden. Wird er vermieden sollte man sich allerdings der oben genannten Konsequenzen bewusst sein und diese intern thematisieren. Und ganz im Sinne von Inspect & Adapt sollte das Thema regelmässig auf die Wiedervorlage.



1Ja, es gibt starke antikapitalistische Tendenzen in der agilen Bewegung. Wer es nicht glaubt kann auf dem nächsten agile Meetup in seiner Gegend versuchen über Manager oder Shareholder Value zu diskutieren und sich überraschen lassen was passiert.

Samstag, 30. April 2022

Kommentierte Links (LXXXVII)

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.

Tim Ottinger: Story Points - Why is this so hard?

Diesem Blogeintrag muss man ein bisschen Kontext vorausschicken. Sein Autor Tim Ottinger arbeitet bei Industrial Logic, der Firma bei der Modern Agile entstanden ist. Die mit diesem Framework verbundene Abneigung gegen die Prozess-Elemente von Scrum und Extreme Programming spürt man auch in dem Text, allerdings (und das ist wichtig) auf eine sehr differenzierte Art und Weise. Ottinger arbeitet heraus wie Story Points funktionieren, welche Probleme er bei ihrer Umsetzung beobachtet, welche Schlüsse er daraus zieht und welche Alternativen er vorschlägt. Man kann in ihnen spürbare Parallelen zu #NoEstimates erkennen.

John Cutler: We Need Someone Who Has Done "It" Before

"Wir brauchen jemanden der so etwas schonmal gemacht hat" ist eine Aussage die man häufig hören kann wenn es darum geht das Team für ein schwieriges Vorhaben zusammenzustellen. Was genau mit diesem "so etwas" gemeint ist kann aber oft sehr unklar sein, sogar innerhalb der Gruppe in der diese Aussage geäussert wird. John Cutler versucht hier zu auszudifferenzieren welche verschiedenen Deutungen möglich sind und zu welchen Problemen es führen kann wenn jeder der Beteiligten zwar eine ungefähre Vorstellung davon hat was er selbst damit meint, er es aber den anderen nicht nachvollziehbar erklären kann.

Pim de Morree, Joost Minnaar: 10 Progressive Organizational Structures Developed By Real Companies

Dass viele erfolgreich agil arbeitende Organisationen sich früher oder später von den bekannten Frameworks verabschieden und ihre eigenen Vorgehensmodelle entwickeln ist kein Geheimnis, einige Fälle wie z.B. die von Youtube und Spotify haben einen grossen Bekanntheitsgrad erlangt. Viele weitere Fälle sind aber weitgehend unbekannt, nicht zuletzt deshalb weil ihre charakteristischen Elemente in der Regel intern nicht als etwas Besonderes wahrgenommen und daher nicht gross kommuniziert werden. Pim de Morree und Joost Minnaar stellen einige von ihnen aus Unternehmnen rund um die Welt vor.

Melanie Brucks & Jonathan Levav: Virtual communication curbs creative idea generation

Wer hier schon länger mitliest kennt meine Meinung zu Remote-Arbeit. Sie kann gut funktionieren, ist manchmal nicht zu vermeiden und in vielen Firmen definitiv besser als das was man vor Ort als Arbeitsbedingungen in den firmeneigenen Büros vorfinden würde. Gleichzeitig hat sie aber auch viele entscheidende Nachteile, über die häufig zu schnell hinweggegangen wird wenn es darum geht über den Arbeitsort zu entscheiden. Der den Melanie Brucks und Jonathan Levav in ihrer Forschungsarbeit identifiziert haben gehört dazu - Kreativarbeit ist im Rahmen virtueller Zusammenarbeit deutlich schwerer als in Präsenz.

Emanuel Kessler: Kein Zeitpuffer, kein Problem?

Als jemand zu dessen täglicher Arbeit ganz wesentlich die Wissensvermittlung gehört freue ich mich immer darüber wenn jemand eine neue Möglichkeit findet relevantes Wissen mit Hilfe von Pop-Kultur, Sport oder bekannten Konzepten zu erklären. Was Emanuel Kessler für Golem verfasst hat ist ein schönes Beispiel dafür: die Konsequenzen des Fehlens eines Zeitpuffers, erklärt anhand der Fersehserie "Star Trek - Lower Decks". Nicht nur für Trekkies zu empfehlen.