Kommentierte Links (CVI)

Bild: Unsplash / Fabio Bracht - 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.

Christiaan Verwijs: On Stakeholders, And How To Discover Them

Eine Frage mit der sich viele Teams schwer tun ist die, wer eigentlich die Stakeholder ihres Produkts oder Services sind. Die klassische Definition "Jeder, der ein Interesse daran hat oder von ihm betroffen ist" ist zwar richtig, hilft aber aufgrund ihrer hohen Abstraktionsebene nur eingeschränkt weiter. Christiaan Verwijs bietet mit diesem Artikel nicht nur einige etwas konkretere Definitionen und Ratschläge an, sondern auch ein sehr nützliches Werkzeug: 10 Fragen anhand derer ein Team feststellen kann, mit welchen Stakeholdern es zu tun hat und was deren Interessen und Betroffenheiten sind.

Marty Cagan und Joakim Sundén: The Product Model at Spotify

Eines vorweg, um Missverständnisse zu vermeiden: das was Marty Cagan und Joakim Sundén hier beschreiben, ist nicht das berühmt-berüchtigte organisatorische Spotify Model mit seinen Tribes, Chaptern, Gilden und Squads, sondern der grundlegende Ansatz, wie bei Spotify mit Produktentwicklung, Produktstrategie und Product Discovery umgegangen wird. Verkürzt gesagt baut es auf möglichst autonome (Teil-)Produkt-Teams auf, die Erkenntnisse aus dem beobachteten Benutzerverhalten verwenden, um durch kleine, schnell validierbare Veränderungen die Nutzungsintensität hochzutreiben. Wer ähnlich erfolgreich wie Spotify werden will sollte sich eher an diesem Product Model orientieren als an der Organisationsstruktur.

Steve Denning: Escaping From The Prison Of ‘Processes’ (Part I, Part II)

Was Steve Denning von praktisch allen anderen Vordenkern der agilen Bewegung unterscheidet, ist seine Zielgruppe. In seinen Kolumnen auf Forbes.com richtet er sich explizit an CEOs und andere Top-Manager, was dazu führt, dass er auch seine Analysen und Lösungs-Ideen auf diese Gruppen ausrichtet. Seine Zusammenfassung des Weges, der grosse Unternehmen in das "Gefängnis obsoleter Prozesse" geführt hat und seine Anleitung zum "Ausbruch" aus diesem Gefängnis sind vor diesem Hintergrund zu lesen. Mit seinen dazugehörenden Ausführungen zu Aktienkursen, ISO-Standards und Management-Rekrutierung ist er entfernt von der sonst dominierenden Team- und Produktzentrierung, und genau deshalb eine wertvolle Ergänzung.

Thorsten Ball: Why We Don’t Ship Software as Fast as We Used To

Von älteren Entwicklern und Managern hört man es immer wieder: "früher" wurde Software schneller entwickelt und zum Kunden gebracht als "heute". Das Bemerkenswerte daran - selbst wenn man Vergangenheitsverklärung und Fortschrittspessimismus mit in Betracht zieht, ist diese Aussage (scheinbar) richtig, wie Thorsten Ball anhand der aus heutiger Sicht atemberaubend schnellen Entwicklung der Computerspiel-Klassikers Doom aufzeigt. Die Erklärung, die er für die (scheinbare) Verlangsamung mitliefert ist die, dass die heutigen Software-Produkte um ein vielfaches komplexer sind als die früheren, diese Komplexität (unterschiedliche Endgeräte, grössere Betriebssysteme, permanente Internet-Verbindung, mehr Nutzer, etc.) aber nicht auf den ersten Blick erkennbar ist. Sicher ein wichtiger Faktor für die häufigen Missverständnisse zwischen "Business" und "Development".

Benji Weber: One does not simply deliver software

Sprache formt unsere Wirklichkeit, oder zumindest deren Wahrnehmung durch uns. Aufbauend auf diese Erkenntnis erklärt Benji Weber, warum es keine gute Idee ist, das zur Verfügung stellen neuer Software-Funktionen als Delivery (Auslieferung) zu bezeichnen. Verkürzt gesagt: es erweckt den Eindruck, dass alles einfacher, aber auch fragiler wäre als es eigentlich ist, und sorgt dadurch für unrealistische Erwartungshaltungen und unnötige Befürchtungen, die früher oder später zu Konflikten führen müssen.

Cost of Delay

Wenn der Mehrwert von schneller Auslieferung und schneller Reaktion auf Veränderungen beschrieben wird, gehört die Vermeidung von Verspätungskosten oder "Cost of Delay" zu den am häufigsten genannten Vorteilen. Don Reinertsen, der Erfinder des Begriffs, beschreibt ihn als die Summe, die pro Zeiteinheit (Monat, Jahr, etc.) nicht eingenommen wird, weil Produkte zu spät fertig werden. Das ist auch richtig, wie er selbst sagt aber nur verkürzt dargestellt.

