Kommentierte Links (LIII)

Bild: Unsplash / Compare Fibre - Lizenz

• Troy Magennis: Story Point Velocity or Throughput Forecasting: Does it matter?

In Bezug auf das in der (IT-)Kanban-Bewegung beliebte statistikbasierte Forecasting bin ich gleichermassen Fan und Skeptiker. Natürlich hat eine auf der Story Point-Velocity beruhende Planung grosse Schwächen, von denen Troy Magennis hier einige aufzählt. Zu beachten ist dabei aber: er geht von nicht-idealen agilen Teams aus, die aufgrund nicht gegebener Crossfunktionalität und fehlender Focussierung starke Abhängigkeiten nach aussen haben. Das ist zwar durchaus realistisch, völlig unabhängige Teams sind selten. Umgekehrt wird aber bei dem als Alternative vorgeschlagenen Durchsatz-Modell nicht erwähnt, dass auch das ideale Rahmenbedingungen braucht, z.B. ein stabiles System, in dem Arbeiten nicht abgebrochen werden und in dem das Leistungsvermögen der Teams nicht schwankt. Auch das ist in der Realität aber selten. Ein bisschen wird hier also mit ungleichem Mass gemessen. Letzten Endes gilt für beide Ansätze, dass sie Unplanbares nicht planbar machen können, weshalb man sich von Anfang an auf Planänderungen einstellen sollte.

• François Knuchel: Why aren’t Lean and Agile Collaborating?

  Mal wieder ein Artikel über die absoluten Basics. Die Unterschiede zwischen Agile und Lean dürften zwar schon oft erörtert worden sein, vermutlich aber selten so ausführlich wie hier von François Knuchel. Neben den offensichtlichen Besonderheiten arbeitet er auch einige heraus die in den meisten Betrachtungen untergehen, z.B. das Agile-Kanban ein eher linearer Prozess einzigartiger Einzelaufgaben ist, während Lean-Kanban aus wiederkehrenden Schleifen gleichartiger Arbeit besteht. Auch die Beobachtung, dass Agile aufgrund der Affinität zu IT und Open Source eine offenere Community hat als Lean ist ein interessanter Gedanke, vor allem in Verbindung mit der Hypothese, dass das eine Ursache der im Vergleich stärkeren Sichtbarkeit und Verbreitung ist. Wirklich zum Nachdenken anregend ist aber die Vermutung, dass die beiden Bewegungen sich kaum austauschen, weil sie sich zu parallelen Silo-Strukturen entwickelt haben. Damit wären sie genau da gelandet wo sie nicht hinwollen.
  

• Mark Lambertz: Matrjoschkas und das Prinzip der losen Kopplung

  Noch mehr zum Nachdenken. Wie oben in anderem Zusammenhang hervorgehoben wurde geht auch Mark Lamberts davon aus, dass Teams mit zu grossen Abhängigkeiten letztendlich nicht agil sein können. Sein Betrachtungsschwerpunkt liegt dabei allerdings nicht auf den "horizontalen Abhängigkeiten" von anderen Teams sondern auf den "vertikalen Abhängigkeiten" von höheren Hierarchiestufen. Konkret geht es um die von dort vorgegebenen globalen Aufgabenschnitte, aus denen die unteren Ebenen ihre lokalen Aufgabenschnitte ableiten müssen. Dass das Selbstorganisation hemmt ist offensichtlich, dass es irgendwie zu einem Zusammenwirken aller beteiligten Einheiten kommen muss aber auch. Mark Lamberts' Idee von "lebensfähigen Systemen, welche in ein übergeordnetes lebensfähiges System eingebettet sind" ist ein interessanter Ansatz um diesen Widerspruch aufzulösen, dürfte aber in der Umsetzung sehr anspruchsvoll sein.

