Kommentierte Links (LXVI)

Bild: Unsplash / Dayne Topkin - Lizenz

Kent Beck: Oh The Messes We Will Make

Ein guter Opener ist bekanntlich alles, und der hier verlinkte Text hat einen besonders schönen. In nur 70 Worten erklärt Kent Beck einen psychologischen Fachbegriff (Ataxophobie), lässt beiläufig fallen, dass er Extreme Programming erfunden hat, macht klar welche Hoffnungen er damit verbunden hatte und verteidigt seinen Status als grimmiger alter Mann der Agilität einmal mehr durch das schöne Bonmont, dass Software nur drei Zustände kennt: desaströs, desaströs und unbenutzt. Es gibt dann noch die Erklärung was die drei klassischen Phasen des Extreme Programming sind, warum in ihnen zwangsläufig Unordnung entehen muss und warum das natürlich und behebbar ist. Und wer danach noch immer nicht genug hat kann bei Ron Jeffries weiterlesen, der das Ganze auf seinem Blog nochmal weiterführt.

Fagner Brack: Specialisation Is The Root Of All Evil

Das hier ist streckenweise etwas technisch, aber der Löwenanteil der agilen Produktentwicklung findet nun mal in der IT statt. Die Botschaft die Fagner Brack hier vermitteln möchte dürfte aber auch in jedem anderen komplexen Umfeld zutreffen: dort wo eine zu starke Spezialisierung von Arbeit stattfindet sind böse Überraschungen im wahrsten Sinn des Wortes vorprogrammiert und tauchen mit unschöner Zuverlässigkeit immer dann auf wenn die Spezialisten-Teilprodukte zusammengefügt werden. Um dem entgegenzuwirken sind Generalisten gefragt, und zwar laut Brack nicht solche die alles können (was unmöglich ist) sondern solche die in der Lage sind herauszufinden welches Wissen sie sich wann zu welchem Zweck aneignen müssen. Ein interessanter (und im Gegensatz zum üblichen Klischee auch umsetzbarer) Blick auf den mythischen "Fullstack-Developer".

Alex Ballarín: Time to say goodbye to Dual Track Agile?

"Dual Track Agile" (zwei parallel laufende und jeweils in sich agil organisierte Stränge für Product Discovery und Product Delivery) gilt für den einen oder anderen als die geheime Zutat für erfolgreiche Produktentwicklung. Das ist auch nicht grundlegend falsch, je nach Kontext kann dieses Vorgehen durchaus Sinn machen. Was Alex Ballarín hier zurecht anmerkt ist aber, dass sich dieses Vorgehen in der Praxis fast immer zu kleinen Wasserfallstrukturen entwickelt, mit allen Nachteilen die damit verbunden sind: langen Lieferzyklen, schlechten Sprintzielen, demotivierten Entwicklern und reduzierten Lerneffekten. Was ihm im Folgenden hoch anzurechnen ist - er stellt nicht einfach ein Idealbild als Gegenentwurf auf sondern er erklärt auch warum das so schwer umzusetzen ist - und wie es vielleicht doch geht.

Roman Pichler: Prioritising a Product Backlog When Everything is Important

Für viele Product Owner eine bekannte Situation: der Auftraggeber will aus einem riesigen Wunschkorb alles haben und für ihn ist auch alles gleich wichtig, so dass es zunächst unmöglich erscheint ein priorisiertes Backlog zu erstellen. Roman Pichlers (verkürzte) Anleitung zur Auflösung dieses Dilemmas: die (Nutzer-)Zielgruppe identifizieren, deren Bedürfnisse feststellen, davon die Dringendsten auswählen und damit anfangen. Das klingt erstmal einfach, dürfte in meiner Erfahrung zuerst zu einer weiteren Erkenntnis führen - hinter einem (zu) grossen Anforderungsumfang steckt sehr häufig eine unklare Vorstellung vom eigenen Kunden. Wenn das der Fall ist macht es Sinn damit anzufangen die zu schärfen und erst danach über die Backlog-Priorisierung nachzudenken.

Dilbert: Applying Math To Guesses [Edit: Link ist mittlerweile tot]

Dass Scott Adams es auch nach über 30 Jahren und tausenden von Comic Strips noch schafft den gelegentlichen Wahnsinn von Konzern-Jobs auf den Punkt darzustellen ist bewundernswert. Diesesmal geht es um die Angewohnheit, Prognosen zu unprognostizierbaren Sachverhalten zu verlangen. Und genau so wie hier beschrieben kommt es jeden Tag irgendwo vor.