Will man kalkulieren, mit welchen Verzögerungskosten man im Fall einer verspäteten Fertigstellung konfrontiert werden wird, sollte man das Konzept auffächern: gibt es unterschiedliche Arten von Kosten, und von welchen würde man betroffen sein? Die Antwort auf diese Frage wird je nach Einzelfall anders ausfallen, die folgenden Typen sind aber diejenigen, mit denen am häufigsten zu rechnen ist und die man daher in die Überlegungen einbeziehen sollte.

1. Vepasster Absatz/Gewinn pro Zeit-Einheit

Der einfachste, und von Reinertsen am häufigsten genannte Fall. Bei einem angenommenen Gewinn von zwölf Millionen pro Jahr betragen die Verspätungskosten etwa eine Million pro Monat. Dieser Schätzwert macht Abwägungen möglich. Z.B. wenn man in diesem Fall durch Investitionen von sechs Millionen ein halbes Jahr schneller am Markt wäre - wäre das den Aufwand wert (nein, eher nicht).

2. Verpasstes Saison-Geschäft

Ein etwas komplizierterer Fall. Oft ist der voraussichtliche Gewinn nicht gleich über einen längeren Zeitraum verteilt, sondern konzentriert sich auf saisonale Phasen (z.B. Weihnachten) oder nach wichtigen Veranstaltungen (z.B. Messen). Eine Verspätung zu diesen Zeiträumen hätte eine hohe Cost of Delay, eine Verspätung mit restlichen Jahr eine geringe oder gar keine.

3. Strafzahlungen wegen Verspätung

Vor allem in regulierten Branchen können auch Strafzahlungen Teil der Verspätungskosten sein. Wenn beispielsweise eine Bank ihren Compliance-Bericht nicht rechtzeitig fertigstellt, kann die Bafin eine Geldstrafe verhängen (hier ein Beispiel). Da die Höhe dieser Strafen sich ungefähr abschätzen lässt, sind auch sie als Cost of Delay bezifferbar.

4. Verpasster Abbau technischer Schulden

Die technischen Schulden sind ein ähnliches Konzept wie die Verspätungskosten. Wenn man in der IT bestimmte effizienzsteigernde Faktoren (modulare Architektur, Testabdeckung, etc.), vernachlässigt, wird man dauerhaft langsamer. Sinkt beispielsweise das Arbeitstempo durch zu viele manuelle Testprozesse um 10 Prozent, lässt sich das in Zeit und damit in Geld umrechnen.

5. Verlorenes Feature-Wettrennen

Eine Variante der ersten, einfachsten Art von Cost of Delay. Wenn ein Wettbewerber ein ähnliches Produkt entwickelt, bedeutet eine Verzögerung nicht nur, dass man später mit dem Geld verdienen beginnt, sondern, dass das auch signifikant geringer ausfällt, da ein Teil der potentiellen Kunden sich dann bereits für das Angebot der früher fertig gewordenen Konkurrenz entschieden hat.

6. Verpasste Besetzung eines neuen Marktes

Gewissermassen die Steigerung eines Feature-Wettrennens. Sowohl bezogen auf neue Käufergruppen als auch bezogen auf neuartige Produkte kann es von grossem Vorteil sein, der Erste zu sein, der diesen Markt besetzt. Alle die später in Konkurrenz zu diesen Pionieren treten, müssen mit einem deutlich höheren Aufwand für Marketing und Vertrieb rechnen, so dass auch hier Zeit gleich Geld ist.

Was bei dieser Übersicht über die verschiedenen Arten von Cost of Delay, bzw. Verzögerungskosten auffällt, ist, dass ihre Grösse nach unten immer weniger abschätzbar wird. Das liegt daran, dass auch der sich verspätende Liefergegenstand nach unten immer grösser und unkonkreter wird. Das bedeutet natürlich nicht, dass man in diesen Fällen nicht über eine Cost of Delay nachdenken sollte, man sollte aber diese Ungenauigkeit in den Schätzungen abbilden.

Feature Factory

Bild: Wikimedia Commons / Alien Property Custodian - Public Domain

Ein Begriff an dem man immer wieder vorbeikommt, wenn es darum geht, ein (negatives) Gegenstück zur agilen Produktentwicklung zu finden, ist die so genannte Feature Factory. Genauer erklärt wird er allerdings nur selten, und wenn, dann meistens nur mit Assoziationen zu Akkordarbeit und starren Kontrollstrukturen. Dabei steckt durchaus mehr dahinter, wenn man es sich näher anschaut. Starten wir damit in einer weit zurückliegenden Vergangenheit.

