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.