• Stefan Kraus: Selbstorganisation im Arbeitsbereich „Bauhof“ des Amtes für Technik, Umwelt, Grün (TUG) der Stadt Herrenberg

  Den Blog des "Forum agile Verwaltung" mag ich sehr, da sich hier immer wieder Beispiele für Flexibilität und Selbstorganisation finden die weit aus der üblichen IT- und Projektmanagement-Blase herausführen. Alleine der bürokratische Titel der hier vorgestellten Behörde würde normalerweise dafür sorgen, dass es ohne nähere Betrachtung in eine der üblichen Klischee-Schubladen einsortiert wird. Nach der Vorstellung der dort eingeführten Arbeitsweisen sieht man dagegen einmal mehr Agilität dort wo man sie nicht vermutet. Und besonders bemerkenswert: hier wurde nicht irgendein bekanntes Framework eingeführt sondern ein eigenes Vorgehensmodell selbst entwickelt.

• Oliver Staley: Whatever happened to Six Sigma?

  Eine Vorstellung von dem was manche Kritiker der agilen Bewegung voraussagen bietet das Schicksal von Six Sigma. Einst ähnlich gehypt ist mittlerweile nicht mehr viel davon übriggebliebben. Die von Oliver Staley genannten Ursachen sind auch tatsächlich die, die gerade bei Scrum, SAFe & Co zunehmend zu betrachten sind: Kommerzialisierung, Hype-getriebene Anwendung auf unpassende Bereiche, Wahrnehmung als Mode-Erscheinung. Dass Agile den selben Weg gehen wird ist nicht zwangsläufig, ein warnendes Beispiel für das was schlimmstenfalls passieren könnte ist Six Sigma aber auf jeden Fall.

Deine Muda: Langfristige Detailplanung

Grafik: Pxhere / Mohamed Hassan - CC0 1.0

Neunter Teil der Deine Muda-Serie. Neben den sieben klassischen Mudas (無駄), also den nicht gewinnbringenden (und aus diesem Grund zu vermeidenden) Tätigkeiten des Toyota Production System, können auch weitere Mudas identifiziert werden. Welche das sind kann je nach Unternehmen und je nach Kontext unterschiedlich sein, weshalb diese hier nicht den Anspruch erheben kann kanonisch zu sein. Ressourcenverbrauchend und nicht gewinnbringend ist sie trotzdem: die langfristige Detailplanung.

Warum langfristige Detailplanung eine Muda ist, ist einfach zu erklären: überall dort wo Arbeit in einer komplexen Umgebung stattfindet (→ dort wo sich Menschen uns Systeme unvorhersehbar verhalten und auf unvorhersehbare Art und Weise mit einander interagieren¹) wird die Realität früher oder später zwangsläufig von der Planung abweichen. Sobald das geschieht müssen die Pläne an die geänderte Realität angepasst werden, wodurch die bisherige Planung automatisch obsolet wird.² Die bereits in sie investierten Aufwände waren umsonst.

Die Alternative zu diesem Vorgehen kommt ebenfalls aus dem Toyota Production System: Just in Time Delivery, oder für diesen Verwendungszweck abgewandelt: Just in Time Planning. Detailplanung sollte nur in überschaubarem zeitlichen Abstand zur Umsetzung stattfinden, da proportional zum diesem kürzer werdendem Abstand die Wahrscheinlichkeit sich ändernder Rahmenbedingungen abnimmt. Das Risiko für die Tonne zu arbeiten lässt sich so minimeren (um Missverständnissen vorzubeugen: das bedeutet keine Planlosigkeit, aber an die Stelle der Detailplanung tritt eine Vision).

Das Problem bei der Abschaffung der langfristigen Detailplanung: viele grosse Organisationen haben ihre gesamte Planungs- und Reportingstruktur auf sie ausgerichtet. Noch immer herrscht in ihnen der Glaube vor, dass man nur gut genug vorausdenken müsste um alle Eventualitäten zu berücksichtigen, und ein Abweichen von diesen Glaubenssätzen wird ignoriert oder sanktioniert (siehe auch die Antipattern der scheinbaren Imitation und der scheinbar umfassenden Planung). Für eine Verhaltensänderung ist also viel Überzeugungsarbeit nötig.