Im frühen 20. Jahrhundert sind die meisten industriellen Betriebe noch wie Manufakturen organisiert. Es gibt zwar bereits erste berufliche Spezialisierungen und Befehlsketten, die eigentliche Arbeit wird aber noch von Hand durchgeführt, in der Regel von mittelgrossen, crossfunktionalen Teams, die ihre Produkte (Kameras, Autos, Plattenspieler, etc.) Stück für Stück vollständig erstellen, was oft eher den Charakter von Einzelanfertigungen als von Serienfertigung hat.

Diese Serienfertigung kommt erst zu dieser Zeit auf, ihre Erfindung wird vor allem mit den Industriellen Frederick Winslow Taylor und Henry Ford verbunden. Sie sorgen dafür, dass die Arbeit auf hoch-spezialisierte Teams übergeht, die jeweils nur noch wenige, immer gleiche Handgriffe an nur einer Station einer motorisierten Fertigungskette (dem Fliessband) vornehmen. Dass daraus am Ende ein Produkt entsteht, wird durch das Management sichergestellt, das die Fertigungskette entwirft und überwacht.

Erst durch diese hochspezialisierte und teilautomatisierte Serien-, bzw. Fliessband-Fertigung werden Produkte so billig, dass sie mit Erfolg auf dem Massenmarkt verkauft werden können, was dazu führt, dass diese Methoden nach und nach von allen Firmen übernommen werden (bzw. dass die, die sich nicht darauf umstellen, vom Markt verdrängt werden). Zuerst geschieht das in den Fabriken, später aber auch in anderen Bereichen, z.B. in Grossküchen, grossen Büros oder in Call Centern.

Besonders die letzte Entwicklung ist dabei von Bedeutung: nach und nach werden im zwanzigsten Jahrhundert fast alle Wirtschaftszweige nach den Ideen von Winslow und Ford umgeformt, bis irgendwann der Eindruck entsteht, dass sie überall anwendbar und zielführend sind. Dass das dann irgendwann auf Fälle treffen muss, in denen das eben nicht der Fall ist, ist naheliegend. Und damit kommen wir zu einer dieser Ausnahmen, der Softwareentwicklung.

Auf den ersten Blick kann man auch in der Softwareentwicklung eine Art Fertigungskette für neue Funktionen (eben die Feature Factory) aufbauen. Am Anfang steht das Anforderungsmanagement, dann das Anwendungsdesign, dann das Schreiben des Code, die Integration der einzelnen Komponenten, die Qualitätssicherung und schliesslich die Auslieferung. Es scheint nahezuliegen, dafür sequenziell angeordnete Spezialistenteams aufzubauen. Das Problem bei diesem Vorgehen: man bekommt am Ende zwar Ergebnisse, aber leider nicht die, die man gebraucht hätte.

Bedingt dadurch, dass man Software per Copy & Paste vervielfältigen kann, kommt es bei ihrer Erstellung nie zu einer wirklichen Serienfertigung, stattdessen wird lediglich ein Einzelstück nach dem anderen erstellt und das dann gleichzeitig an alle Nutzer ausgeliefert. Da diese Einzelstücke aber jeweils individuell anders sind, müsste die "Software-Fertigungsstrasse" eigentlich jedes mal neu konzipiert werden, da sonst die spezialisierten Einzeltätigkeiten nicht sauber ineinandergreifen.

Das allerdings ist kaum realisierbar, alleine wegen des damit verbundenen Umgewöhnungs-Aufwands der jeweiligen Spezialisten. Die sinnvolle Lösung wäre daher eine Rückkehr zum Manufaktur-Prinzip. Crossfunktionale Teams mit relativ geringer Spezialisierung erstellen ein Software-Produkt nach dem anderen und passen ihre Abläufe dabei jedes einzelne mal so an, dass sie für die in diesem Fall vorhabdenen Erfordernisse passend sind. So weit, so (scheinbar) einfach.

In der Realität wird die eigentlich gut nachvollziehbare Tatsache, dass Softwareentwicklung sich nicht wie eine Fabrik organisieren lässt, von vielen Managern und Unternehmensberatern bis heute bestritten. Sei es wegen fehlendem IT-Bezug, aus Methodismus (das klappt doch überall, also auch hier) oder aus welchem Grund auch immer - wieder und wieder trifft man vor allem in grösseren Firmen auf Fälle, in denen Entwicklungsabteilungen oder -ressorts als Feature Factories organisiert sind.

Praktisch immer führt das zu einer von zwei Dysfunktionen: entweder ist die "Fertigungsstrasse" nicht so optimiert, wie es im jeweiligen Einzelfall nötig wäre, was zu Ineffizienz und Fehleranfälligkeit des Prozesses führt, oder das Design der neu zu bauenden Funktionen wird an den vorhandenen Erstellungsprozess angepasst - im Zweifel auf Kosten der Marktbedürfnisse, was geringere Akzeptanz beim Kunden und geringeren wirtschaftlichen Erfolg zur Folge hat.

