Kommentierte Links (CXXII)
 |
| Grafik: Pixabay / Brian Penny - Lizenz |
Dienstag, 31. Dezember 2024
Martin Fowler: Continuous Integration
Agile Produktentwicklung kann durch Methoden wie Scrum, Kanban und die Skalierungsframeworks einfacher werden, mindestens genau so wichtig sind aber bestimmte technische Aspekte. Martin Fowler, einer der Verfasser des Manifests für agile Softwareentwicklung, hat sich mit Continuous Integration einen davon herausgesucht und in diesem epischen Essay (über 80.000 Zeichen!) alles was man zu diesem Thema wissen sollte zusammengefasst - bzw. fast alles, aber für alles andere enthält er Buchempfehlungen und weiterführende Links. Für jeden der bei diesem Thema mitreden möchte, eine absolute Empfehlung.Benjamin Ross Hoffmann: Systems of Bullshit Work
Dieser Text ist ein bisschen Meta, da sich Benjamin Ross Hoffmann in ihm auf das Buch Bullshit Jobs bezieht, in dem der Ethnologe David Graeber einen Grossteil der heutigen Jobs als unnötig bezeichnet. Hoffmann differenziert das aus, indem er erklärt, durch welche Faktoren es zum Entstehen dieser Jobs kommt. Wer schon einmal fehlgeschlagene agile Transformationen erlebt hat wird vieles aus denen hier wiederfinden, z.B. im achten Beispiel: Your job might be to perform a ritualized imitation of a service that would be useful if genuine. Es dürfte den einen oder anderen Scrum Master geben, auf den das zutrifft.Maarten Dalmijn: The Era of Copy-Paste Agile Is Over
Maarten Dalmijn hat sich im vergangenen Jahr einen Namen damit gemacht, den aktuellen Zustand der agilen Bewegung, bzw. des agil industriellen Komplex, wortgewaltig zu kritisieren. Auch an dieser Stelle macht er damit weiter, diesesmal mit der Hypothese, dass die gängigen agilen Frameworks den Widerstands- und Beharrungskräften grosser Organisationen nicht gewachsen sind und darum fast zwangsläufig scheitern müssen. Diese Ansicht (und die von ihm vorgeschlagene Alternative) muss man nicht teilen, als provokanter Denkanstoss ist sie aber durchaus wertvoll.John Cutler: Why Orgs Become Too Tall
Dass John Cutler seinen Ruf als ausgezeichneter "Systems Thinker" nicht von ungefähr hat, wird (spätestens) aus diesem Blogpost klar. Ausgehend von der weit verbreiteten Beschwerde, dass viele Organisationen zu gross und zu bürokratisch sind, analysiert er, welche sich wiederholenden Muster dafür sorgen, dass es immer wieder dazu kommt. Das ist zum einen erhellend, zum anderen aber auch hilfreich, da es aufzeigt, an welchen Stellschrauben gedreht werden kann, um Organisationen wieder zu verschlanken und Bürokratie abzubauen.Freitag, 27. Dezember 2024
Kommentierte Links (CXXI)
 |
| Grafik: Pixabay / Geralt - Lizenz |
The Burndown: Continuous Improvement – The Kaizen Way
Dass agile Produkt- und Softwareentwicklung ihren Ursprung im Lean Management hat ist unter Methodikern ein Allgemeinplatz, was das im Konkreten bedeutet bleibt aber häufig unklar. The Burndown leistet hier Aufklärungsarbeit und hebt zwei zentrale Aspekte hervor: zum einen ist das Verbesserungsziel die Steigerung der Wertgenerierung, statt wie im klassischen Management der Produktivität, zum anderen erfolgt die Verbesserung kontinuierlich in kleinen Schritten statt in seltenen, aber dafür grossen Schüben. Gut auf den Punkt gebracht.Willem-Jan Ageling: 7 Hacks to Scale Agile Without Overly Complicated Frameworks
Diese Liste von Willem-Jan Agelings sieben "Hacks", mit denen man ohne übermässig komplizierte Frameworks Agilität im grossen Massstab erreichen kann, ist eine interessante Zusammenstellung, und das alleine deshalb weil sie sowohl Praktiken als auch Organisationsprinzipien als auch Haltungen enthält - in den meistens derartigen Zusammenstellungen kommt nur jeweils eine dieser Kategorien vor. Wer sich mit den agilen Skalierungsframeworks auskennt wird hier sowohl Elemente von LeSS und Nexus als auch von SAFe wiedererkennen. In gewisser Weise der Versuch ein "Best of" zu extrahieren.Doc Norton: Frequent releases improve outcomes
In der agilen Community dürfte Doc Norton mit seiner Aussage, dass häufige Releases zu besserer Ergebnisqualität führen, offene Türen einrennen, in klassisch geprägten Unternehmen herrscht allerdings immer noch die gegenteilige Meinung vor. Da diese Ablehnung meistens auf der nachvollziehbaren Sorge beruht, Geschwindigkeit nur auf Kosten der Qualitätssicherung erreichen zu können, geht Norton auch darauf ein, mit einer wichtigen Klarstellung - natürlich muss zuerst an dieser gearbeitet werden, und zwar so, dass auch sie in hoher Frequenz nötig ist. Iccha Sethi: Tying Engineering Metrics to Business Metrics
Dieser Artikel ist wirklich interessant, da er sich eines weit verbreiteten Problems annimmt: sowohl Business als auch IT verfügen über Metriken, mit deren Hilfe sie Fortschritte und Ergebnisse überprüfen, es sind aber in den meisten Fällen keine gemeinsamen, sondern nur solche, die jeweils auf nur einer Seite verwendet werden und die der anderen als wenig nachvollziehbar oder wenig wichtig erscheinen. Dadurch dass sie hier zueinander in Beziehung gesetzt und miteinander verbunden werden, wird es einfacher gemeinsame Ziele zu definieren und auf sie hinzuarbeiten.Charity Majors: “Founder Mode” and the Art of Mythmaking
Eines der grossen Buzzwords des Jahres 2024 ist "Founder Mode" gewesen, ein Management-Ansatz, der durch Brian Chesky, einen der Gründer von AirBnB, erfunden und popularisiert wurde. Er stellt so ziemlich das Gegenteil aller anderen modernen Management-Ansätze dar, da er sowohl ein mittleres Management als auch crossfunktionale, empowerte, autonome Teams ablehnt und stattdessen alles auf eine einzige alleinentscheidende Person (den Founder) ausrichtet. Da es Chesky auf diese Art gelungen ist, sein Unternehmen aus der Krise zu führen, ist dieses Vorgehen zumindest eines mit dem man sich beschäftigen sollte, um darüber mitreden zu können. Charity Majors hat das dankenswerterweise gemacht, indem sie das Interview, in dem Chesky seinen Founder Mode vorstellt, ausführlich analysiert hat. Das Kurz-Fazit: Chesky hat die Schieflage seines Unternehmens nicht nur behoben, er hat sie vorher auch selber verursacht. Sein Management-Ansatz ist daher mit Vorsicht zu betrachten, selbst wenn er auch sinnvolle Elemente enthält.Montag, 23. Dezember 2024
The 12 Days of Scrum
Dass es auf Youtube eine ganze Reihe von Liedern über agiles Arbeiten gibt ist schon bemerkenswert genug, aber dass es darüber hinaus auch noch "agile Weihnachtslieder" gibt, fasziniert mich immer wieder. Hier ist das nächste, eine Coverversion des englischen Klassikers The twelve Days of Christmas:Und für alle die jetzt in der entsprechenden Stimmung sind - hier sind fünf weitere, die ich in den vergangenen Jahren bereits geteilt habe:
- Agile Night Xmas
- An Agile Little Christmas
- Agile Christmas Eve in Lockdown
- Agile Xmas Song
- Do they know this Agile Thing?
Für die Playlist nach dem einen Eggnogg zu viel.
Freitag, 20. Dezember 2024
Agile Success Stories: The Power of limited WIP
Leider ist es unverkennbar, dass viele Mitglieder der agilen Bewegung mit der Zeit eine eher negative Grundeinstellung entwickeln. Das
ist auch menschlich verständlich, wer sich ständig mit dem Beseitigen
von Impediments und dem Kampf gegen Change Fatigue und Konzern-Trolle
beschäftigen muss, kann leicht in Frustration abrutschen. Um nicht
selbst in dieses Muster verfallen, veröffentliche ich
ab und zu selbst erlebte "agile Erfolgsgeschichten". So wie diese hier.
Es war in einem meiner letzten Einsätze als klassischer Projektleiter. Ein grosser Mittelständler hatte vor, seine Website einem Relaunch zu unterziehen, inclusive des dort eingebundenen Shops. Insgesamt fünf Teams arbeiteten daran, aus der IT, aus dem Marketing und aus der Unternehmenskommunikation, und wie mir im Vorfeld gesagt wurde, war das Meiste schon fertig. Als externe Krankheitsvertretung des Projektleiters sollte ich nur noch die letzten Arbeiten koordinieren.
Die Realität, die ich vorfand, war dann allerdings eine andere. Zwar war die Arbeit tatsächlich schon weit fortgeschritten, die einzelnen Teile (Shop, CMS, Redaktionssystem, Single Sign on, etc.) passten aber an keiner Stelle zusammen. Jeder Versuch, irgendetwas fertigzustellen oder mit irgendeinem anderen Teil zu verbinden, führte zu einer Kaskade an Fehlermeldungen. Und mit gleicher Zuverlässigkeit ergoss sich regelmässig eine Kaskade aufgebrachter Stakeholder in das Projektleitungs-Büro.
Genau das erwies sich auch als die Ursache des Problems. In früheren Projektphasen hatte jeder Stakeholder ständig seine Wünsche in das Projekt einbringen dürfen. Und aus dem Wunsch heraus, alle gleich gut zu behandeln, hatte die alte Projektleitung die Teams angewiesen, an allem gleichzeitig zu arbeiten. So war es dazu gekommen, dass zwar Alles angefangen war, aber Nichts fertig, Nichts integriert, Nichts getestet und Nichts funktionierend.
Der einzige Vortrteil an dieser Situation war, dass das Projekt intern bereits als gescheitert galt, und alle Manager sich fern von ihm hielten, um zu verhindern, dass sie mit ihm in Verbindung gebracht wurden (das war auch der wahre Grund, warum ich als Externer der Projektleiter geworden war). Dadurch hatte ich relativ grosse Freiheiten, um neue Wege auszuprobieren. Nur welche das sein sollten, war mir noch nicht kar - also fragte ich die Entwicklungsteams. Und die hatten tatsächlich eine Idee.
Statt gleichzeitig an allem zu arbeiten und nirgendwo weiterzukommen wollten sie sich immer nur auf ein Feature konzentrieren, das fertigstellen, testen und integrieren, dann das Gleiche mit einem zweiten machen, dann mit einem dritten, und so weiter. Um zu zeigen, dass sie dabei wirklich vorankommen würden, boten sie mir einen täglichen kurzen Statusbericht an, vor einem Board auf dem der Fortschritt jedes Arbeitspaketes visualisiert wurde. Kanban nannten sie das (der Begriff war mir damals noch neu).
Der Beitrag, den ich dazu leisten musste, war, ihnen alle Stakeholder vom Hals zu halten, an deren Feature gerade nicht gebaut wurde. Mit Erbitterung und erstaunlicher Ausdauer drangen diese darauf, dass jetzt doch auch endlich sie wieder an der Reihe sein müssten, verlangten Fortschrittberichte, brachten neue Ideen auf, die sie noch spät in die Umsetzung einbringen wollten und eskalierten ständig beim Top-Management (das sich aus den oben genannten Gründen aber heraushielt). Ein Vollzeit-Job.
Während ich mir also irgendwo Powerpoint-Saalschlachten mit uneinsichtigen Leuten lieferte, wurden so fast unbemerkt die ersten Funktionen fertig. Zu Beginn noch mit Ablehnung aufgenommen ("Was? Nur so wenig? Da fehlt doch noch alles andere!") wurden sie nach und nach mehr und mehr. Und mit diesen frühen Funktionsumfängen gelang das erste kleine Wunder: als die ersten Stakeholder sahen, dass ihre Kernfunktionen fertig waren, waren sie fürs Erste zufrieden und zogen ihre Zusatzwünsche zuück.
Die verbliebenen kämpften zwar um so verbissener für ihre Interessen, da jeder befürchtete, dass am Ende für die Letzten keine Zeit und kein Budget mehr übrig sein würde, aber die Runden wurden nach und nach kleiner und beherrschbarer. Und irgendwann gelang das zweite kleine Wunder. Nachdem die konzentrierte Arbeit dazu geführt hatte, dass die Teams endlich liefern konnten, wurde ihren Zeitplänen auf einmal Glauben geschenkt und die Eskalationen wurden seltener.
Das aus der Sicht des Unternehmens grösste Wunder fand aber ganz zum Schluss statt: nach der Fertigstellung eines zufriedenstellenden Funktionsumfangs hatten sich alle auf das eingerichtet, was sie in vergangenen Projekten als unvermeidbaren Teil der Softwareentwicklung kennengelernt hatten - eine lange und für alle Beteiligten quälende Phase des Software-Testens und Reparierens, bei der nie so ganz abbsehbar war, wie lange sie dauern würde. Diesesmal aber was diese Phase kurz und schnell vorbei.
Der Grund dafür war, dass jede fertiggestellte Funktion sofort mit den anderen integriert und zusammen mit ihnen getestet worden war. Und da immer nur an einer gearbeitet wurde, waren die jeweils neuen Umfänge und Fehlerquellen immer überschaubar gewesen, wodurch sich die Test- und Reparatur-Aufwände in Grenzen gehalten hatten. Statt erst ganz am Ende mit der Qualitätssicherung beginnen zu müssen, war das meiste davon zu diesem Zeitpunkt schon abgeschlossen.
Am Schluss war auf diese Weise einiges von der zwischenzeitlichen Verspätung aufgeholt worden, und das Projekt endete mit jeweils zehn Prozent Zeit- und Budget-Überschreitung. In der gesamten jüngeren Unternehmensgeschichte (in der nie ein IT-Projekt pünktlich fertiggeworden war), war das der beste Wert an den man sich erinnern konnte. Und für mich selber war es der Anstoss, nur noch so arbeiten zu wollen (was ich mittlerweile auch geschafft habe).
Dienstag, 17. Dezember 2024
Hofstadter's Law
 |