Einen Ausweg aus dieser Situation bietet - Ironie der Geschichte - ausgerechnet das meistens mit langfristiger Detailplanung einhergehende langfristige Detailreporting. Überall dort wo jeder einzelne Konzeptions-, Umsetzungs- und Testaufwand erfasst, festgehalten und mit einer Buchungsnummer versehen ist kann man problemlos aufzeigen wie viel Arbeitszeit (und damit Geld) sinnlos ausgegeben wurde, weil die Realität nicht mehr zum Plan passt. Die Muda wird damit sichtbar und messbar - und so zu einem gewichtigen Argument um an Veränderungen zu arbeiten.


¹Es gibt natürlich auch nicht-komplexe Umgebungen, aber um die soll es hier nicht gehen.
²In manchen Organisationen wird stattdessen versucht die Realität an die Planung anzupassen. Ein Thema für sich.

Jack of all trades, Scrum Master of none

Bild: Pixabay / Moise Theodor - Lizenz

Liest man im Scrum Guide nach welche Aufgaben ein Scrum Master alles übernehmen soll kann einem schnell schwindelig werden. Er soll das Team in Richtung Selbstorganisation coachen, soll Hindernisse beseitigen, Meetings moderieren, den Product Owner methodisch unterstützen und Change Management in der umgebenden Organisation betreiben. Je nach Umfeld sind noch weitere Themenfelder nötig: XP-Techniken, Liberating Structures, Design Thinking, Konflikt-Mediation, Skalierung, etc. etc. etc.

Es ist zwar nicht ausgeschlossen, dass es Menschen gibt die all das aus dem Stand beherrschen, viele sind es aber nicht. Da es den Beruf noch nicht lange gibt kommen meisten Scrum Master ursprünglich aus einem anderen Betätigungsfeld, Klassiker sind dabei Softwareentwicklungs-Spezialisierungen (Entwickler, Konzepter, Tester), Projektmanager oder IT-ferne Coaching-Berufe. Aus einem solchen Hintergrund heraus zu einem "universal gebildeten Spezialisten für alles" zu werden ist schwer, und vor allem dauert es Zeit.

Wenn man nicht den Luxus hat in einer Gruppe von Scrum Mastern zu arbeiten, in der einzelne Mitglieder sich unterschiedliche Schwerpunkte suchen können, bleibt die Wahl zwischen zwei Ausrichtungen: Spezialisierung und Generalisierung. Entweder man geht in einem (oder wenigen) Wissensgebieten in die Tiefe oder man erwirbt ein Grundwissen in möglichst vielen. In der überwiegenden Zahl der zu beobachtenden Fälle¹ fällt die Entscheidung auf Variante Eins.

Dass das problematisch ist, ist intuitiv ersichtlich, schliesslich werden wichtige Felder bewusst nicht beackert. Die wahre Dimension erschliesst sich aber wenn man bedenkt, dass in den meisten Fällen die Spezialisierung in den "teamnahen" Themenfeldern stattfindet. Um nicht falsch verstanden zu werden - gekonnte Meeting-Moderation und gute Coaching-Techniken sind wichtig, wenn für sie aber (agil) strukturiertes Produktmanagement und das Alignment mit der umgebenden Organisation wegfallen ist nichts gewonnen. Die Scrum-Implementierung wird dann schwere Dysfunktionen haben.

Die Alternative ist vielversprechender: ein Grundverständnis aller relevanten Bereiche sogt zum einen dafür, dass sich nicht irgendwo unbemerkt Antipattern ausbreiten können, zum anderen ist es die Ausgangslage dafür, zielgerichtet andere Teammitglieder zur eigenen Entlastung einbinden zu können. Zum Beispiel kann die Meeting-Moderation in den meisten Fällen von Teammitgliedern selbst übernommen werden, so dass dort nur noch eingesprungen werden muss wenn ein neutraler Vermittler nötig ist.²

Zuletzt ist ein breites Grundverständnis die Voraussetzung dafür, dass in späteren Phasen der Selbstentwicklung entschieden werden kann wo eine Vertiefung der Kenntnisse den grössten Mehrwert stiften kann. Wichtig ist dabei aber die Reihenfolge: erst das breite Verständnis, dann die Vertiefung in einzelne Themen. Nicht umgekehrt.