Regression zum Rand

Grafik: Pixabay / Mediamodifier - Lizenz

Ein Hoch auf die Wissenschaft! In diesem Fall ein weiteres mal auf den Oxford-Professor Bent Flyvbjerg, über den ich bereits vor mehreren Jahren etwas geschrieben habe. Flyvbjerg hat sich scheiternde Grossvorhaben als Forschungsgegenstand ausgewählt und publiziert viele lesenswerte Veröffentlichungen zu diesem Thema. Die um die es heute gehen soll definiert eine neue Regel: The Law of Regression to the Tail, zu deutsch Das Gesetz der Regression zum Rand (hier der Link zu einer Zusammenfassung).

Um zu verstehen was damit gemeint ist zunächst ein kurzer Exkurs zu einer anderen Gesetzmässigkeit, dem Gesetz der Regression zur Mitte. Erstmals nachgewiesen 1877 vom britischen Wissenschaftler Francis Galton besagt es, dass nach einem extrem ausgefallenen Messwert die nachfolgende Messung meistens wieder näher am bisherigen Durchschnitt liegt¹. Es gibt also eine natürliche (und statistisch belegbare) Tendenz zum Ausgleich und zum Durchschnittswert, die sich als Grundlage für Prognosen und Planungen nutzen lässt.

Zurück zu Flyvbjerg. Seine These ist, dass das Gesetz der Regression zur Mitte in wichtigen Fällen nicht anwendbar ist, und zwar immer dann wenn extrem ausgefallene Messwerte in hoher Frequenz auftreten. Die dahinterliegende Erklärung: da sich mit der Frequenz auch die Varianz erhöht (also die Spanne innerhalb der etwas noch als durchschnittlich gilt) liegen irgendwann auch Extremwerte im Durchschnittsbereich, wodurch die Regression zur Mitte nicht mehr stattfindet.

Darauf aufbauend geht Flyvbjerg noch einen Schritt weiter: wenn eine steigende Frequenz extremer Ereignisse die Varianz so erhöht, dass irgendwann alle Werte im Durschnitt liegen, und wenn ein Durchschnitt per Definition immer das ist was zwischen den Extremwerten liegt, dann ist es zwangsläufig, dass es regelmässig zu immer höheren Extremwerten kommen muss. Diese Umkehrung der Regression zur Mitte nennt er das Gesetz der Regression zum Rand.

Das Auftreten dieser Gesetzmässigkeit verortet er vor allem in seinem eigenen Forschungsgebiet, also bei scheiternden Grossvorhaben. Bei insgesamt 10 Arten von Extremvorfällen erkennt er eine so starke Regression zum Rand, dass sich sämtliche vorbeugenden Gegenmassnahmen regelmässig als unzureichend erweisen: Erdbeben, Cyberkriminalität, Kriege, Pandemien, Kostenexplosionen in IT-Projekten, Überflutungen, Pleitewellen, Feuerkatastrophen, Kostenexplosionen globaler Sport-Events und grossflächige Stromausfälle.

Er belässt es aber nicht bei dieser Analyse sondern nennt auch vier Gegenmassnahmen die sich in seiner Forschung als sinnvoll erwiesen haben: frühzeitige Planung der voraussichtlich nötigen Schadensbegrenzung, vorbeugende Massnahmen zur Begrenzung des Schadensumfangs, Evaluierung theoretisch möglicher "extremer Extremvorfälle" und Aufbau von Strukturen die bei Bedarf zu schnellen und umfassenden Reaktionen in der Lage sein können.

Flyvbjergs Empfehlungen mögen naheliegend erscheinen, üblich sind die aber nicht, zumindest nicht alle. Während die ersten beiden dieser Gegenmassnahmenauch im klassischen Projektmanagement zum Standard gehören sind die beiden anderen seltener vorzufinden. Das heisst aber nicht, dass es sie nicht gibt - für die Evaluierung extremer Extremvorfälle gibt es bereits mehrere Ansätze und für ein Vorgehen schneller Reaktionsfähigkeit sogar einen der sich durchgesetzt hat: Agilität.

Siehe auch:

Regression zum Rand II

¹Das gilt natürlich nur wenn die gemessene Entwicklung nicht gesteuert oder beeinflusst wird.

