Kommentierte Links (CXXII)

Grafik: Pixabay / Brian Penny - Lizenz

Normalerweise sammele ich in den kommentierten Links die jeweils interessantesten oder amüsantesten Artikel die ich im letzten Monat gelesen habe. Von Zeit zu Zeit kommt es aber vor, dass ich einen vorübergehend vergesse oder ihn erst entdecke Monate nachdem er erschienen ist. Hier sind die besten dieser "verpassten" aber trotzdem lesenswerten Texte aus dem letzten Jahr.

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.

Donald 'Mark' Haynes: An Agile focus on minimalism

Das was Mark Haynes hier hervorhebt ist eine zu oft vergessene Wahrheit: wer mit agilem Arbeiten erfolgreich sein will, der muss in der Kunst des Minimalismus geübt sein, da grosser Umfang und komplizierte Zusammenhänge sehr schnell zu Schwerfälligkeit und Langsamkeit führen. Was man bei ihm lernen kann ist, dass dieser Minimalismus nahezu überall anwendbar ist - bei Prozessen, bei Entwicklungspraktiken, in der Software-Architektur und in Anforderungen. Was daraus folgt: bei agilen Transitionen sollte es weniger um das Hinzufügen von Rollen, Regeln, Prozessen und Praktiken gehen und mehr darum, möglichst viele bestehende abzuschaffen.

Christiaan Verwijs: Why Teams Need Composition Autonomy

Das hier ist eine kontroverse, aber interessante Meinung. Christian Verwijs ist davon überzeugt, dass ein wesentlicher Aspekt autonomer Teams sein sollte, dass sie ein Mitspracherecht bei der Frage haben sollten, wer ihnen angehört. Wichtig für das Verständnis seiner Ausführungen ist dabei, dass er die Gewährung dieser Mitsprache-Rechte nicht als Alles oder Nichts-Entscheidung sieht, sondern dazwischen eine Skala definiert, auf der unterschiedliche Teams unterschiedlich eingeordnet werden können (und auf der sie sich auch noch weiter hin- und herbewegen können).

Jeff Gothelf: Aligning, Not Cascading, OKRs with an OKR Lineage

Nachdem die Objectives and Key Results von der agilen Bewegung "adoptiert" wurden, stellte sich bei ihnen in kürzester Zeit die gleiche Frage, deren Beantwortung auch von den anderen agilen Frameworks verlangt wurde: wie funktioniert das im grossen Massstab? Jeff Gothelf hat sich den beliebtesten OKR-Skalierungsansatz, die "kaskadierenden OKRs" angeschaut und für nicht gut befunden, hat aber auch eine bessere Alternative im Angebot: die Lineage OKRs (Abstammungs-OKRs). Statt Ziele von oben nach unten durchzureichen, werden sie hier dezentral erstellt, müssen dabei aber einen Bezug zur nächsthöheren Ebene aufweisen können.

Melissa Perri: Building a Great Product Management Organization

In Teilen der US-amerikanischen Tech-Szene hat mittlerweile der Begriff "Product" (bzw. Product Management) den Begriff Agile verdrängt oder assimiliert. Dieser Artikel von Melissa Perri (einer der bekanntesten Product Management-Vordenkerinnen) zeigt gut auf, wie dort eine produktorientierte Organisation verstanden wird, was sie beinhalten sollte und woran man Dysfunktionen erkennt. Ein Vergleich zu den üblichen Agile-Talking Poin ist durchaus interessant, da man sowohl Gemeinsamkeiten als auch Unterschiede erkennen kann (z.B. die Thematisierung von Karrierepfaden).

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.

Marty Cagan: Transformation as a Project

Eines der grossen Mantras der agilen Bewegung und der Produktorientierungs-Bewegung ist, dass sie weg von der projektbasierten Organisationsform wollen, die in den meisten grossen Organisationen der Standard ist. Und beide leiden unter der tragisch-ironischen Situation, dass sie mit ansehen müssen, dass viele Versuche ihre Ansätze einzuführen dann doch wieder als Projekt durchgeführt werden, mit all den Problemen die damit verbunden sind. Marty Cagan thematisiert diese Dysfunktion ebenfalls, hat aber auch Ideen wie es besser gehen kann: durch kleine Anfänge, schnelle Lernzyklen, asynchrone Fortschritte und kontinuierliche Optimierung. Wie auch sonst?, möchte man fragen.

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.

Nigel Baker: What Has Gone Wrong - And How To Fix It.

Apropos Systems Thinking: in diesem Blogpost von Nigel Baker findet sich einiges davon (und daneben auch Humor und Polemik, was das Ganze sehr lesenswert macht). Das Thema, das er derartig beleuchtet, ist (ähnlich wie weiter oben bei Maarten Dalmijn) der Zustand der agilen Bewegung. Wer dieses recht zähe Thema gerne launisch und unterhaltsam aufbereitet haben möchte, ist an dieser Stelle richtig.

Kommentierte Links (CXXI)

Grafik: Pixabay / Geralt - 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.

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.

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.

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).

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.¹

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?

¹Formulieren würden es die wenigsten so, aber dass analog zu dem Aussmass von Ungewissheit und Komplexität die Fehlannahmen exponentiell steigen oder zurückgehen, würden die meisten bestätigen

Ein Bild sagt mehr als 1000 Worte (XLV)

Grafik: Geek & Poke - CC BY 3.0

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.¹ 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.² 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.

Ob die Aussenwahrnehmung dadurch wieder zurück zum Tech-Nerd geht, ist eine andere Frage (genau wie die, ob das überhaupt wünschenswert ist), wichtiger als das ist aber in solchen Fällen ohnehin, sich zuerst aus den negativen Klischees herauszuarbeiten. Alles andere kann dann später kommen.

¹Das soll kein HR-Bashing sein, es geht lediglich um die Beschreibung einer weit verbreitenden Meinung, unabhängig von deren Berechtigung
²Natü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

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.

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.