| Bild: Wikimedia Commons / Roland Dobbins - CC BY-SA 2.0 |
Unter den vielen verschiedenen "Gesetzen", die mit der Zeit geschrieben wurden, um regelmässig auftretende Phänomene der Softwareentwicklung zu beschreiben, ist ein besonders schönes. Es handelt sich um Hofstadter's Law (also Hofstadters Gesetz), ist benannt nach dem amerikanischen Physiker, Informatiker und Kognitionswissenschaftler Douglas Hofstadter, und wurde von ihm erstmals 1979 beschrieben. Es lautet:
Hofstadter's Law: It always takes longer than you expect, even when you take into account Hofstadter's Law.
Ins Deutsche übersetzt: Hofstadters Gesetz: es dauert immer länger als man es erwarten würde, selbst wenn man dabei Hofstadters Gesetz berücksichtigt. Das klingt erstmal wie ein Scherz, es steckt aber durchaus mehr dahinter. Um dieses Gesetz zu verstehen muss man zuerst kurz das Buch erklären, in dem Hofstadter es veröffentlichte - es hat den Namen Gödel, Escher, Bach: an Eternal Golden Braid und es handelt (unter anderem) von Rekursionen.
Eine Rekursion (von lateinisch recurrere, ‚zurücklaufen‘) wird ein prinzipiell unendlicher Vorgang bezeichnet, der sich selbst als Teil enthält oder sich selbst immer wieder neu startet. Bei einem derartigen Vorgang kann es sich um ein Computerprogramm handeln (das man anhalten muss, wenn es nicht ewig weiterlaufen soll), es kann aber auch ein Denkvorgang (oder eine Verkettung von Denkvorgängen) sein, und genau darauf wollte Hofstadter hinaus.
Den Ausgangspunkt bildet eine bei der Planung komplexer Vorhaben häufige kognitive Verzerrung, der Optimism Bias, der dafür sorgt, dass man den für die Umsetzung nötigen Aufwand unrealistisch niedrig einschätzt. Wie alle derartigen Verzerrungen ist er dem Menschen, in dessen Kopf er stattfindet, aber in der Regel nicht bewusst - im Moment der unrealistisch niedrigen Aufwandsschätzung ist ihm daher nicht klar, dass sie unrealistisch niedrig ist.
Selbst wenn ein vom Optimism Bias betroffener Mensch versucht, den Erfahrungswert, dass er immer zu optimistisch geplant hat, in seine Aufwandsschätzungen einzubeziehen, löst dieser Gedankengang trotzdem erneut den Optimism Bias aus, wodurch die erwähnte Rekursion entsteht. Douglas Hofstadter versuchte diesen Teufelskreis offensichtlich zu machen, indem er in sein nach sich selbst benanntes Gesetz ebenfalls eine Rekursion einbaute: Hofstadters Gesetz löst sich selbst aus.
Die Parallelen zu rekursiven Computerprogrammen sind bis hierhin einleuchtend, an einer Stelle unterscheiden sich die durch Hofstadter's Law beschriebenen Denkvorgänge aber entscheidend von ihnen - mit der Zeit schwächt sich das Ausmass der Verzerrung ab. Das Beispiel an dem Hofstadter sein Gesetz erklärte, war die Entwicklung eines Schachcomputers, der einen Menschen schlagen kann. Und obwohl die Entwicklungzeit mehrfach falsch eingeschätzt wurde - irgendwann war er fertig.
Und damit kommen wir zu einer unerwarteten Verbindung zu einer in vielen agilen Teams verbreiteten Praktik: den Aufwandsschätzungen anhand von Fibonacci-Sequenzen. Dieser exponentielle Wachstums-Verlauf (0, 1, 2, 3, 5, 8, 13, 21, etc) war für Hofstadter beispielhaft für durch Rekursionen bedingte grösser werdende Schätzfehler. Umgekehrt wird in agilen Teams implizit davon ausgeggangen, dass es bei geringer Ungewissheit zu weniger Schätzungs-Rekursionen kommt und die Schätzungen genauer sind.1
In den meisten Fällen dürfte den die Fibonacci-Sequenzen benutzenden agilen Teams dieser gedankliche Unterbau gar nicht klar sein (was auch nicht weiter schlimm ist). Für alle, die sich an geisteswissenschaftlichen Ausschweifungen erfreuen können, dürfte der Gedanke aber eine gewisse Faszination haben: immer dann, wenn die Scrum- und XP-Teams dieser Welt Planning Poker-Karten hochhalten arbeiten sie an der Widerlegung von Hochstädters Gesetz. Was der wohl dazu gesagt hätte?
Donnerstag, 12. Dezember 2024
Ein Bild sagt mehr als 1000 Worte (XLV)
 |