Diese Entwicklungen sind der tatsächliche Grund dafür, dass in der Softwareentwicklung Feature Factories hoch problematisch und anti-agil (im Sinne von einschränkend für Geschwindigkeit und Flexibilität) sind. Und selbst wenn man es nie schaffen wird, jeden zu überzeugen - ein besseres Argument als die Ablehnung von gefühlter Akkordarbeit und starren Kontrollstrukturen sind sie auch.

The Case for Technical Excellence

Zu den Folgeerscheinungen der zunehmenden Verlagerung der Verantwortung für agiles Arbeiten zu Menschen ohne technischen Hintergrund (Managern und Coaches) gehört, dass die zentrale Rolle von technischer Exzellenz immer häufiger vernachlässigt wird. Kevlin Henney zeigt in diesem Talk auf, welche negativen Folgen das haben kann. Seine Kernaussage, die man nicht oft genug wiederholen kann: wer glaubt, dass er technische Exzellenz vernachlässigen kann, um schneller Features oder Business Value zu erzeugen, wird weder das eine noch das andere bekommen.

Was im Hinterkopf zu behalten ist: agile Vorgehensweisen sind mittlerweile auch in vielen Bereichen ausserhalb der Softwareentwicklung verbreitet. In solchen Kontexten ist technische Exzellenz entweder etwas Anderes (z.B. in der agilen Hardware-Entwicklung) oder hat ein Äquivalent in einer anderen Art der Umsetzungs-Expertise (z.B. im Event- oder Change Management). Wichtig ist eine wie auch immer geartete Umsetzungs-Exzellenz aber in jedem Fall.

Warum Mitarbeiter Probleme nicht melden

Eine wiederkehrende Beschwerde in vielen grossen Organisationen ist die, dass "die da oben" die Probleme der Umsetzungsebene gar nicht kennen würden. Tatsächlich ist daran auch häufig etwas Wahres, denn wer die Gelegenheit hat, sowohl mit den höheren als auch mit den unteren Hierarchie-Ebenen zu sprechen, der wird merken, dass die Umsetzung vieler grosser Pläne und Strategien ganz oder teilweise scheitert, ohne dass das dem Top-Management bewusst ist.

"Warum sagen die Mitarbeiter uns das dann nicht?" ist eine häufige Frage, die daraufhin auf den oberen Hierarchie-Ebenen gestellt wird, wenn man sie darauf aufmerksam macht. Sie ist durchaus berechtigt, aber leider nicht einfach zu beantworten. Um so dankbarer kann man John Cutler, einem Silicon Valley-Thought Leader, dafür sein, dass er häufige Gründe für eine derartige ausbleibende Kommunikation zusammengetragen hat (und zwar hier). Hier ist ihre Übersetzung ins Deutsche.

Gefühlt ausreichende Kommunikation

Es kann vorkommen, dass Mitarbeiter Probleme schon mehrmals nach oben kommuniziert haben und das Gefühl haben, das nicht nochmal wiederholen zu müssen, da diese ja mittlerweile bekannt sein sollten. Vor allem wenn diese Rückmeldungen über längere Zeiträume verteilt waren, kann das "von oben gesehen" den Eindruck erwecken, dass es keine nennenswerte Unzufriedenheit gibt.

Emotionale Erschöpfung

Wenn Missstände über einen längeren Zeitraum bestehen, ohne dass es zu wahrnehmbaren Verbesserungen oder Verbesserungsbemühungen kommt, kann es zu Erschöfungs- und Resignationseffeken kommen, die dazu führen, dass die Betroffenen sich mit diesen für sie frustrierenden Themen nicht mehr beschäftigen wollen, selbst wenn die Probleme ungelöst bleiben.

Gewöhnungseffekte

Ein anderer Effekt von über einen längeren Zeitraum bestehenden ungelösten Missständen kann sein, dass diese irgendwann als normal und darum als nicht mehr erwähnenswert empfunden werden. Ggf. kann das sogar zur Folge haben, dass Menschen, die in der Organisation ihre berufliche Sozialisierung erfahren haben (z.B. Auszubildenden), die Probleme nie bewusst geworden sind.

Kognitive Dissonanzen

Falls Mitarbeiter grosse Aufwände in den Versuch von Problembehebungen investiert haben, kann es sein, dass unbewusste Selbstrechtfertigungen stattfinden. Um das Gefühl haben zu können, dass diese Anstengungen nicht umsonst gewesen sind, kommt es zu einer unrealistisch positiven Wahrnehmung der Situation, selbst dann wenn es tatsächlich kaum zu Verbesserungen gekommen ist.

Verschobene Erwartungen