Digitalisierung (IV)

Bild: Pixabay / Joshua Woroniecki - Lizenz

Die Faszination an der Tatsache, dass es in vielen Unternehmen auch im zweiten Jahrzehnt des 21. Jahrhunderts noch Digitalisierungsprojekte gibt hat schon zu einigen Artikeln auf dieser Seite geführt. Dass noch weitere dazukommen werden ist absehbar, zu vielschichtig sind die Gründe die zu immer neuen derartigen Vorhaben führen. Der um den es heute gehen soll wurde bereits 2015 beschrieben, mit einem Satz der seitdem in der IT-Branche zu einem geflügelten Wort geworden ist:

"Wenn sie einen Scheißprozess digitalisieren, dann haben sie einen scheiß digitalen Prozess."

Thorsten Dirks, Vorstandsvorsitzender der Telefónica Deutschland, auf dem Wirtschaftsgipfel der Süddeutschen Zeitung

Was Thorsten Dirks mit dieser leicht obszönen Ausdrucksweise hervorheben wollte ist einer der grössten Fehler den man bei Digitalisierungsprojekten machen kann (der aber trotzdem immer wieder gemacht wird) - die Eins zu Eins-Übertragung eines bisher analogen Arbeitsablaufs in eine digitale Form. Warum das ein Fehler ist lässt sich an einem einfachen Beispiel aufzeigen.

Stellen wir uns den Posteingang eines grossen Unternehmens vor. Sämtliche eingehenden Briefe werden von der Zentral-Poststelle nach Ressort sortiert, dann von den Ressort-Poststellen nach Priorität sortiert und dann zur Bearbeitung den Fachreferaten übergeben. Nach einem Digitalisierungsprojekt werden eingehende Emails in der Zentral-Poststelle nach Ressorts sortiert, dann von den Ressort-Poststellen nach Priorität sortiert und dann zur Bearbeitung den Fachreferaten gemailt.¹

Zwei Dinge sind an diesem Beispiel zu beachten: zum einen war bereits der ursprüngliche, analoge Prozess offensichtlich schlecht designed. Mit den beiden verschiedenen Poststellen wies er gleich zwei Flaschenhälse auf, dazu kommt, dass die ohne Abstimmung mit den Fachreferaten vorgenommene Priorisierung das Risiko von Fehl-Optimierungen erhöhte. Und zum anderen wurden die Schritte dieses Prozess durch die Digitalisierung nicht verändert sondern nur in ein anderes Medium übertragen.

Eine Digitalisierung derartiger Abläufe kann zwar in überschaubarem Rahmen für Beschleunigung sorgen (Emails sind schneller als Briefe), das mögliche Potential wird dadurch aber nur in Ansätzen ausgeschöpft. Wesentlich weiter kann man kommen wenn auch das grundlegende Prozessdesign neu gedacht wird. Gerade die Bearbeitungsschritte die in der analogen Welt noch nicht möglich waren sind es schliesslich, die die grösste Wirkung entfalten können.

Noch einmal zurück zum Beispiel des Grossunternehmens-Posteingangs. Er könnte so umgestaltet werden, dass die Fachabteilungen von aussen kommende Mails direkt empfangen können², durch KI könnte bei zentral eingehenden Mails automatisiert erkannt werden wo sie hingehören und die Priorisierung könnte im Rahmen gemeinsamer Arbeit an geteilten Dokumenten erfolgen auf die jeder zugreifen kann.

Vermutlich würde hier eine begriffliche Differenzierung Sinn machen. Neben der Digitalisierung im engeren Sinn (der Umwandlung bestehender Prozesse) könnte die digitale Neugestaltung von Prozessen gestellt werden. Digitalisierungsvorhaben wären beide, der zweite Typ hätte aber einen wesentlich höheren Wirkungsgrad.


¹Dieses Beispiel ist von einem real existierenden Fall inspiriert
²Das ist in manchen Konzernen tatsächlich nicht möglich

The Evolution of Enterprise DevOps

Das was Graham Zabel hier bietet ist ein interessanter Einblick in die Art wie in Konzernen DevOps betrieben wird. Angefangen von eher inoffiziellen und anarchischen Anfängen über die "historisch gewachsene" Gegenwart bis zu den regulierten und komerziell getriebenen Ansätzen die sich langsam ausbreiten. [Edit: das ursprüngliche Video wurde gelöscht, das hier ist eine Aufnahme eines weitgehend ähnlichen Vortrags von ihm]