| Grafik: Geek & Poke - CC BY 3.0 |
Montag, 9. Dezember 2024
Der Imagewandel der agilen Bewegung
Es gibt diese Momente, in denen jemand bewusst oder unbewusst etwas Augenöffnendes sagt, das komplexe Sachverhalte, mit deren prägnanter Formulierung man sich bis dahin schwer getan hätte, auf einmal kurz und klar zusammenfasst. Ich habe diesen Moment früher in diesem Jahr im Rahmen eines Einsatzes bei einem Kunden gehabt, bei dem ein Mitarbeiter beschrieb, wie sich seine Wahrnehmung der Scrum Master über die Zeit geändert hatte. Seine Aussage war:
Back in the days, talking to Agilists was like talking to a bunch of tech-nerds. Today it's like talking to HR.
Ins Deutsche übersetzt: damals (der Mitarbeiter war schon seit deutlich über zehn Jahren im Unternehmen), fühlten sich Unterhaltungen mit den Agilisten wie Gespräche mit technikverliebten Spezialisten an. Heute ist es so, als würde man mit der Personalabteilung reden. In diesem Satz (der so in vielen Firmen fallen könnte) steckt unglaublich viel an Inhalt, da er aber ein bisschen Vorwissen benötigt, kommt hier etwas Kontext. Was wollte der Herr uns sagen?
Schauen wir uns zunächst den ersten Teil an, dass die Unterhaltungen mit Scrum Mastern früher denen mit Tech-Nerds entsprochen hätten. Die dahinterstehende implizite Aussage ist die, dass man bei hochspezialisierten (IT-)Technikern zwar niemals zur Gänze versteht, wovon sie eigentlich reden, dass daraus aber Ergebnisse entstehen, die immer wieder beeindruckend sind. Für die frühen Scrum Master und Agile Coaches (ca. zwischen 1995 und 2015) eine durchaus treffende Beschreibung.
Der zweite Teil, demzufolge sich die Gespäche heute wie solche mit HR anfühlen, ist weniger schmeichelhaft. In der breiten Wahrnehmung vieler Mitarbeiter hat die Arbeit der Personal-Einheiten zwar einen sinnvollen Kern, besteht aber darüber hinaus zu einem Grossteil aus dem Erzeugen von Regeln, Prozessen und Sprach-Vorgaben, deren Mehrwert nicht wirklich nachvollziehbar ist.1 Und man muss es leider sagen - die Wahrnehmung vieler agiler Methodenmenschen ist nicht weit davon weg. Autsch.
Wer schon etwas Zeit mit oder in der agilen Community verbracht hat wird entsprechende Aussagen kennen: "Das ist nicht DevOps", "So formuliert man User Stories nicht", "Steht im Daily bitte auf", "Darüber sprechen wir erst in der Retrospektive", "Diese Daten darf ausserhalb des Teams niemand sehen", etc. Ähnlich wie bei den meisten HR-Bemühungen stecken dahinter gute Ideen, wahrgenommen wird es aber meistens als Bevormundung und Gängelung.
Ganz unabhängig davon, ob diese Sicht gerechtfertigt oder berechtigt ist - sie ist real, und findet sich in vielen Unternehmen explizit oder implizit bei den Mitarbeitern wieder. Und wenn diese Sicht einmal Mehrheitsmeinung ist, dann kann man darauf wetten, dass früher oder später jemand die Frage stellen wird, warum man diese Rollen denn braucht, wenn alles was man von denen mitbekommt, die Erzeugung von Regeln, Prozessen und Sprach-Vorgaben mit zweifelhaftem Mehrwert ist.
Alleine um die eigene berufliche Existenz zu sichern, sollten sich Scrum Master und Agile Coaches daher regelmässig fragen, ob das was sie tun von aussen als besserwisserisch, bevormundend und bürokratisch wahrgenommen werden könnte.2 Und wenn das der Fall ist, dann ist damit ein Verbesserungspotential entdeckt, dessen Realisierung deutlich mehr bewirken kann als das dogmatische Bestehen auf bestimmten Prozessen und Begrifflichkeiten.
2Natürlich sollten sie das auch tun, um wirksam zu bleiben. Wie Ken Schwaber in Agile Project Management with Scrum sagte - A dead sheepdog is a useless sheepdog
Freitag, 6. Dezember 2024
The Myth of Conway's Law
Dieses Video von der Large Scale Scrum (LeSS)-Conference Madrid 2024 ist gleich auf mehreren Ebenen sehenswert. Zum einen weil der LeSS-Erfinder Craig Larman hier etwas sehr Sinnvolles tut: am Beispiel von Conway's Law zeigt er auf, wie sehr manche bahnbrechende wissenschaftliche Papers mit der Zeit aus ihrem Kontext gerissen und mit zusätzlicher Bedeutung aufgeladen werden, bis zu dem Punkt, an dem vieles, was sie in der Aussenwahrnehmung ausmacht, gar nicht mehr aus dem Original ableitbar ist.
Auf einer weiteres Enene kann man aus diesem Video aber auch erkennen, warum LeSS, das ja egentlich ein sehr schlankes und agiles Framework ist, mitunter in der agilen Community skeptisch gesehen wird. Sein Schöpfer ist offensichtlich sehr davon überzeugt, Recht zu haben und sehr schnell bereit, anderen vorzuwerfen, ahnungslos oder im Unrecht zu sein (in diesem Fall geht das u.a. gegen die Verfasser der Bücher Team Topologies und Dynamic Reteaming). Wird der eigene Standpunkt auf diese Art vermittelt, ist klar, warum das nicht überall auf Begeisterung stösst.
Dienstag, 3. Dezember 2024
The Ironies of Automation
Es ist wieder soweit - ein Hoch auf die Wissenschaft! Diesesmal auf eines der in Relation zu ihrem Einfluss viel zu unbekannten Research Papers, The Ironies of Automation, verfasst 1983 von der amerikanischen Psychologin Lisanne Bainbridge. Seine Kernaussage: anders als man denken könnte führt Prozessautomatisierung nicht zwangsläufig zu mehr Effektivität oder Effizienz, stattdessen kann es sein (und das ist die Ironie der Geschichte), dass danach alle genauso stark beschäftigt sind wie davor.
Für dieses Phänomen gibt es Gründe. Zum einen führt eine Automatisierung nachvollziehbarerweise dazu, dass der jeweilige Mensch sich weniger mit seinem eigentlichen Arbeitsgegenstand beschäftigt, da diese Aufgabe ja jetzt von einer Maschine oder einem Computer übernommen wird. Sobald ein Eingreifen dann doch nötig wird (und sei es nur um zu überprüfen ob die automatisierte Arbeit richtig ausgeführt wird), dauert das aufgrund der fehlenden Erfahrung länger und ist fehleranfälliger.
Des Weiteren entstehen durch die Automatisierung neue Aufgaben, die es vorher nicht gab. Die Maschine, bzw. die Computerprogramme müssen betrieben, gewartet, repariert und modernisiert werden, was zum einen arbeitsintensiv ist, zum Anderen im Vergleich zu der früher selbst durchgeführten eigentlichen Arbeit deutlich abstrakter und monotoner, was zu nachlassender Konzentration führt, mit der erneuten Folge, dass die Wahrscheinlichkeit von Fehlern (die dann repariert werden müssen) steigt.
Zuletzt entsteht durch die Notwendigkeit, sowohl den eigentlichen Arbeitsgegenstand als auch die Automatisierungstechnik zu beherrschen, eine hohe kognitive Belastung, die auch hier wieder zur Ursache menschlicher Fehler werden kann. Dabei kann es sogar zu einer "Automatisierungs-Ironie in der Automatisierungs-Ironie" kommen, wenn zur Reduzierung dieser Belastungen konzipierte Automatisierungen durch ständige Ergebnisberichte selbst kognitiv belastend werden.
Einen einfachen Ausweg aus diesem Dilemma bietet Lisanne Bainbridge nicht, stattdessen weist sie darauf hin, dass die Lösung nur daraus bestehen kann, ein einzelfallspezifisches Optimum an Automatisierung zu finden, das jeweils bestimmt wird durch Umfang und Komplexität der Prozesse, Änderungs-Häufigkeit, (In-)Stabilität der Umgebung und des Arbeitsgegenstandes, Auswirkungsgrad möglicher Fehler und Qualifikation des jewils eingesetzten Personals.
Auch hier läuft es damit einmal mehr darauf hinaus, sich in einer unbeständigen Welt durch Inspect & Adapt kontinuierlich neu auszurichten und das für den Moment beste Vorgehen zu finden, das sich aber bereits bald wieder ändern kann. Und selbst wenn Lisanne Bainbridges Ironies of Automation sich ursprünglich auf die Frühzeit der Digitalisierung in den 80er Jahren bezogen hat, sind die Parallelen zur heutigen KI-getriebenen Automatisierung offensichtlich.
PS: eine wichtige Differenzierung - die Ironies of Automation sind klar zu unterscheiden von den oberflächlich ähnlichen Rebound-Effekten. Auch die machen die Effektivitäts- oder Effizienzgewinne von Automatisierungen wieder zu Nichte, die dahinterliegenden Mechanismen sind aber komplett andere. Mehr zu den Rebound-Effekten steht hier.
Samstag, 30. November 2024
Kommentierte Links (CXX)
|
| Grafik: Pixabay / Geralt - Lizenz |
Joe Foley: Delete to Accelerate: Boulders, rocks, pebbles - An Agile model that scales
Kurz bevor ich diesen Artikel von Joe Foley gelesen habe, habe ich selber den sehr ähnlichen Ansatz Rock, Pebbles, Sand bei einem Team meines aktuellen Kunden eingeführt. Was beiden gemeinsam ist, ist, dass sie dem häufigen Problem begegnen, dass vorgegebene Planungszyklen (Quartale, Sprints, etc.) nicht vollständig verplanbar sind. Statt in der verbleibenden Zeit mit der nächstwichtigsten Arbeit zu beginnen (die im Zweifel nicht abschliessbar ist), wird diejenige unter den nächstwichtige Aufgaben gewählt. die im verbleibenden Zyklus abschliessbar ist. Ein elementarer Unterschied.Cliff Berg: Empowerment, Not Self-Organization
Es ist eine Debatte die so alt ist wie die agile Bewegung: bedeutet Selbstorganisation nur, dass sich ein bereits zusammengestelltes Team selber entscheidet, auf welchem Weg es ein vorgegebenes Ziel erreicht, oder sollte es sich auch selbst zusammenstellen und sich selbst einen Auftrag suchen dürfen? Cliff Berg plädiert hier für die erste Variante, und zwar nicht aus ideologischen Gründen, sondern aus Pragmatismus. Bei allen Vorteilen ist das Risiko von Konflikten und Dyfunktionen in vielen Fällen zu hoch für das nötige Investment. Ich kann da nicht widersprechen.Sean Gödeke: How I ship projects at big tech companies
Was Sean Gödeke hier aufbringt ist auf den ersten Blick ein technisches Thema - wann ist eine neu entwickelte Funktion "verschifft" (im IT-Englisch: für die Endkunden-Nutzung verfügbar gemacht)? Seine auf den ersten Blick überraschende Definition: nicht dann, wenn das prozessual abgeschlossen ist, sondern erst dann wenn das Management und andere Stakeholder mit dem Ergebnis zufrieden sind. Ist das nicht der Fall, werden auch einwandfrei funktionierende Auslieferungen wieder und wieder überarbeitet werden müssen. Ein guter Impuls um die Definition of Done zu überdenken.Paweł Huryn: 10 Sources of Waste in Product Management
Zum Thema der Mudas (無駄), also der nicht gewinnbringenden (und aus diesem Grund zu vermeidenden) Tätigkeiten aus dem Toyota Production System habe ich schon eine ganze Artikelserie geschrieben, aber auch ich kann aus Paweł Huryns Übertragung auf das Produktmanagement noch neue Erkenntnisse ziehen. Ich glaube sogar, dass es egal ist wo und in welcher Form man sie einsetzt - sobald man sich ernsthaft mit dem Thema Ressourcenverschwendung beschäftigt, wird man überall Verbesserungspotentiale finden können.Pim de Moree: Bayer's Bold Bet: How a 160-Year-Old Giant is Liberating 100,000 People
Bei der aktuellen Konzern-Transformation der Bayer AG bin ich mir unsicher: in der Theorie klingt alles richtig und sinnvoll, was man von Beteiligten aus dem Unternehmen hört, klingt dagegen mitunter eher planlos und willkürlich. Andererseits entspräche das auch wieder den typischen Abwehrreaktionen von Menschen, denen ihre Komfortzone genommen wird. In diesem Text von Pim de Moree steht wieder die positive Seite im Vordergrund. Wie es wirklich ist, wird man vermutlich erst in einigen Jahren wissen, bis dahin ist es eine spannend zu beobachtende Live-Fallstudie.Dienstag, 26. November 2024
Die agile Bewegung
 |