Ähnlich wie im Fall der Gewöhnungseffekte tritt bei den verschobenen Erwartungen das Gefühl ein, dass über einen längeren Zeitraum bestehende ungelöste Missstände der (neue) Normalfall sind. Der Unterschied liegt darin, dass die Dysfunktionalität zwar noch (emotionslos) erkannt wird, es aber keine Erwartung mehr gibt, dass irgendjemand ein Interesse an der Behebung haben könnte.

Lokale Unbedenklichkeit

Viele Dysfunktionen haben in der Gesamtsicht erhebliche Auswirkungen, führen in den verschiedenen Teilen der Ausführungsebene aber nur zu geringen Unannehmlichkeiten (z.B. dann wenn es nach einer Übergabe zu einer anderen Abteilung zu langen Wartezeiten kommt, bis dort die Arbeit weitergeht). Aus einer lokalen Sicht ist in solchen Fällen oft gar nicht erkennbar, dass Probleme vorliegen.

Konzentration auf den eigenen Verantwortungsbereich

Vor allem wenn viele verschiedene Missstände vorliegen, ist es eine häufige Bewältigungsstrategie, sich auf das zu konzentrieren, was im Bereich der eigenen Kontrolle liegt. Für Probleme die ausserhalb des eigenen Kontrollbereichs liegen fühlt man sich dann nicht mehr zuständig - auch nicht dafür, herauszufinden, wer zuständig ist, und sie dort zu addressieren.

Angst vor negativen Auswirkungen von Problem-Meldungen

Wer nach dem Ansprechen von Problemen negative Konsequenzen fürchten muss, wird das eher selten tun, ggf. sogar gar nicht. Zu diesen negativen Konsequenzen gehören dabei nicht nur Bestrafungen oder Mehrarbeit (durch den Auftrag, das Problem selbst zu lösen), sondern auch ein befürchteter Ansehensverlust der eigenen Person oder Einheit, durch deren Verbindung mit den Problemen.

Hedonistische Tretmühlen

Unter diesem Konzept versteht man die Tendenz, bzw. den Wunsch vieler Menschen, sich von negativen Ereignissen "nicht aus der Bahn werfen zu lassen". Bei einer negativen Veränderung von Zufriedenheits-Faktoren führt das dazu, dass eher neue gesucht werden, als dass an der Wiederherstellung der alten gearbeitet wird, da das "ein schnellerer Weg zum Glück" ist.

Die Quintessenz dieser Aufzählung: selbst bei offensichtlichen Problemen sollte man nicht zu sehr darauf vertrauen, dass diese von den Mitarbeitern gemeldet werden, es gibt verschiedene soziale und psychologische Phänomene, die dafür sorgen können, dass das unterbleibt. Um zu verhindern, dass es zu langfristig unentdeckten Missständen kommt, müssen auch die oberen Hierarchie-Ebenen selbst und aus eigenem Antrieb immer wieder danach suchen.

P.S.

Der Focus dieses Beitrages auf soziale und psychologische Phänomene der Umsetzungs-Ebene bedeutet nicht, dass die Ursachen fehlender Rückmeldungen ausschliesslich dort liegen. Auch in den mittleren und oberen Ebenen gibt es Faktoren, die dazu beitragen können. Die sind aber ein eigenes Thema.

Context Collapse

Bild: Wikimedia Commons / Sven-Sebastian Sajak (uncropped) - CC BY-SA 3.0

Jeder braucht ein Hobby, wie wir wissen. Meines ist es, sozialwissenschaftlich beschriebene Phänomene aus anderen Bereichen auf die agile Bewegung zu übertragen, von der Betriebswirtschaftschaft bis zur Politologie. Heute ist es eines aus der Kommunikationswissenschaft, das den schönen Namen Context Collapse trägt. Der Begriff wurde bereits in der Vergangenheit in neue Zusammenhänge übertragen, es passt also, das ein weiteres mal zu tun.

Entwickelt wurde der Begriff des Kontext-Kollaps von den beiden Amerikanern Erving Goffman und Joshua Meyrowitz, die beide beobachteten, dass Kommunikationsinhalte, die in kleinen oder homogenen Gruppen problemlos verständlich waren, bei einer Übertragung in grössere und diversere Gruppen (oder bei einer Kommunikation zwischen unterschiedlichen Gruppen) zu Missverständnissen und infolgedessen häufig zu Konflikten führten.

Die Ursache dafür sahen sie darin, dass in den kleinen oder homogenen Gruppen der Entstehungs- oder Intentions-Kontext einfach zu vermitteln war oder sogar bereits allen bekannt war. In den grösseren oder diverseren Gruppen war das dagegen nicht nur schwieriger, es kam ausserdem immer wieder dazu, dass die Kommunikations-Emfänger die Inhalte unbewusst in ihre eigenen, anders gearteten Kontexte einordneten, was in vielen Fällen zu geänderten Bedeutungen oder Interpretationen führte.