Was man noch ergänzend erwähnen sollte: so richtig und sinnvoll diese Entwicklung aus betriebswirtschaftlicher und IT-Sicherheits-Sicht auch sein mag - es besteht das Risiko, dass es als "Kollateralschaden" zu dogmatischen Vorschriften und bürokratischen Genehmigungsverfahren kommt. Die Konzerne die sich auf diesen Weg begeben wären daher gut beraten, wenn sie auf dieser Entwicklung ein Auge haben würden.

Agile HR on a Poster

Das ist doch mal eine schöne Übersicht. Meine erste Überlegung war zwar ob das nicht eher Agile allgemein als Agile HR ist, aber das würde in die (zu grosse) Debatte führen was HR eigentlich sein soll und will. Was mir besonders gefällt ist der breite Überblick über viele verschiedene Aspekte, der gute erste Einblicke gibt, auf der anderen Seite aber auch erkennen lässt, dass es noch einen grossen vertiefenden Wissensfundus gibt den man erkunden kann.

Bild: Dandy People - CC BY-SA 4.0 (zum Vergrössern klicken, Download hier)

Und natürlich werden hier auch einige Reflexe getriggert. Oben bei Spotify und SAFe habe ich kurz den Atem angehalten, unten bei Cynefin und Modern Agile war ich dann wieder positiv überrascht. Es dürfte für jeden etwas dabei sein.

Das agile Mindset (eine Dekonstruktion)

 

Grafik: Pixabay / Geralt - Lizenz

Dafür, dass das Konzept des "Agilen Mindset" eines ist das häufig genannt und häufig für zentral erklärt wird ist es erstaunlich umstritten. Für die einen ist es die unabdingbare Voraussetzung für jegliche Art des agilen Arbeitens, für andere eher eine esoterische Nebelkerze, die geworfen wird um nicht über die wirklich wichtigen Themen reden zu müssen. Was beide Sichten gemeinsam haben ist aber, dass es hochgradig unklar bleibt was eigentlich gemeint ist wenn dieser Begriff fällt. Höchste Zeit ihn auseinanderzunehmen und einen Blick auf die darin verborgenen Bestandteile zu werfen. Hier sind sie, gesammelt mit einer Kernfrage im Hintergrund - was muss gegeben sein um in kurzen Zyklen reaktions- und lieferfähig (→ agil) zu sein?

Offenheit

Der vermutlich offensichtlichste Bestandteil. Ohne eine grundlegende Offenheit für Neues wird man sich schwer damit tun den initial gefassten Plan ständig zu überprüfen und an die sich ändernde Realität anzupassen. Grundlage dafür ist ein noch fundamentaleres Phänomen, das "Growth Mindset". Es zeichnet die Menschen aus die sich über Überraschungen, neue Herausforderungen und neu zu lernende Themen freuen, statt sie als Belastung zu empfinden ("Fixed Mindset").

Systemisches und analytisches Denken

Ebenfalls fundamental ist die Fähigkeit und Bereitschaft systemisch zu denken. Die Ursache der Komplexität (zu deren Bewältigung die agilen Ansätze entwickelt wurden) sind die unvorhersehbaren Interaktionen der verschiedenen Teil- und Umgebungssysteme. Um auf die Folgen dieser Interaktionen gegebenenfalls schnell reagieren zu können ist es nötig diese Systeme und ihre Beziehungen untereinander identifizieren und analysieren zu können.

Zahlengetriebenheit

Gerade bei Analysen komplexer Zusammenhänge sind es vor allem Zahlen (und deren Veränderungen) die analysiert werden müssen, da Einzelfälle bestenfalls anekdotische Evidenz liefern. Alleine das zu erkennen ist ein wichtiger Schritt, weitere bestehen darin zu erkennen welche Zahlen in welchem Kontext Sinn machen (und in welchem nicht), wie sie erhoben werden können, wozu sie genutzt werden können und wie hoch der damit verbundene Aufwand ist.

Kunden- und Zielgruppenorientierung

Agilität bedeutet auch, die Menschen für die man arbeitet immer besser zu verstehen zu wollen um die Interaktion mit ihnen ständig optimieren zu können. Was sind die Bedürfnisse und Nutzungsgewohnheiten, wie schnell und in welcher Frequenz werden neue und verbesserte Angebote gebraucht, wie werden sie angenommen, wie wird das Feedback eingesammelt und wie fliesst es in das weitere Vorgehen ein? Diese Fragen müssen regelmässig gestellt werden.