¹Basierend auf der eigenen Beratungserfahrung und dem Austausch in der agilen Community im Rheinland
²Ironie der Geschichte: diese Tätigkei zu delegieren fällt vielen Scrum Mastern besonders schwer

Das beste agile Skalierungs-Framework der Welt: Reden

Bild: Pexels / Christina Morillo - Lizenz

In den nächsten Tagen werde ich an einer Podiumsdiskussion teilnehmen dürfen, die den etwas reisserischen Titel "Battle of the Frameworks" trägt. Das Ziel: verschiedene agile Skalierungs-Frameworks nebeneinander zu halten, Vorteile und Nachteile zu vergleichen und wenn möglich herauszufinden welcher Ansatz in welcher Situation hilfreich sein könnte und welcher eher nicht.

In der Vorbereitung habe ich mir durch den Kopf gehen lassen welche der bekannten Skalierungs-Frameworks ich schon im Einsatz gesehen habe und bin auf einige gekommen: Scrum@Scale, LeSS, Nexus, SAFe, (Pseudo)Spotify, Flightlevel-Kanban und einige Hybrid-Modelle aus Agile und Wasserfall waren dabei, alle mit Aspekten die gut funktioniert haben und solchen bei denen das nicht der Fall war. Mir ist aber auch klar geworden, dass ich einen absoluten Favoriten habe - einfach miteinander reden.

Bis zu einer Größe von mindestens fünf Teams kommt man damit erstaunlich weit (und ich kenne nicht viele Fälle in denen mehr als fünf Teams Sinn gemacht haben). Wenn die Produktmanager und Product Owner den gemeinsamen Release zusammengehörender Features planen wollen können sie das tun indem sie miteinander reden. Wenn die Entwickler Coding-Standards und Schnittstellen definieren wollen können sie miteinander reden. Wenn die UX-Designer ein übergreifendes Look and Feel herbeiführen wollen können sie miteinander reden, etc.

Das passiert grundsätzlich zwar auch in allen anderen Frameworks, der Unterschied ist, dass Zeit, Ort und Gruppe dabei reglementiert sind. Planung findet im PI-Planning statt, die Klärung von Abhängigkeiten im Scrum of Scrums, die Erarbeitung von Konventionen in der Community of Practice - für nahezu jedes Anliegen lässt sich ein passendes Format finden, dass dann aber auch Risiken in sich birgt: wenn für ein Anliegen kein Format da ist oder wenn dieses erst zu einem anderen Zeitpunkt stattfindet, dann findet eine Klärung oft nicht statt.

Die Alternative: sobald der Bedarf nach Abstimmung aufkommt kann man einfach zu den Betroffenen hingehen, kann sie fragen ob sie einen Beitrag zum Thema liefern können, wann sie Zeit dafür haben und wen sie sonst noch dazuholen würden. Wenn es soweit ist spricht man miteinander, einigt sich und klärt welche nächsten Schritte zu welchem Zeitpunkt gemeinsam angegangen werden sollen. Und das ist es, mehr als das ist in den meisten Fällen nicht nötig.

Dass dieses verblüffend einfache Modell in der Realität kaum vorkommt hat natürlich Gründe: räumliche Trennung, Überplanung durch zu viele Termine, fehlende Entscheidungskompetenzen, fehlende Einsicht in grössere Zusammenhänge und zu viele Abhängigkeiten. Aber an dieser Stelle gibt es auch gute Neuigkeiten - all das kann man ändern, man muss es nur wollen. Und wenn das geschafft ist kann man alle komplizierten Zusammenarbeitmodelle den Grossprojekten überlassen und sich auf das gemeinsame Reden beschränken.

Making things better for everyone

Es ist ein Thema über das man lange diskutieren kann: gehören "weiche Themen" wie Augenhöhe, Diversität, etc. zur agilen Organisationsentwicklung dazu? Wenn sie dazugehören droht das Begriffsverständnis sehr in die Breite zu gehen, wenn sie nicht dazugehören kann das Folgen für die geistige Beweglichkeit der Belegschaft haben. Einen weiteren Aspekt kann man aus diesem Vortrag von Jill Wetzler mitnehmen: durch ihre diversitätsfördernden Massnahmen zeigen Unternehmen wie offen, datengetrieben oder feedbackorientiert sie sind - oder nicht sind.