Goffmann und Meyrowitz beobachteten das Wegfallen (oder Kollabieren) von für die Kommunikation wichtigen Kontexten im Rahmen der Einführung von Massenmedien (die eine direkte Interaktion der Kommunikationsparteien verhinderten), Jenny Davis und David Jurgenson (zwei weitere Amerikanische Wissenschaftler) übertrugen es später auf die sozialen Medien und wiesen nach, dass kollabierende Kontexte auch in direkter Kommunikation zu Missverständnissen führen können.

Übertragen wir das auf die agile Bewegung. Dort wo es zur Einführung der verschiedenen agilen Frameworks und Praktiken kommt, treffen fast immer zwei Personengruppen aufeinander, deren Kommunikationsinhalte ohne das Wissen um den jeweiligen Entstehungskontext für die jeweils andere hochgradig missverständlich sein können: klassische Manager auf der einen Seite und agile Entwickler und Methodiker auf der anderen. Ein Context Collapse ist hochwahrscheinlich.

Die Aussagen eines klassischen Managements müssen vor dem Hintergrund bestimmter Rahmenbedingungen gesehen werden. Klassiker unter denen sind (meistens von oben vorgegebene) Budgetierungsprozesse, Planungszeiträume, Zielsetzungen und Aufgabenteilungen, durch die gewisse Grade an Unflexibilität und Determiniertheit funktionswichtig sind. Ohne das zu wissen können die kommunizierten Meinungen und Entscheidungen starr und bürokratisch wirken.

Umgekehrt existieren solche Rahmenbedingungen auch bei den agilen Entwicklern und Methodikern. Klassiker auf dieser Seite sind das Wissen um die disruptive Kraft sozialer Dynamiken oder technischer Komplexität, durch die eine zu detaillierte Planung ständig an der Realität scheitern muss. Ohne das Wissen um diesen Hintergrund kann der Eindruck entstehen, dass der Mehrwert von klaren Zielen und strukturiertem Vorgehen nicht verstanden wird.

Vor diesem Hintergrund betrachtet lassen sich viele der in agilen Transitionen auftretenden Konflikte anders betrachten. Ein sehr wahrscheinlicher Entstehungshintergrund dürfte oft sein, dass den beiden Seiten entweder nicht bewusst ist, wie kontextbedürftig ihre Kommunikation ist, oder dass sie das jeweilige Kontextwissen bei den jeweils anderen voraussetzen. Tritt in einem solchen Fall ein Context Collapse ein, sind Missverständnisse fast zwangsläufig.

Die oben genannten Wissenschaftler haben in ihrer Forschung aber auch einen Ausweg aus dieser Situation beobachtet. Statt die Entwicklung (ggf. unbewusst) einfach hinzunehmen, kann man die Situation eines Context Collapse auch bewusst und kontrolliert herbeiführen (sie beschreiben das als Context Collusion). Ist allen Beteiligten das bewusst, kann dann an einem gemeinsamen Kontext-Verständnis gearbeitet werden, wodurch das Risiko von Missverständnissen und Konflikten sinkt.

Monte Carlo Simulation Explained

Es ist nicht ganz klar wann es begonnen hat, aber seit über 10 Jahren wird in der agilen Community die Monte Carlo-Simulation als ein Weg angesehen, im Rahmen von propabilistic forecasting voraussichtliche Lieferzeitpunkte zu berechnen. Vereinfacht gesagt handet es sich dabei um die Ermittlung von Eintrittswahrscheinlichkeiten auf Basis randomisierter historischer Daten. In diesem Video wird erklärt wie das stattfindet.

Die Frage, die sich nach derartigen Einführungen jeder sofort stellt, ist - funktioniert das wirklich? Die Antwort ist wie so oft, dass es auf den Kontext ankommt. Die Aussagekraft ist höher (wenn auch komplizierter zu verstehen) als die von reinen Durchschnittswerten. Man muss sich aber bewusst machen, dass mehrere Voraussetzungen gegeben sein müssen: der Umfang der Anforderungen muss stabil sein, das umsetzende Team muss stabil sein und es darf keine Änderung der für die Umsetzungsgeschwindigkeit relevanten Umgebungsfaktoren geben. Ob das in einer Umgebung, in der agil gearbeitet wird, der Fall ist?

Will agile history be X-ed out?

Irgendwann reichte es ihm. Die Social Media-Plattform, auf der er seit über zehn Jahren zahllose Beiträge gepostet hatte, hatte sich nach einem Management-Wechsel mehr und geändert. Die Usability wurde schlechter, der Diskussionston rauher, die Kommerzialisierungs-Bemühungen aggressiver. Er wollte kein Teil davon sein, also zog er die Konsequenzen: er löschte seinen Account, und mit ihm alle Beiträge die er jemals erstellt hatte.