MVP-Orientierung

Ein dem Kundenkontakt vorgelagerter Perfektionismus kann alles langsam und teuer machen, da durch ihn die Nutzer- und Auftraggeber-Rückmeldungen erst spät erfolgen und es erst zu spät klar wird wenn irgendwo am Bedarf vorbeiproduziert wurde. Besser ist es auf Minimum Viable Products (MVPs) zu vertrauen, rudimentäre aber bereits benutzbare Früh-Versionen, mit denen bereits Feedback eingeholt und in die Weiterentwicklung integriert werden kann.

Nachholender technischer Perfektionismus

Das unverzichtbare Gegenstück zur MVP-Orientierung. Da diese immer wieder dazu führt, dass Ideen "quick and dirty" umgesetzt werden (was erwünscht ist!) besteht immer wieder die Notwendigkeit diejenigen unter ihnen die von den Nutzern angenommen wurden zu überarbeiten um so die unkomplizierte technische Verständlichkeit, Wartbarkeit und Weiterentwickelbarkeit sicherzustellen. Wird das unterlassen wird alles schwerfällig und langsam, also un-agil.

Verantwortlichkeits- und Delegationsbereitschaft

Zu den grundlegenden Voraussetzungen schneller Kommunikations- und Reaktionsfähigkeit gehört die Abwesenheit grosser oder komplizierter Hierarchien, die den Fluss von Informationen und Entscheidungen verlangsamen und (unabsichtlich) verfälschen würden. Um diese Abwesenheit zu ermöglichen ist es zum einen nötig Informationszugänge und Entscheidungskompetenzen "nach unten" zu verlagern, zum anderen aber auch, dass diese Verantwortungen dort angenommen werden.

Teamfähigkeit

Ein scheinbar einfacher Begriff, hinter dem aber mehr steckt. Teamfähigkeit beschreibt nicht nur die Bereitschaft mit anderen zusammenzuarbeiten sondern im agilen Kontext auch sich als Gruppe so weiterzuentwickeln, dass Crossfunktionalität gegeben ist, dass die Kommunikation effizient ist, dass Flaschenhälse abgebaut werden und dass eine Verantwortlichkeits-, Produktivitäts- und Kreativitäts-fördernde Atmosphäre entsteht.

Transparenz und Ehrlichkeit

Zwei Eigenschaften die beide auf das selbe Ziel einzahlen - die anderen Menschen sollen nicht gezwungen sein nach versteckten und verschwiegenen Informationen suchen zu müssen und sie schlimmstenfalls erst zu spät zu finden. Beides würde entweder zu Verzögerungen führen oder dazu, dass Fehler zu spät erkannt und aufwändig korrigiert werden müssen, schlimmstenfalls mit Auswirkungen auf Qualität und Kundenzufriedenheit.

Humanismus

Ein Wesenszug der meistens (oft unter anderen Namen) zuerst genannt wird steht hier bewusst ganz unten. Um Missverständnisse zu vermeiden - Vertrauen, Empathie, Wertschätzung, Integrität, Augenhöhe und Ähnliches sind grundsätzlich richtige und wichtige Dinge um die sich jeder Mensch bemühen sollte. Zum agilen Mindset gehören sie aber nur, weil sie für einige der zuvor genannten Punkte eine notwendige Voraussetzung sind. Wir können uns glücklich schätzen, dass sie dazugehören, in diesem Kontext sind sie aber nur Mittel zum Zweck. Und Vorsicht ist geboten: dort wo dieses Mittel selbst zum Zweck wird, ist das Agile Mindset zu genau dem esoterischen Konstrukt geworden das es eigentlich nicht sein will. Denn das muss klar sein - in kurzen Zyklen reaktions- und lieferfähig zu sein wird nur durch die Gesamtheit aller zuvor genannten Eigenheiten gewährleistet, aber nicht bloss dadurch dass man sich menschlich verhält.

Sense of Urgency (II)

Bild: Pixabay / Sasint - Lizenz