Agile Bauprojekte (II)

Bild: Wikimedia Commons / Koma Modular Construction - CC BY-SA 3.0

Manchmal ist es erstaunlich durch welche Artikel besonders heftige Reaktionen ausgelöst werden. Der über agile Bauprojekte gehört definitiv dazu. Das würde doch alles gar nicht stimmen, hiess es mehrfach, das wäre am Thema vorbei und irreführend. Denn: dort ginge es gar nicht um Bauvorhaben im eigentlichen Sinn sondern nur um Renovierungen. Dort wo wirklich neu gebaut würde, da wären agile Ansätze nicht anwendbar. Nun ja. Vermutlich nicht überall, aber das hatte auch niemand behauptet. Grundsätzlich geht es aber sehr wohl, wenn man es denn will und sich auf bestimmte Voraussetzungen einlässt.

Beginnen wir mit der Problem-, bzw. Aufgabenstellung. Unter welchen Umständen könnte es dazu kommen, dass Gebäude in kurzer Zeit aufgebaut, umgebaut, abgebaut und an anderer Stelle neu errichtet werden müssen? Etwa dann wenn ihr Eigentümer häufig umzieht und seine Heimat mitnehmen möchte. Oder dann wenn sich der Bedarf nach Wohn- und Arbeitsraum häufiger ändert. Oder dann wenn es Schwankungen bei der Nutzungsintensität gibt oder unterschiedlich schnellen Verschleiss unterschiedlicher Gebäudeteile.

Sich an diese sich ändernden Gegebenheiten anzupassen wäre zwar mit den klassischen, sprichwörtlich fest gemauerten Baustilen nur schwer möglich, es gibt aber einen anderen mit dem sich diese Herausforderung bewältigen lässt: mit der Modulbauweise. Das Gebäude besteht in diesem Fall aus mehreren vorgefertigten Modulen, die sich je nach Bedarf kombinieren, neu arrangieren, anbauen oder entfernen lassen. Die Bauarbeiten bestehen dann nur noch aus dem Ebnen des Bodens, dem Aufstellen und Verbinden der Module und dem Anschliessen von Rohren und Leitungen.

Agilität wird so in verschiedenen Weisen ermöglicht: bis relativ spät im Baufortschritt können die Pläne angepasst werden. Grösser, kleiner oder anders angeordnet, verschiedene Modifikationen sind möglich. Auch ein schnelles Vergrössern oder Verkleinern fertiger Gebäude ist möglich, etwa wenn die Kinder ausziehen oder wenn in einem gewerblich genutzten Gebäude mehr Arbeitsplätze entstehen oder in einem Wohnheim mehr Zimmer gebraucht werden. Einzelne Module lassen sich austauschen, z.B. wegen Brandschutz, und da jedes Modul auf einen Laster passt kann sogar das ganze Haus versetzt werden.

Soweit die Theorie, aber gibt es das auch in der Realität? Ja, gibt es. Nicht zu oft aber vorhanden und erprobt. Eher selten sind modular aufgebauter Wohnhäuser, die sich bei Bedarf erweitern und verkleinern lassen. Häufiger sind temporäre Häuser, mit denen etwa München oder Brüggen am Niederrhein Wohnraum für zugezogene Studenten schaffen, die am Anfang keine Wohnung finden. Auch während der Flüchtlingswelle 2016 wurden Modulbauten genutzt, etwa in Hannover, Gelsenkirchen, Augsburg und Marburg. Und ein besonderer Fall sind schnell auf- und umbaubare Krankenhäuser in Krisengebieten.

Giga Berlin will come together at an impossible-seeming speed. The prefabricated construction method in Germany is extremely impressive.

— Elon Musk (@elonmusk) July 27, 2020

Den Maschinenpark in Ordnung halten

Bild: Wikimedia Commons / Mixabest - CC BY-SA 3.0