Um welche Social Media-Plattform es in dieser Geschichte geht kann man sich leicht vorstellen, es ist Twitter, bzw. X nach seiner Übernahme durch Elon Musk. Welcher Nutzer es ist, der seinen Account gelöscht hat, ist dagegen weniger offensichtlich, daher hier die Auflösung: es ist Chet Hendrickson, einer der Pioniere des Extreme Programming und einer der Verfasser des Manifests für agile Softwareentwicklung. Und damit kommen wir zum Thema dieses Beitrags.

Aufgrund ihrer Entstehung "in den Schatten" sind die ersten Jahre der verschiedenen agilen Frameworks (im Wesentlichen die 90er) kaum dokumentiert worden, schliesslich war damals noch nicht absehbar welche Bedeutung sie später bekommen würden. Diese unklare Entstehungsgeschichte hat an vielen Stellen zu Missverständnissen und Fehlinterpretationen geführt, zum Teil auch zu einer missbräuchlichen Begriffsverwendung.

Das Korrektiv zu diesen Tendenzen waren und sind die Urheber der verschiedenen agilen Frameworks selbst, die bis heute regelmässig darauf aufmerksam machen, wie ihre Ideen eigentlich gedacht waren und an welcher Stelle sie von anderen missverstanden und verfälscht werden. Ein Grossteil dieser Zwischenrufe (bzw. zumindest derer die dokumentiert sind) fand und findet auf Twitter/X statt, z.B. zum Ursprung des Begriffs User Story oder zu Missverständnissen um die Story Point-Schätzung.

Quelle: Twitter

Quelle: Twitter

An dieser Stelle wird das Problem erkennbar: viele der Pioniere der agilen Softwareentwicklung sind mittlerweile im hohen Alter angekommen, so dass abzusehen ist, dass ihre korrigierenden Zwischenrufe zurückgehen und irgendwann verstummen werden. Allerdings konnte man bis vor kurzem davon ausgehen, dass ihre Dokumentation auf Twitter/X bestehenbleiben würde, so dass es im Zweifel möglich wäre, auf sie zu referenzieren.

Angesichts der aktuellen Entwicklung bei Twitter/X muss man allerdings befürchten, dass dieses Archiv in seinem Bestand gefährdet ist. Die zu Beginn genannten Beiträge von Chet Hendrickson sind bereits verschwunden, mit Ron Jeffries und Martin Fowler haben schon weitere Pioniere und Verfasser des agilen Manifests ihren Unmut mit der aktuellen Entwicklung bekundet. Und sollte Elon Musks Plan umgesetzt werden, Twitter/X kostenpflichtig zu machen, könnte das zur Löschung weiterer bedeutender Accounts führen, deren Inhaber nicht bereit sind, Geld an ihn zu zahlen.

Ob es wirklich so kommen wird? Keiner kann es sagen, aber unwahrscheinlich ist es leider nicht mehr. Was kann man dagegen machen? Nichts, es sei denn man gehört zu den Menschen, die Elon Musk oder die Pioniere der agilen Bewegung beeinflussen können. Sind diese Daten irgendwo gesichert? Nur zum Teil in der Wayback Machine und unzugänglich ("embargoed") in der Library of Congress. Man kann eigentlich nur zusehen und abwarten was passiert.

Zugegeben, wir reden hier von einem Thema, das sehr in Richtung "Special Interest" geht. Aber für die Disziplinen der Technik- und Management-Geschichte und für alle, die daran interessiert sind, wie die verschiedenen agilen Praktiken und Frameworks entstanden sind und ursprünglich gedacht waren, wäre der Verlust der Dokumentation bei Twitter/X wirklich, wirklich schade.

Eine kurze Typologie der agilen Skalierungsframeworks

Grafik: Pixabay / GDJ - Lizenz

Sobald irgendwo mehrere agile Teams zusammenarbeiten sollen kommen sie ins Spiel: agile Skalierungsframeworks. Mittlerweile gibt es eine ganze Reuhe von ihnen, die alle ihre Fans und Skeptiker haben. Eine Frage wird dabei aber erstaunlich selten gestellt - gibt es Strukturmerkmale, anhand derer man sie grundlegenden Mustern zuordnen kann? Für ein Buchprojekt habe ich versucht, eine entsprechende Übersicht zu erstellen, die ich auch hier teilen möchte.

Wichtig für das Verständnis ist dabei, dass die einzelnen Vorgehensmodelle hier nicht im Detail vorgestellt werden sollen. Es geht darum hervorzuheben, was sie von den anderen unterscheidet und welche ihrer Elemente wesensbestimmend sind. Detailbeschreibungen zu jedem einzelnen gibt es an verschiedenen anderen Stellen, das hier ist ein Versuch einer grundlegenden Gruppierung, die einen Einstieg in das Thema der agilen Skalierung erleichtern soll.