Einige weitere Gedanken zum Sense of Urgency. Zuerst noch einmal kurz zusammengefasst: es handelt sich bei ihm um eine Wahrnehmung von unmittelbarem Handlungsdruck, beruhend auf sich anbahnenden deutlichen Verschlechterungen bei Nichtstun, und das in einem sehr engen Zeithorizont. Für Veränderungsbemühungen eine ideale Ausgangslage, da nicht mehr diskutiert werden muss ob sich etwas verändern muss sondern nur noch was und wie.

Beruhend darauf geht das klassische Change Management davon aus, das der Sense of Urgency für die Beteiligten und Betroffenen spürbar gemacht werden muss bevor die Veränderungen beginnen. John Kotter (auf dessen Buch der Begriff in seiner heutigen Form zurückgeht) rät z.B. das zu tun indem verfehlte Ziele, unzufriedene Kundenstimmen, frustrierende Mitarbeiter-Erlebnisse, schlechte Zahlen und drohende Konsequenzen öffentlich gemacht werden. Wie das in einem konkreten Fall aussehen kann zeigt anschaulich diese Grafik:

Die Tendenz in diesem Bild ist so offensichtlich, dass der Sense of Urgency den die Besitzer und Mitarbeiter des National Enquirer gerade fühlen dürften sofort nachvollziehbar ist - wenn sich hier nicht sehr schnell und sehr radikal etwas ändert wird von der Auflage dieser Zeitschrift bald nichts mehr übrig sein und sie wird nach fast hundert Jahren aufhören zu existieren. Man kann davon ausgehen, dass beide Seiten zu Anstrengungen und Opfern bereit sein werden.

Auch die umgekehrte Situation ist allerdings immer wieder zu betrachten, dann nämlich wenn das offensichtliche Fehlen einer Notlage dazu führt, dass kein Sense of Urgency entsteht. Ein Beispiel dafür wären etwa die jahrelangen Versuche die Deutsche Bahn zu reformieren. Als staatliche Infrastruktur-Einrichtung waren fehlende Gewinne hier weder ungewöhnlich noch existenzbedrohend, gleichzeitig befand sich die Nachfrage auf einem Höchststand. Viele der Grafiken sahen demnach so aus:

 

Grafik: Wikimedia Commons / MCMC - CC BY-SA 4.0

Auch bei diesem Bild sind die Reaktionen auf Veränderungsprogramme einfach zu erraten, selbst wenn sie diesesmal in eine andere Richtung gehen. Hier soll es einen dringenden Veränderungsbedarf geben, obwohl die Zahlen erkennbar nach oben gehen? Das ist kaum zu vermitteln. Die Change-Programme waren daher eher von Skepsis und Ablehnung begleitet.

Um eine sich daraus ableitende naheliegende Frage zu nennen - heisst das, dass es bei (scheinbar) gut oder zumindest ohne drängende Probleme dastehenden Unternehmen keine Änderungen geben kann? Natürlich nicht, strategische Ziele oder langfristige Herausforderungen können das trotzdem nötig machen. Aber: auf eine Unterstützung durch einen Sense of Urgency (bzw. durch die Menschen die ihn spüren) darf man hier nicht hoffen, es muss auch ohne ihn gehen.

Das Risiko das jetzt auftreten kann ist, dass die mit dem Change befassten Menschen in eine Methodismus-Falle laufen. Statt andere Modelle (etwa Deutschmanns Relate, Repeat, Reframe) zu erwägen wird versucht den Sense of Urgency künstlich zu erzeugen, etwa durch ständige Brandreden, künstliche Deadlines und Ähnliches. Allerdings - was so entsteht ist eher ein "Sense of Harassment", also das Gefühl belästigt zu werden.

Hier wird es dann gleichermassen tragisch wie ironisch. Bei sachgemässer Anwendung von Kotters Methoden würde sich in solchen Situationen nämlich irgendwann doch ein Sense of Urgency feststellen lassen, wenn auch anders als gedacht. Massnahmen wie die oben genannten Sammlungen frustrierender Mitarbeiter-Erlebnisse würden einen dringenden Bedarf nach einem sofortigen Ende der Veränderungsmassnahmen aufzeigen. Im Folgenden kann man sich dann mit einem anderen englischen Fachbegriff auseinandersetzen: Change Fatigue. Eine eigene Geschichte.

Warum Regelverstösse nicht agil machen

Bild: Wikimedia Commons / Ibex73 - CC BY-SA 4.0