Stellen wir uns die folgende Situation vor: eine Firma besitzt zur Herstellung ihrer Produkte eine grosse Produktionshalle voller Maschinen. Diese sehen auf den ersten Blick gut aus, bei näherer Betrachtung finden sich aber zahlreiche Beschädigungen. Keilriemen sind rissig, Schrauben haben gebrochene Gewinde und Verstrebungen sind stark verrostet. Solche Dinge. Die Schäden sind offensichtlich und allgemein bekannt, repariert wird aber nichts. "Dafür ist keine Zeit" heisst es als Begründung, "wir sind voll damit beschäftigt Güter zu produzieren." Was wäre von dieser Firma zu halten?

Nicht viel, wäre die Antwort. Denn selbst wenn die Auftragslage für eine Vollauslastung aller Maschinen sorgt ist eine unterlassene Instandhaltung fahrlässig. Mit zunehmendem Verschleiss wird es schwerer die Schäden zu reparieren, ab einem bestimmten Punkt weiten sie sich aus auf bisher nicht betroffene Teile, irgendwann bricht der Betrieb zusammen und muss in einer langen und aufwändigen Reparaturphase wieder aufgebaut werden - mit Kosten die wesentlich höher sind als es die kleinen Reparaturen zu Beginn gewesen wären.

Und doch ist es so, dass dieses widersinnige Verhalten permanent stattfindet, und zwar in zahlreichen Unternehmen, quer durch alle Branchen. Allerdings gibt es dabei eine Besonderheit: was hier nach und nach verfällt sind keine Maschinen sondern Software. Bugs werden nicht gefixt, schlechte Architektur wird nicht geradegezogen, fehlende Lastfähigkeit wird ignoriert. Die Folgen sind dagegen die selben wie bei der Maschine: die Probleme häufen sich und verstärken sich gegenseitig, bis irgendwann Nichts mehr geht und alles generalüberholt werden muss.¹ Umsatz gibt es in dieser Zeit keinen mehr.

Bereits bei einem sich nicht verändernden System wäre das alles ein Grossproblem, dort wo regelmässig Um- und Ausbauten stattfinden müssen wird es zu einem riesigen. Dort wo intensiver Wettbewerb oder gesetzliche Regulierungen häufige Änderungen erfordern wird die Arbeit an einem nicht gewarteten System das Auftreten von Problemen wahrscheinlicher machen. Es ist wie bei einem Jenga-Turm - es ist nicht mehr die Frage ob eine Modifikation zum Zusammenbruch führt sondern nur noch wann das passiert. Und wenn dadurch Zieldaten verfehlt werden werden die Wettbewerber erfreut reagieren - und die Aufsichtsbehörden verärgert.

Schon in einem stabilen Umfeld macht es also grossen Sinn "den Maschinenpark in Ordnung zu halten", in einem dynamischen ist das erst recht der Fall. Und doch - häufig passiert es nicht. Das kann vielfältige Gründe haben: eine übermässige Focussierung auf kurzfristige Ziele, fehlendes technisches Verständnis der entscheidenden Personen und falsch verstandene Sparsamkeit dürften die häufigsten sein. Das in den grossen Kontext zu setzen und in vernünftigere Bahnen zu lenken muss in solchen Fällen ein vorrangiges Ziel sein. Sonst wird schon bald auch von diesen Firmen nicht mehr viel zu halten sein.


¹Was schlimmstenfalls Monate dauern kann.

Demographie

Bild: Pixabay / Geralt - Lizenz

Irgendein Algorithmus ist Schuld. Ohne danach gesucht zu haben hatte ich plötzlich das Video vom Vortrag The Scribe's Oath von Bob Martin auf dem Bildschirm. Es ist mittlerweile über zwei Jahre alt, und nach dem Ansehen möchte ich die englischen Bewertung, "it aged well" vergeben. Was bei mir hängen geblieben ist, ist aber nicht der eigentliche Inhalt (eine Art Hippokratischer Eid für Software-Entwickler) sondern eine Nebenbemerkung: ab Minute 17 versucht er nachzuvollziehen wie sich die Gesamtzahl der Software-Entwickler auf der Erde entwickelt und kommt auf einen atemberaubenden Schluss: die Zahl verdoppelt sich alle zwei bis fünf Jahre. [Edit: er hat auch etwas dazu geschrieben]