Scrum-Skalierungsframeworks

Beginnen wir mit den Minimalisten. Die Scrum-Skalierungsframeworks LeSS (Large Scale Scrum) und Nexus haben den Anspruch, Scrum zu skalieren ohne ihm Meetings und Rollen hinzuzufügen. Ihre Grundidee: mehrere Scrum Teams teilen sich einen Product Owner, ein Backlog und eine Definition of Done und haben gemeinsame Plannings und Reviews, führen die dazwischenliegenden Sprints aber getrennt durch. Sehr unbürokratisch, für den Product Owner aber ggf. sehr fordernd.

Hierarchische Skalierungsframeworks

Im deutlichen Kontrast dazu führen hierarchische Skalierungsframeworks wie Scaled Agile Framework (SAFe) und Scrum@Scale oberhalb der Scrum Teams neue Hierarchieebenen ein, SAFe etwa den Product Manager und den Release Train Engineer, Scrum@Scale den Chief Product Owner und den Scrum of Scrums Master [sic]. Bei grösseren Vorhaben ist das nochmal erweiterbar, für weitere Hierarchieebenen können nochmal weitere Rollen geschaffen werden.

Dynamische / Fluide Skalierungsframeworks

Dynamische Ansätze wie FAST (Fluid Agile Scaling Technology) und Unfix stellen die Idee des crossfunktionalen und autonomen Teams in den Mittelpunkt. Bei grossen oder komplexen Produkten kann es sein, dass eine solche Einheit deutlich mehr als die üblichen zehn Personen umfassen muss. Um trotz dieser Grösse agil bleiben zu können ist es vorgesehen, dass sich innerhalb dieser stabilen Einheiten Untereinheiten je nach Bedarf bilden und wieder auflösen können. Quasi ein agiles Organigramm.

Kanban-Skalierungsframeworks

Aufgrund der "Open Source-Natur" von Kanban sind die Skalierungs-Möglichkeiten in diesem Bereich sehr wenig formalisiert, bzw. sehr individuell. Die grundlegende Idee ist aber eine Optimierung des Arbeitsflusses oder Wertstroms. Skalierung bedeutet in diesem Sinn, dass Umfang oder Anfangs- und Endpunkt des Wertstroms immer weiter definiert werden, etwa durch Einbeziehung von Zulieferern oder Parallel-Fertigungen. Bestehende Rollen und Hierarchien bleiben dabei zunächst unverändert.

Kommunikationsorientierte Skalierungsframeworks

Ähnlich wie bei den Kanban-Skalierungsframeworks verzichten kommunikationsorientierte Ansätze wie Flight Levels oder Open Space Agility zunächst auf neue Rollen und Strukturen. Stattdessen werden übergreifende Abhängigkeiten für alle sichtbar visualisiert (Flight Levels) oder in Grossgruppen-Formaten regelmässig mit allen Beteiligten besprochen (Open Space Agility). Basierend darauf können dann Kommunikation und Zusammenarbeit dort stattfinden wo es Sinn macht.

Sonstige Skalierungsframeworks

Über die gerade gennten agilen Skalierungsansätze hinaus gibt es auch weitere die immer wieder genannt werden, u. a. das so genannte "Spotify Model" und organisationsweite Objectives and Key Results (OKRs). Bei ihnen handelt es sich aber nicht um agile Skalierung im eigentlichen Sinn, sondern eher um eine kreative Neubenennung klassischer Organisationsprinzipien (Spotify = Matrix-Organisation, organisationsweite OKRs = Zielkaskadierung). Auch ok, nur ein anderes Thema als das hier.

Soviel zur Übersicht - aber was kann man jetzt mit ihr machen?

Eine guter Einsatzmöglichkeit ist, vor (!) dem Beginn einer wie auch immer gearteten agilen Skalierung zu überprüfen, welche dieser Grundmuster in der eigenen Organisation vermittelbar wären. Sind beispielsweise Scrum oder Kanban auf Teamebene gesetzt? Dann machen diese Ansätze vermutlich auch in der Skalierung Sinn. Wird Wert auf Hierarchien gelegt? Dann passen SAFe und Scrum@Scale. Soll maximale Flexibilität möglich sein? Dann passen die dynamischen Skalierungsframeworks besser.

Was durch ein derartiges Vorgehen möglich wird, ist eine Lösung die zur Aufgabenstellung passt, statt einer Lösung an die die Aufgabenstellung angepasst werden muss. Denn so merkwürdig es klingt - Variante zwei ist zur Zeit noch verbreiteter als Variante eins. Das umzudrehen kann nur im Interesse aller Beteiligten sein.