| Bild: Unsplash / Miguel A. Amutio - Lizenz |
Wenn von der Gruppe aller Menschen die Rede ist, die in irgendeiner Form agil arbeiten (oder denen das zumindest zugeschrieben wird) fallen häufig Begriffe wie "die agile Bewegung" oder "die agile Community". Was damit genau gemeint ist bleibt in der Regel offen, was aber keineswegs bedeutet, dass diese Gruppe nicht beschreibbar wäre. Tatsächlich gibt es in der Wissenschaft sogar eine ganze Kategorie sozialer Zusammenschlüsse, die hier passend ist: die der sozialen Bewegungen.
Ein wichtiges Merkmal an dem soziale Bewegungen erkennbar sind, sind übergeordnete, gesellschafts-verändernde oder gesellschafts-stabilisierende Ziele. Das ist offensichtlich bei Bürgerrechts- oder Umweltbewegungen, kann aber auch in Berufskontexten stattfinden. Hier ist die agile Bewegung neben New Work sogar eine der Wichtigsten. Ihr aus dem agilen Manifest abgeleitetes grosses Ziel: die Schaffung einer besseren, humaneren, nachhaltigeren und effektiveren Arbeitswelt.
Was soziale Bewegungen ausserdem von anderen Gruppen unterscheidet, ist die nur schwer überprüfbare Zugehörigkeit. Weder wird man in sie hineingeboren (wie in Familien oder Stämme) noch gibt es klar formalisierte Zugehörigkeits-Kriterien und Aufnahmebedingungen (wie in Unternehmen oder Vereinen). Was es stattdessen gibt sind Selbst- oder Fremdzuordnungen, die sich auch widersprechen können. Man denke z.B. an die Debatten, oder SAFe und OKRs agile Frameworks sind oder nicht.
Eine Folge dieser nicht-formalen Zugehörigkeit ist das weitgehende Fehlen von Macht-Mitteln und Ressourcen-Kontrolle. Bis zu einem gewissen Grad ergeben die sich zwar indirekt aus charismatischer Führung, bzw. der sich daraus ergebenden Gefolgschaft, es gibt aber keine Budgets, keine Karrierepfade und keine bei Fehlverhalten drohenden Konsequenzen. Das ist auch ein Hauptgrund für den in sozialen Bewegungen verbreiteten Idealismus, der als Motivator an die Stelle materieller Anreize tritt.
Dieser unklare und von materiellen Zielen getrennte Status wird allerdings weiter verkompliziert durch das Phänomen, dass es mit der Zeit zu Formalisierungen von Teilen sozialer Bewegungen kommen kann, die dann parallel zu den unformalisierten Teilen bestehen. Eines der bekanntesten Beispiele dürfte die Entstehung der grünen Parteien aus der Umweltbewegung sein, formalisierte Teile der agilen Bewegung sind u.a. die Agile Alliance oder die Scrum Alliance.
Diese letzten Beispiele zeigen auch ein Problem auf, dass soziale Bewegungen bekommen können, wenn sich Teile von ihnen formalisieren. Ob nur zur Finanzierung der eigenen Strukturen oder aufgrund einer Gewinnerzielungsabsicht - mit Formalisierung geht praktisch immer der ein Geldbedarf einher, der alleine aus Selbsterhaltungstrieb doch als materielles Ziel neben die ursprünglichen, idealistischen Ziele tritt - was von den nicht-formalisierten Teilen der Bewegung z.T. vehement abgelehnt wird.
Verstärkt werden derartige Konflikte durch ein weiteres Phänomen, den so genannten Sog der Addition. Er tritt auf, wenn ähnliche soziale Bewegungen gemeinsame Teilziele verfolgen und sich dadurch teilweise überlagern. Sobald diese Überlagerung eine kritische Masse überschreitet, werden auch ursprünglich nicht geteilte Ziele übernommen, im Fall weiter Teile der agilen Bewegung z.B. das Streben nach Basisdemokratie oder die Ablehnung von Shareholder Value-Orientierung.
Nochmal von einer anderen Seite betrachtet können Soziale Bewegungen derartige interne Konflikte aber besser bewältigen und kompensieren als stärker formalisierte Gruppen, zum Einen weil sie eben aufgrund der fehlenden Formalität und Ressoucenverteilung in einem weitgehend konsequenzfreien Raum operieren, zum Anderen weil ihre übergreifenden idealistischen gesellschaftlichen Ziele eine Bindekraft haben können, die grösser ist als die Zentrifugalkräfte der verschiedenen internen Interessen.
Donnerstag, 21. November 2024
Agile Coach, choose your words carefully
Eine kleine Anekdote: in einem meiner längeren Einsätze war ich mit der Begleitung einer agilen Konzern-Transformation beauftragt, in deren Rahmen ich über mehrere Monate Product Owner und Scrum Master ausbildete, Schulungen durchführte und bei der Erstellung einer neuen Aufbau und Ablauforganisation beriet. Im Großen und Ganzen ein Auftrag, auf den ich gerne zurückblicke - mit einer Ausnahme, bei der ich mich etwas fahrlässig verhalten habe.
In einem Workshop mit mehreren angehenden Scrum Mastern stellte irgendjemand einen der Klassiker unter den Einsteiger-Fragen: für was Scrum eigentlich die Abkürzung wäre.1 Ich war gleichermassen amüsiert und leicht genervt, da ich den Ursprung dieses Namens bereits mehrfach erklärt hatte. Und aus einem Affekt heraus antwortete ich mit einem Witz: "Scrum steht für Scaled Corporate Rational Unified Model". Alle lachten kurz, ich dachte mir nichts dabei und der Workshop ging weiter.
Man kann sich vermutlich denken, was als nächstes passiert ist: Zu den Aufgaben der anwesenden neuen Scrum Master gehörte auch die Erstellung von Schulungsunterlagen, und als ich die zwei Wochen später zu Gesicht bekam, musste ich kurz nach Luft schnappen. SCRUM wäre eine Abkürzung, hiess es da, und sie würde stehen für Scaled Corporate Rational Unified Model. Mir war sofort klar, wo diese Fehldeutung ihren Ursprung hatte - bei mir.
Sensibilisiert durch dieses Erlebnis achte ich seitdem darauf, dass humorige oder sarkastische Bemerkungen von mir klar als solche zu erkennen sind, um nicht wieder zur Quelle für eine fehlerhafte Information zu werden. Und ich achte darauf, wo andere Agile Coaches versehentlich mit flapsigen Bemerkungen Falsch-Informationen verbritet haben. Und was soll ich sagen - selbst wenn es zum Glück nicht häufig ist, es kommt immer wieder vor.
Bei einem Kunden stand in der Dokumentation, dass die Kanban-Methode nach ihrem Erfinder Kenji Kanban benannt worden wäre. Bei einem anderen, dass SAD MF ein vielversprechendes Skalierungs-Framework wäre, dass man näher evaluieren sollte. Mehrfach habe ich erlebt, dass Jira erkennbar ironisch als agiles Framework bezeichnet wurde, einmal mit der Anmerkung, dass Entwickler die es benutzen nicht mehr selbst denken müssten. Offensichtlicher Sarkasmus, der aber nicht erkannt wurde.
Wie es zu derartigen Transfer-Missverständnissen kommt ist dabei einfach erklärbar: Für den Agile Coach ist sene Arbeit entweder Routine, die er durch Scherze aufzulockern versucht, oder eine Frustrationserfahrung, die in zu Sarkasmus verleitet. Die ihn umgebenden Menschen befinden sich dagegen in einer Sondersituation, sind noch unsicher was von dem neuen Wissen relevavant ist und verinnerlichen vorsichtshalber alles. Was daraus folgt ist offensichtlich.
Gerade aufgrund dieser Wissens-Asymetrie befindet sich der jeweilige Agile Coach in einer Position, in der er sich verantwortungsvoll verhalten muss. Wie oben gesagt, Humor und Sarkasmus sind in Ordnung, sie müssen aber als solche erkennbar sein, im Zweifel durch die Anmerkung, dass die letzte Aussage bitte nicht ernst zu nehmen ist. Das hilft allen anderen, hilft aber auch dem Agile Coach selbst, der sich weniger Sorgen machen muss, dass von ihm versehentlich das Falsche gelernt wird.
Montag, 18. November 2024
Agile Success Stories: Die iterativ-incrementelle Reorganisation
Die Entwicklung einer negativen Weltsicht durch viele "agile Methodiker" (Agile Coaches, Scrum Master, etc.) ist ein bedauenswertes, aber auch menschlich verständliches Phänomen - wer sich ständig mit dem Beseitigen von Impediments und dem Kampf gegen Change Fatigue und Konzern-Trolle beschäftigen muss, kann leicht in Frustration abrutschen. Um nicht selbst in dieses Muster verfallen, veröffentliche ich ab und zu selbst erlebte "agile Erfolgsgeschichten", um zu zeigen, dass vieles auch gut läuft.
In dieser hier geht es um das Durchführen einer Konzern-Reorganisation. Besagter Konzern hatte in den Jahren zuvor bereits mehrere Reorganisationen durchgeführt, und alle Beteiligten waren sich einig, dass sie nur mittelgut verlaufen waren. Am Anfang hatte es zwar jedesmal gut durchdachten Pläne gegeben, sobald die auf die Realität trafen, hatten sie sich aber jedesmal als lückenhaft erwiesen. Die Anpassung an die Realität hatte dann jedesmal zu Bürokratie, Unordnung und Unzufriedenheit geführt.
Das neue Vorgehen, mit dem es diesesmal anders werden sollte, sah zunächst vor, die Veränderungen in Arbeitspakete aufzuteilen, die nach und nach, in Abständen von wenigen Wochen, ausgeliefert werden sollten. Das Besondere daran: spätere Schritte wurden bewusst noch nicht ausdetailliert, stattdessen wurde nach jeder Auslieferung ein Feedback-Prozess gestartet, auf dessen Basis die Detaillierung angepasst wurde. Sogar das Rückgängigmachen früherer Reorganisationsschritte war ggf. möglich.
Um es an Beispielen konkret zu machen: ein erstes Arbeitspaket war die grundsätzliche Aufteilung und Bündelung von Zuständigkeiten, ein zweites der darauf aufbauende Zuschnitt der Bereiche und Abteilungen, ein drittes die Besetzung der Leitungspositionen, ein viertes die Zuordnung derjenigen Mitarbeiter, deren Tätigkeitsprofil das eindeutig zuliess, ein fünftes die Zuordnung der nicht ganz so eindeutigen Fälle, ein sechstes die Verteilung der neuen Einheiten auf die Büros.1
Der Feedback-Prozess, der nach der Fertigstellung von jedem dieser Arbeitspakete folgte, bestand aus mehreren Dimensionen. Zum einen gab es Versammlungen der (bisherigen) Standorte und Abteilungen, in denen Fragen, Bedenken und Hinweise geäussert werden konnten. Parallel dazu wurden Mitarbeiter aus allen Organisationseinheiten zu Teilzeit-Change Managern ernannt, die dort Ansprechpartner waren und Rückmeldungen sammelten. Zuletzt gab es physische und virtuelle Feedback-Briefkästen.2
Die Erkenntnisse aus diesen Feedbacks waren zum Teil sehr wertvoll. An einer Stelle wurde z.B. darauf hingewiesen, dass beim Abteilungsschnitt eine Zuständigkeitslücke gelassen wurde, an einer anderen Stelle, dass die Aufteilung bestimmer Aufgaben auf zwei Abteilungen zwar theoretisch möglich, in der Realität aber schwierig umzusetzen sein würde, da sie bisher von den selbem Personen durchgeführt wurden. Mehrfach führte das zu Anpassungen, die ebenfalls wieder Gegenstand von Feedback wurden.
Dass diese Anpassungen mit verhältnismässig gerigem Aufwand durchgeführt werden konnten, war vor allem dem Verzicht auf zu frühe Detailplanung zu verdanken. So wären in den beiden erwähnten Beispielen die Korrekturen der suboptimalen Abteilungsschnitte deutlich schwieriger gewesen, wenn zu dem Zeitpunkt bereits alle Versetzungen in diese Einheiten stattgefunden hätten. Da die Versetzungen jetzt erst in einem nächsten Schritt stattfanden, entstanden die Probleme gar nicht erst.
Als Nebeneffekt wurde auch die Kommunikation der Veränderungsmassnahmen deutlich einfacher. Statt alle Veränderungen auf einmal konsistent erklären und als Ganzes verstehen zu müssen, wurde jeweils nur auf das aktuelle Arbeitspaket vertieft eingegangen, bei den späteren reichte eine kurze Ankündigung des Inhalts und des geplanten Zeitpunkts. Sowohl im Kommunikationsteam als auch in der Belegschaft wurde das im Vergleich zu früheren Reorganisationen als deutliche Verbesserung empfunden.
Eine Pointe dieser Geschichte hier ist, dass das in ihr beschriebene Vorgehen, nie offiziell als "agil" konzipiert oder bezeichnet wurde. Stattdessen ging es nach Ansicht aller Beteiligten lediglich auf Common Sense und Erfahrungswerte zurück, aus denen sich ganz selbstverständlich die hier beschriebenen Schritte ergaben. Erst ganz zum Schluss fiehl einem Vorstand auf, dass es offensichtliche Parallelen zur agilen Produktentwicklung gab. Grösser thematisiert wurde das aber nie.
1Auch anonymes Feedbach war hier möglich
Donnerstag, 14. November 2024
Welches SAFe darfs denn sein?
Dass es von jedem agilen Framework in der Realität sehr unterschiedliche Ausprägungen gibt, dürfte jeder wissen, der verschiedene agil arbeitende Unternehmen gesehen hat. Zu den Gründen dafür gehört zum einen ein bewusst offen gelassener Gestaltungsspielraum, zum anderen aber auch versehentliche oder absichtliche Verfremdungen der ursprünglichen Idee. Das trifft auf Scrum zu, auf Kanban, auf OKRs, aber auch auf das Scaled Agile Framework (SAFe).
SAFe ist dabei aber in einem Aspekt deutlich anders als die anderen Frameworks: während sich deren Variantenvielfalt u.a. daraus ergibt, dass sie sich in einem Spannungsfeld zwischen einem praxisnahen Graswurzel-Ursprung und einer später entstandenen starken Kommerzielisierung bewegen, ist SAFe bereits in seinen Ursprüngen kommerziell angelegt. Sämtliche seiner Varianten sind dadurch Teil des Beratungs- und Zertifizierungs-getriebenen agil-industriellen Komplexes.1 Hier sind sie:
The Little Agile Release Train
Die vielleicht häufigste Variante, wenn auch oft mit anders benannten Namen und Rollen.2 Drei bis zehn Teams arbeiten in synchronisierten Sprint-Rhythmen, es gibt eine übergreifende Quartalsplanung und oberhalb der Product Owner und Scrum Master einen Produktmanager / Chief Product Owner und Release Train Engineer / Chief Scrum Master, der ihnen jeweils übergeordnet ist. Für sich genommen eine noch relativ schlanke, agile und halbwegs unbürokratische SAFe-Umsetzung.
The Feature Factory
Die Grössenordnung, die die Aussenwahrnehmung von SAFe am stärksten prägt. Ab einer Größe von mehr als zehn Teams ist ein Release Train nicht mehr ausreichend, es werden mehrere parallel zueinander eingerichtet, über denen dann eine zusätzliche Hierarchieebene mit einem Solution Manager und einem Solution Train Engineer entsteht. Feedback-Schleifen und Nähe zwischen Entwicklern und Anwendern sind nur noch schwer möglich, es werden vor allem Feature Requests abgearbeitet.
Disruptive SAFe
Während der einzelne Release Train und die Feature Factory die alten Strukturen einer Firma noch weitgehend unangetastet lassen, hat SAFe einige optionale Elemente, deren Anwendung einiges durcheinanderwerfen würde, z.B. die Koppelung der Budgetierung an Teams statt an Features oder die Ausrichtung der Planungen an Value Streams statt an Roadmaps. Aus einer "agilen Perspektive" sehr wünschenswert, kommt aber in der Realität nur sehr selten vor.
Absorbed SAFe
Dort, wo (warum auch immer) alles in einem einzigen, grossen agilen Framework organisiert werden soll, die Auswirkungen von disruptivem Safe den Verantwortlichen aber zu weit gehen, ist es eine häufige Reaktion, so lange Anpassungen vorzunehmen, bis zentrale Elemente des bisherigen Vorgehens nicht mehr angetastet werden. Das Ergebnis können Hybrid-Frameworks wie SpotiSAFe sein, ggf. aber auch einfach eine Erweiterung oder Beschneidung des SAFe-Umfangs an entscheidenden Stellen.
Post-SAFe
Mittlerweile erstaunlich häufig anzutreffen sind Unternehmen, die sich irgendwann entschlossen haben, nicht mehr nach SAFe zu arbeiten, da die damit verbundenen Erwartungen nicht erfüllt werden konnten. Mitunter werden aber einzelne funktionierende Elemente beibehalten, z.B. das PI Planning oder die Rolle des Release Train Engineers. Man erkennt durch sie noch, dass SAFe hier einmal im Einsatz gewesen ist, der aktuelle Zustand hat aber nur noch eingeschränkt damit zu tun.
Und viele mehr ...
Wie immer bei solchen Aufzählungen ist auch diese hier nicht vollständig, in den Unternehmen dieser Welt kann man mit Sicherheit noch weitere SAFe-Varianten finden. Wichtig ist an dieser Stelle vor allem die zentrale Botschaft: es gibt verschiedene Ausprägungen dieses Frameworks, die sich z.T. sehr deutlich voneinander unterscheiden, wodurch es viel weniger eindeutig und einheitlich ist, als es auf den ersten Blick erscheinen mag.
2Bei abweichenden Benennungen ist nicht immer klar erkennbar, ob hier SAFe die ursprüngliche, später begrifflich angepasste Idee war, oder ob es durch Einbringung von SAFe-Elementen in LeSS, Nexus oder Scrum@Scale-Umsetzungen zu diesen Ergebnissen gekommen ist.
Montag, 11. November 2024
Wie der Staat wieder handlungsfähig wird (II)
 |