Seine daraus folgende Erkenntnis: solange das so bleibt (und nichts spricht dagegen, dass es sich ändert) wird die Mehrheit der Entwickler immer eine Berufserfahrung von nur wenigen Jahren haben. Man kann das kritisch sehen, so wie Bob Martin es tut, und ethische Richtlinien fordern. Man kann aber auch die Chance darin sehen. Wer erst wenige Jahre im Beruf ist wird in der Regel noch offen sein für Neues, nicht auf Gewohntem beharren, nicht alles so machen wollen "wie immer" und Veränderung nicht als Störung empfinden. Vermutlich ist das einer der grossen, unterschätzten Faktoren dafür, dass agile Ansätze vor allem in der IT entstanden sind und hier auch bestehen bleiben.¹

Weitergedacht bedeuten diese Faktoren aber nicht, dass die "jugendliche Wechselbegeisterung" ein Charakteristikum aller IT-Unternehmen und Abteilungen sind - in kaum einer Firma steigt die Anzahl der Beschäftigten bremskurvenartig an. Ab einer bestimmten Grösse wird kaum noch neu eingestellt, so dass es zu einer demographischen Polarisierung kommt: auf der einen Seite die relativ junge Belegschaft in Startups und Neugründungen, auf der anderen Seite die älteren Mitarbeiter der Firmen die schon in den 80ern und 90ern auf Digitalisierungslösungen gesetzt haben. Selbst in der scheinbar immer modernen IT findet man hier Strukturkonservativismus, Sicherheitsfixierung, Groupthink und ähnliche Phänomene, die häufig zu verkrusteten, bürokratischen Strukturen führen.

Noch einmal weitergedacht ergibt sich für die nächsten Jahre aber ein gegenläufiger Trend. Dort wo IT-Abteilungen in den 80ern und 90ern aufgebaut worden sind steht in absehbarer Zeit ein Generationenwechsel an. Bei manchen Mittelständlern und in vielen IT-Abteilungen von Grossunternehmen sind die Entwickler im Schnitt Mitte bis Ende 50, die nächste Verrentungswelle ist also absehbar.² Da die nächste, bereits in den Startlöchern stehende Generation deutlich jünger sein wird bedeutet das aber, dass die Offenheit für Neues bald wieder deutlich grösser sein wird. Und da die Unternehmen für die gefragten Fachkräfte attraktiv sein wollen werden auch sie nicht umhinkommen das zuzulassen und zu fördern. Die immer zahlreicher werdenden "New Work"-Programme sind Teil dieser Entwicklung.³

Natürlich besteht bei solchen Betrachtungen immer die Gefahr unzulässiger Verallgemeinerungen, trotzdem deuten die Faktoren aber darauf hin: die demographische Entwicklung sorgt dafür, dass die Agile Bewegung sich ständig erneuert, und dass zur Zeit der nächste "Agilisierungs-Schub" auf die IT-Branche zurollt.


¹Ja, es gibt auch junge unflexible Entwickler und alte die hochagil sind. Es geht aber um Mittelwerte.
²Genaugenommen ist es in der IT fast überall die erste.
³Wobei der Unterschied zwischen Agilität und New Work nochmal ein eigenes Thema wäre.

Chaos doesn't cause problems, it reveals them

Alleine das Wort schreckt viele ab - Chaos Engineering, das klingt nach Unordnung, nach Unvorhersehbarkeit und nach Kontrollverlust. Das kann keiner wollen! Das Problem: diese Zustände existieren trotzdem, und zwar überall (solange wir von IT und anderen komplexen Produkten reden). Nora Jones gibt einige Einblicke wie dem begegnet werden kann, wertvoll ist aber vor allem die andere Seite ihres Vortrags: wie sich eine Kultur des Chaos Engineering in einem Unternehmen etablieren lässt.