Einmal mehr bietet die aktuelle Nachrichtenlage eine schöne Analogie für die Dos und Dont's des agilen Arbeitens. Konkret geht es um ein Urteil des Verwaltungsgerichts Berlin zu den in den letzten Monaten entstandenen "Pop up-Radwegen", die kurzfristig mit Baustellenmarkierungen eingerichtet wurden um den unerwartet hohen Radverkehr bewältigen zu können. Sie wurden in ihrer aktuellen Form verboten. Und es lohnt sich zu erzählen wie es dazu gekommen ist.

Am Anfang stand wie so oft eine Krise. Beginnend im Frühling 2020 sorgte der Ausbruch des Covid19-Virus dafür, dass sich fast niemand mehr dem Gedränge im öffentlichen Nahverkehr aussetzen wollte. Stattdessen nahm die Nutzung von Fahrrädern sprunghaft zu und überlastete die bisher dafür vorgesehenen Spuren. Um das dadurch steigende Risiko von Verkehrsunfällen einzudämmen richtete die Stadt so schnell wie möglich die oben erwähnten Pop up-Radwege ein, die einen Teil der bisher auch von Autos genutzten Strassen belegten.

Was das Gericht in seinem Urteil feststellte: diese Eile und die Sondersituation alleine waren keine ausreichende Begründung für einen derartig schweren Eingriff in den Strassenverkehr. Auch in einer solchen Situation hätte begründet werden müssen wie die Massnahmen mit dem relevante Gesetz, § 45 (9) StVO, in Einklang zu bringen war. Und da das nicht geschehen war erfolgte die Anweisung die Spuren wieder abzubauen.

Warum das eine Analogie auf (falsch verstandenes) agiles Arbeiten ist? Weil die hier genannten Fehler oft auch in der agilen Produktentwicklung gemacht werden. Wenn irgendetwas schnell gehen muss verfallen Teams und Unternehmen manchmal in eine "der Zweck heiligt die Mittel"-Haltung, in der die internen und externen Vorschriften (Barrierefreiheit, Datenschutz, etc.) sehr grosszügig ausgelegt oder sogar ignoriert werden.

Auch die folgende Phase der Untätigkeit ist Analogie-fähig. Genau wie die Berliner Verwaltung monatelang darauf verzichtete die neuen Verkehrswege nachträglich rechtssicher zu begründen verfallen auch manche Teams und Unternehmen in den Irrglauben, auf Dringlichkeit beruhende Massnahmen wären nach Abschluss ein Bestandsschutz geniessendes "Minimum Viable Product", selbst dann wenn sie auf nicht wirklich zulässige Art zustande gekommen sind.

Beides zusammen führt letztendlich allerdings zum genauen Gegenteil des ursprünglich anvisierten Ziels. Durch Regelbeugung zustande gekommene Massnahmen sind nur scheinbar ein schneller Erfolg, erfordern aber in der Regel Nacharbeiten die aufwändiger sind als sie es zu Beginn gewesen wären. Und das Einsparen der noch überschaubaren Kosten eines frühen "Refactorings" wird später richtig teuer und zeitfressend, wenn alles zurückgebaut werden muss.

Selbst wenn es für den Einen oder Anderen unintuitiv erscheinen mag: im Kontext von Gesetzen und Vorschriften bedeutet Agilität nicht, dass man beweglich wird indem man sie so weitreichend wie möglich umgeht, sondern dass man versucht sie so früh wie möglich einzuhalten um schnell Rechtssicherheit zu haben. Alles andere führt zu einem Scherbenhaufen wie dem vor dem die Berliner Politik gerade steht.

Agile 1984

Die Anzahl der überzeugten Anhänger agiler Vorgehensweisen die durch die zunehmende Kommerzialisierung enttäuscht sind nimmt in den letzten Jahren gefühlt immer schneller zu, und Allen Holub dürfte zu den bekannteren unter ihnen gehören. Was ihn auszeichnet ist aber die Ausdauer mit der er immer wieder darauf hinweist wie das Ganze ursprünglich gemeint war. So auch hier.

Darüber hinaus ist sein Vortrag auf einer zweiten Ebene sehenswert. Anders als bei vielen anderen Menschen hat die Verlagerung in die Remote-Arbeit bei ihm nicht dazu geführt, dass er sich für seine Vorträge in Powerpoint-Schlachten stürzt. Stattdessen zeigt er, dass auch jetzt noch die Verwendung von Whiteboards und Post-Its möglich ist.