| Bild: Strassen NRW |
Ab und zu wird man von der staatlichen Verwaltung positiv überrascht, in diesem Fall vom Landesbetrieb Straßenbau Nordrhein-Westfalen. Der ist u.a. verantwortlich für den Neubau einer Brücke, die ich in den letzten Jahren ab und zu benutzt habe, der Wupperbrücke Blombacher Bach in Wuppertal. Dieser Neubau wurde dieses Jahr in einer rekordverdächtigen Geschwindigkeit von nur wenigen Wochen abgeschlossen, und das mit Massnahmen, die jetzt zum Standard in NRW werden sollen.
Die erste dieser Massnahmen ist ein frühes Beteiligungsverfahren, an denen sich alle betroffenen Gruppen (in diesem Fall Anwohner, Pendler, Unternehmen, etc.) beteiligen und ggf. ihre Bedenken einbringen können. Das mag auf den ersten Blick wie eine Verzögerung wirken, sorgt aber später im Prozess für Geschwindigkeit, da durch die Einbeziehung derartiger Stakeholder die Wahrscheinlichkeit von Fehlplanungen und Gerichtsprozessen geringer wird.
Über die zweite Massnahme habe ich bereits an anderer Stelle etwas geschrieben: es ist die Modulbauweise. Die einzelnen Bauelemente können an einer anderen Stelle im Voraus gefertigt werden und werden vor Ort nur noch zusammengesetzt und durch eine so genannte Ortbetonergänzung verbunden (was für ein schönes deutsches Wort). Neben der Geschwindigkeit ergibt sich dadurch ein zweiter Vorteil - beschädigte Brückenteile können später einfacher ersetzt werden.
Die dritte Massnahme ist vermutlich für die deutsche Bürokratie am revolutionärsten, es handelt sich um die so genannte funktionale Ausschreibung der Bauvorhaben. Bei derartigen Ausschreibungen wird kein detaillierter Leistungskatalog mehr vorgegeben, sondern es wird nur das zu erreichende Ziel definiert (z.B. Abriss und Neubau einer Brücke) ggf. verbunden mit in diesem Rahmen zu erreichenden Kennzahlen (z.B. der Traglast dieser Brücke).
Dieses Vorgehen hat gleich mehrere positive Effekte: der Umfang der zu erstellenden und zu bearbeitenden Ausschreibungs-Unterlagen wird geringer, den Bauträgern wird es möglich gemacht, neue und innovative Bautechniken einzusetzen, ohne die Bauämter davon überzeugen zu müssen, diese in die Pläne aufzunehmen, und durch die geringeren Aufwände in diesen Ämtern ist der dort spürbare Fachkräftemangel ein weniger starker Verlangsamungsfaktor für Planungs- und Genehmigungsprozesse.
Donnerstag, 7. November 2024
A Field Guide to Reliability Engineering
Mir fällt gerade auf, dass ich noch nie etwas zum Thema Site Reliability Engineering (der Schaffung einfach skalierbarer und trotzdem hochzuverlässiger Softwaresysteme) geschrieben habe. Hole ich irgendwann nach, für den Moment nimmt mir Heinrich Hartmann diese Arbeit aber ab, in dem er gut darstellt, wie das bei seiner Firma (Zalando) gemacht wird.
Was mir besonders gut daran gefällt: er streicht deutlich heraus, dass es sich bei Site Reliability Engineering nicht nur um ein rein technisches Thema handelt, sondern um ein technisch-soziales, das ohne Berücksichtigung der Anwender, bzw. ihrer Wünsche und Reaktionen, nicht zu denken ist.
Montag, 4. November 2024
Unternehmens-Multikultur
Noch einmal zum Thema Unternehmenskultur. Wie bereits an anderer Stelle geschrieben hat jedes auch nur halbwegs grosse Unternehmen nicht nur eine Kultur, sondern mehrere, die parallel zu einander existieren: eine in der Fertigung, eine im Vertrieb, eine in der Finanzabteilung, eine in der Software-Entwicklung, etc. Das gilt übrigens auch dort, wo offiziell etwas anderes behauptet wird, wo die "offiziell verkündete Kultur" total positiv erscheint oder wo sie von allen gewollt wird.
Das wirft aber weitere Fragen auf: sind diese verschiedenen Kulturen überhaupt miteinander kompatibel? Wiedersprechen sie nicht ggf. sogar in ihren Grundannahmen und Werten? Ist es auf dieser Basis überhaupt möglich, eine gemeinsame (Firmen-)Identität zu schaffen und sich auf gemeinsame Ziele zu einigen? Oder muss man nicht befürchten, dass die verschiedenen kulturellen Gruppen eher gegeneinander als miteinander arbeiten? Alles berechtigte Punkte.
Die gute Nachricht an dieser Stelle ist, dass es bereits seit langem eine umfangreiche wissenschaftliche Beschäftigung mit diesem Thema gibt, nämlich in der Soziologie, genauer gesagt in der Kultursoziologie. Zwar beschäftigt die sich eher mit Gesellschaften als Unternehmen, die Ergebnisse sind aber übertragbar. Bekannte Forscher sind hier Milton M. Gordon, John Rex oder Alf Mintzel (der in seinem Buch Multikulturelle Gesellschaften in Europa und Nordamerika eine gute Übersicht über das Thema gibt).
Das (vereinfachte) Ergebnis dieser Forschungen ist, dass Menschen in der Lage sind, in multikulturellen Umgebungen ihre Kultur temporär zu wechseln. In der Gesellschaft könnte dieser Wechsel z.B. zwischen Familie und Beruf stattfinden, in einem Unternehmen z.B. zwischen Projekt und Linie. In beiden Umfeldern werden dabei jeweils (bewusst oder unbewusst) die Verhaltensmuster an den Tag gelegt, von denen angenommen wird, dass sie in der jeweiligen Situation Kultur-konform sind.
Natürlich sind mit dieser Art von Multikultur Risiken verbunden. Zum einen kann es beim Aufeinandertreffen der jeweiligen kulturellen Gruppen für den, der zwischen ihnen wechselt, zu Rollenkonflikten kommen (zu wem verhält man sich jetzt kompatibel?), zum anderen sind während der temporären Zugehörigkeit zur einen Gruppe die Anliegen der anderen Gruppe nicht mehr so einfach zu erklären, ohne aus der Rolle zu fallen (die Folge ist der so genannte Kontext-Kollaps).
Um derartige Missverständnisse und daraus folgende potentielle Konflikte zu entschärfen, neigen multikulturelle Gesellschften (bzw. Unternehmen) dazu, selbstorganisiert jeweils zwei Varianten jeder einzelnen ihrer Teil-Kulturen herauszubilden: die primäre, die nur innerhalb der jeweils gleichartig ausgeprägten Gruppen ausgelebt wird, und die sekundäre, die dort ausgelebt wird, wo sich der Wirkungs- und Wahrnehmungsraum verschiedener kultureller Gruppen überschneiden.
Dabei kann es dazu kommen, dass die von den verschiedenen Einzelgruppen herausgebildeten Sekundär-Kulturen sich so ähnlich sind, dass sie sie kaum noch unterscheiden lassen. In einer Betrachtung von aussen kann dadurch der Eindruck entstehen, dass es doch eine gemeinsame, einheitliche Unternehmenskultur gäbe. Da diese Annahmen die parallel existierenden Primär-Kulturen nicht beachten, halten sie einer näheren Betrachtung aber kaum stand.
PS:
Die hier genannte Unternehmens-Multikultur ist übrigens nicht zu verwechseln mit dem in grossen Unternehmen häufigen Zusammenarbeiten verschiedener Nationalitäten oder Ethnien. Es gibt zwar Überschneidungen, aber trotzdem ist es nochmal ein eigenes Thema, zu dem es eine eigene wissenschaftliche Forschung gibt.Donnerstag, 31. Oktober 2024
Kommentierte Links (CXIX)
|
| Grafik: Pixabay / Geralt - Lizenz |
John Utz: Delete to Accelerate: Transforming Your Product with a Reverse Roadmap
Weniger ist mehr, das gilt in vielen verschiedenen Kontexten, aber ganz besonders im Umfeld agiler Produktentwicklung. Kleinere Anforderungen lassen sich schneller umsetzen, kleine Anwendungen einfacher umbauen oder erweitern, kleinere Systeme einfacher betreiben. Um in diesen Zustand zu kommen, empfiehlt John Utz eine zweite, parallele Roadmap. Während in der ersten das Hinzufügen von Features, etc. im Mittelpunkt steht, konzentriert sich die zweite auf das Verschlanken. Doc Norton: Opportunity Solution Trees
Ich bin grosser Fan davon, Change Management in Form von kleinen, überschaubaren Experimenten durchzuführen, aus ähnlichen Gründen wie den weiter oben genannten. Aber wie behält man dabei den Überblick über alle Ausgangshypothesen, Validierungsschritte und Ergebnisse? Doc Norton stellt mit dem Opportunity Solution Tree ein mögliches Werkzeug vor, in dem man nachvollziehen kann welche Experimente mit welchen Ergebnissen stattgefunden haben.Stefan Kühl: Disruption
Mal wieder ein "akademischer Rant" von Stefan Kühl, der als Soziologe eine eigene und distanzierte Sicht auf Manager, Berater und ihre Moden hat. Diesesmal ist die Postulierung einer im Vergleich zur Vergangenheit angeblich einzigartigen Disruption Gegenstand seiner Kritik, und wer seine Beiträge kennt, der weiss auch bereits, wie sein Fazit lautet: so einzigartig ist die aktuelle Situation gar nicht. Es sind andere Disruptionen als früher, aber keine schwerwiegenderen.Maarten Dalmijn: Are Scrum Masters Too Much Overhead? / Are Product Owners Too Much Overhead?
In diesen beiden Artikeln hat es Maarten Damijn erkennbar darauf angelegt, die Scrum-Community ein bisschen zu provozieren, denn er stellt nicht nur die Notwendigkeit der beiden Rollen Scrum Master und Product Owner in Frage, sondern fragt darüber hinaus, ob es sich bei ihnen nicht sogar um Overhead handelt. Die Antwort gibt er selbst: es kommt darauf an. Womit er erkennbar hadert ist, dass man sie in solchen Fällen zwar weglassen kann, das Ergebnis dann aber nicht mehr Scrum heissen darf.Lisa Crispin: The Agile Testing Quadrants
Zuletzt ein Heads up für die agile QA-Community. Mit den agilen Test-Quadranten verfügt sie über eines der bekanntesten "agilen Werkzeuge", das schon 2008 durch das Buch Agile Testing bekanntgemacht wurde. Mit Lisa Crispin macht eine der beiden Autorinnen hier darauf aufmerksam, dass die meistens verwendete Version nicht mehr die aktuelle ist, da sie weiterentwickelt und verbessert wurde. Vielleicht ein Grund für einen schnellen Kontrollblick in den eingenen methodischen Werkzeugkoffer.Montag, 28. Oktober 2024
How Money Flows Trump Conway's Law
Conway's Law ist ein grosser Klassiker wenn es darum geht, die Zusammenhänge zwischen Organisationsstruktur und Software-Architektur zu erklären (oder aufzuzeigen, dass die überhaupt existieren). Ian Miell macht zu Recht darauf aufmerksam, dass diese Ableitung der Architektur aus der Struktur aber nur ein unvollständiges Bild bietet - auch die Struktur orientiert sich nämlich an etwas, und zwar an den Finanzströmen des Unternehmens. Mit anderen Worten: die Gestaltung der Finanzströme definiert über die Organisationsstruktur die Software-Architektur.
Über diese Erkenntnis hinaus geht Miell aber noch weiter und erklärt anhand von realen Beispielen, wie die Finanzströme mit Projekten, Produkten, DevOps, Site Reliability Engineering und Unternehmenspolitik zusammenhängen. Ein grosser Rundumschlag, aber ein lohnender und aufschlussreicher.
Donnerstag, 24. Oktober 2024
Schrödinger's Agile
Es ist gerade wieder eine dieser Phasen, in denen der "State of Agile" lebhaft diskutiert wird. Auf der einen Seite werden fehlgeschlagene agile Transitionen und die Entlassung der Scrum Master in manchen Unternehmen als neuer Beleg für die seit ca 2005 periodisch auftauchende "Agile ist tot"-These genommen, auf der anderen Seite werden verschiedene Transitions-Erfolgsgeschichten und die zahlreichen Scrum- und Agile-Stellenausschreibungen als Beweis des Gegenteils betrachetet.
In meiner Wahrnehmung sind beide Standpunkte richtig, und zwar nicht so, dass die Wahrheit in der Mitte liegt. Genau wie Schrödingers Katze ist agiles Arbeiten gleichzeitig tot und am Leben, für beides gibt es eindeutige Anzeichen. Und genau wie im Fall von Schrödingers Katze wird eine konkrete Überprüfung eines einzelnen Sachverhalts zwar für diesen Einen eine Antwort für die Frage tot oder lebendig bringen, die aber die grundlegende Gleichzeitigkeit nicht auflöst.
Werden wir etwas konkreter. Über die Zeit haben sich verschiedene Spielarten der "real existierenden Agilität" herausgebildet, deren aktueller Zustand höchst unterschiedlich sein kann. Nimmt man die jeweils für sich genommen unter die Lupe, kann alles dabei sein, von erstaunlich lebendig bis kurz vor dem Ableben. Diese Einschätzungen sind alle natürlich hochgradig subjektiv, wobei ich schon glaube, durch Kunden, Akquise und Meetups einen überdurchschnittlich breiten Einblick zu haben.
Technische Agilität
Alive and kicking. Egal ob Oldschool (Extreme Programming), zeitgemäss (DevOps, CI/CD) oder avantgardistisch (Chaos Engineering, AI Driven), die technische Dimension des agilen Arbeitens ist der de facto-Standard in der Softwareentwicklung geworden. Tatsächlich tritt hier gerade ein, was ich vor fast 10 Jahren geahnt habe: die Verbreitung ist soweit fortgeschritten, dass oft nicht mehr von agiler Softwareentwicklung die Rede ist, sondern nur noch von zeitgemässer Softwareentwicklung.
Business-Agilität
Alive and kicking. Produktzentrierung, Design Thinking, Lean Startup, Business-Experimente, AB-Testing, MVPs, Low Code-Prototypen und mehr sind selbst in Grosskonzernen und traditionellen Familienunternehmen mittlerweile weit verbreitet - sogar so sehr, dass mitunter die Fach- und Marketingabteilungen ein genauso gutes, manchmal sogar besseres Verständnis von Agilität haben als die IT-Abteilungen. Das wäre noch vor wenigen Jahren undenkbar gewesen.
Agiles PMO ("Team-Sekretariat")
Polytrauma. Ein Grossteil der Agile Coaches und Scrum Master dieser Welt hat leider das Klischee erfüllt, vor allem Meetings zu moderieren, Jira zu konfigurieren und die Teamkalender zu verwalten. Darin wird in vielen Firmen, aber auch in vielen Teams, kein Mehrwert mehr gesehen, und auch die Betroffenen selbst sind meistens unglücklich. Viele Entlassungen haben hier stattgefunden. Dort wo es "agile PMO-Kräfte" noch gibt, haben sie in der Regel zwei, drei oder noch mehr Teams zu betreuen.
Agiles Hands Off-Coaching
Tot. Bis zur Corona-Pandemie hat es einen weit verbreiteten Typ von Agile Coaches und Scrum Mastern gegeben, der durchgehend mit dem Team zusammensass, wenig selbst gemacht hat, aber regelmässig Beobachtungen geteilt und Feedback gegeben hat. Das war auch deutlich wertvoller als man auf den ersten Blick denken könnte, hat aber durch den Umschwung zur Remote-Arbeit 2020 schlagartig aufgehört zu funktionieren und zu existieren.
"Agiles" Life Coaching / Personal Coaching
Mausetot. Während der zuletzt genannte Typ für wertstiftendes Feedback mindestens ein Grundniveau an Wissen über Softwareentwicklung, Projektmanagement und Produktmanagement gebraucht hat, gab es daneben einen weiteren weitverbreiteten Typ, der dieses Wissen weder hatte noch wollte, und sich stattdessen auf (häufig ungefragtes) Life Coaching und Personal Coaching beschränkt hat ("Was macht das mit Dir?"). Diese Personen gehörten nicht nur in Krisenzeiten zu den ersten Personalabbau-Zielen.
Esoterisches Agile Coaching
Mausetot. Bei diesem Typ von Agile Coaches und Scrum Mastern fragt man sich rückwirkend, wie die sich jemals in nennenswerter Menge am Markt etablieren konnten. Pseudo-wissenschaftliche Ansätze wie neurolinguistische Programmierung, Eneagramme und Spiral Dynamics und extreme Überspitzungen grundlegend sinnvoller Konzepte, wie z.B. von gewaltfreier Kommunikation, waren schon immer schwer zu vermitteln, mittlerweile sind sie es gar nicht mehr.
Agiles Hands On-Coaching
Auf dem Weg der Besserung. Im Rahmen mancher Personalabbauprogramme sind zahlreiche agile Methodiker, die einen guten Job gemacht haben, mit den zuvor genannten in einen Topf geworfen und entlassen worden. In vielen Fällen ist danach aufgefallen, was plötzlich fehlt, so dass diese Stellen wieder aufgebaut wurden. Und bei vielen weiteren war die Wertschätzung so gross, dass ihre Positionen behalten konnten (wenn auch z.T. mit geändertem Jobtitel aber ähnlichen Aufgaben).
Agiler Zertifizierungsmarkt
Polytrauma. Über lange Jahre waren die Scrum-, SAFe- und Kanban-Zertifizierungslehrgänge sowohl Einnahmequelle als auch Vertriebskanal für viele Agile Coaches und agile Beratungen. Seit einiger Zeit wird der Wert dieser Zertifikate aber immer kritischer gesehen, während gleichzeitig immer neue Anbieter ein Überangebot geschaffen haben. Da für viele Zertifizierungs-Lizenzen eine Mindestmenge an Trainings nötig ist, sind die mitunter nur noch schlecht gebucht und dadurch ein Verlustgeschäft.
Agil-industrieller Komplex
Alive and kicking. Die meisten agilen Idealisten würden es sich anders wünschen, aber dem agil-industriellen Komplex geht es erstaunlich gut. Die Konzerne schmeissen zwar nicht mehr ganz so viel Geld aus dem Fenster um agile (Pseudo-)Transitionen und Skalierungsvorhaben durchzuführen, die Einführung von SAFe oder dem Spotify Model in Grossorganisationen ist aber immer noch ein solider Business Case, und das vermutlich noch lange.
Agile beyond IT
Den Umständen entsprechend. Die Zeit in der auch Einheiten wie HR, Hausmeisterdienst und Rechtsabteilung unbedingt Sprints, Dailies und OKRs haben wollten sind zwar vorbei, auf der anderen Seite haben Firmen wie Mercadona, Cleveland Clinics und SpaceX agile Praktiken weit aus der Softwareentwicklung herausgeführt und gelten in ihren Branchen sogar als Vorbilder. Darüber hinaus tritt Agilität unter z.T. anderem Namen noch in vielen weiteren Bereichen unentdeckt auf.
Was durch diese Übersicht klar wird: pauschale Aussagen wie "Agile ist tot" oder "Agile hat gewonnen" gehen an der vielschichtigen Realität vorbei.1 Und diese Situation wird dadurch, dass es zwischen einzenlen Unternehmen grosse Unterschiede gibt, nochmal vielschichtiger. Aus einer gewissen Distanz betrachtet muss man also grundsätzlich davon ausgehen, dass agiles Arbeiten sowohl lebendig als auch von uns gegangen sein kann. Was stimmt, sieht man nur im Einzelfall.
Montag, 21. Oktober 2024
Loose Coupling
Zu den Begriffen an denen man bei der Beschäftigung mit agilen Zielsetzungs-Systemen (OKRs, Sprint Goals, etc.) früher oder später vorbeikommt, gehört auch das Loose Coupling (ins Deutsche übersetzt die lose Koppelung). Beschrieben wird das meistens damit, dass über- und untergeordnete Ziele und Massnahmen nicht zu fest miteinander verbunden sein sollen (das wäre Tight Coupling, bzw. enge Koppelung) - aber warum will man diese enge Verbindung eigentlich oft nicht?
Zum besseren Verständnis hilft es, sich Zielsetzungssysteme anzusehen, die umgekehrt gestaltet sind, in denen also Tight Coupling stattfindet. Das sieht meistens so aus, dass die untergeordneten Ziele und Massnahmen fest definierte Teilmengen der übergeordnetend sind, was zwei Folgen hat: zum einen müssen sie alle erfüllt werden um das übergeordnete Ziel zu erreichen, zum anderen sind sie so eng miteinander verbunden, dass sie sich gegenseitig beeinflussen.
Wenn das übergeordnete Ziel z.B. die Gründung einer neuen Niederlassung ist, und davon das Mieten eines Gebäudes, die Einrichtung der Arbeitsräume und die Anstellungung von geeignetem Personal abgeleitet werden, dann ist das eine enge Koppelung. Sollte eine einziges dieser Unterziele oder der dazugehörigen Massnahmen scheitern oder sich deutlich verzögern, wäre auch das übergreifende Gesamtziel in gleicher Art davon betroffen.
Drehen wir es um, wie würde hier eine lose Koppelung aussehen? Das übergreifende Ziel könnte z.B. sein, die neue Niederlassung möglichst schnell arbeitsfähig zu bekommen. Abgeleitet davon könnte man die Onboarding-Handbücher verbessern, einen Bonus für bestehende Kollegen ausloben, die sich zeitweise versetzen lassen um die neuen einzuarbeiten, oder temporär mehr Home Office erlauben. Man sieht an diesen Beispielen: wenn sie nicht gelingen sollten, wären die Folgen weit weniger tiefgreifend.
Noch einmal einfacher ist das Loose Coupling in der digitalen Produktentwicklung. Wenn z.B. das Ziel ist, die Zeit die man in einem Genehmigungsportal verbringen muss zu reduzieren, können verschiedene Entwicklungsteams völlig unterschiedliche Ideen einbringen: besseres UX-Design, schnellere Ladezeiten, hilfreiche Chatbots, etc. Alle diese Ideen tragen zum übergeordneten Ziel bei, untrennbar mit ihm verbunden sind sie aber alle nicht, und untereinander auch nicht.
Durch diese Gestaltung wird etwas möglich, was in jeder ernsthaften Bemühung agil zu Arbeiten enthalten sein sollte: autonome, selbstorganisierte Teams. Durch das Vorgeben der übergeordneten Ziels wird sichergestellt, dass sie im Sinn der Gesamtstrategie arbeiten, mit welchen untergeordneten Ziele und Massnahmen sie das machen und auf welche Art und Weise sie diese umsetzen liegt aber bei ihnen (natürlich müssen dafür bestimmte Vorbedingungen erfüllt sein, z.B. Crossfunktionalität).
Es wird aber an dieser Stelle auch offensichtlich, an welcher Stelle Loose Coupling an Grenzen stösst: dort nämlich, wo aus technischen, juristischen oder sonstigen Gründen sehr klare Vorgaben nötig sind, die dann auch genau so erfüllt werden müssen. Andererseits handelt es sich dann bei ehrlicher Betrachtung auch nicht mehr um Zielsetzungs-Systeme sondern um Anleitungs- und Kontrollsysteme. Das wäre aber nochmal ein eigenes Thema für sich.
