Donnerstag, 21. Januar 2021

Verschachtelte Sprints

FS
Bild: Pixabay / Hannah Alkadi - CC0 1.0

Im Kosmos der agilen Frameworks gibt es Begriffe die niemand kennt, hinter denen sich aber Phänomene verbergen die in vielen Teams so alltäglich sind, dass es niemandem auffällt, dass sie keinen bekannten Namen haben. Verschachtelte Sprints (auf Englisch "nested Sprints") gehört in diese Kategorie. Kaum jemand nennt sie so, dort wo Scrum oder andere iterative Ansätze angewandt werden sind sie aber durchaus häufig anzutreffen.


Konkret verbergen sich dahinter mehrere aufeinanderfolgende Sprints deren Länge genau einem grösseren Zeitraum (der auch Sprint heissen kann, aber nicht muss) entspricht. Diese Anordnung - ein Objekt das mehrere andere Objekte enthält - entspricht genau der üblichen Definition von Verschachtelung. Die Benennung passt also. Nur - warum macht man so etwas? Die naheliegende Antwort: um die Arbeit von Scrum-Teams in grössere Planungs- und Lieferzyklen zu integrieren oder um Synchronisierungen zu erleichtern.


Häufig anzutreffen ist in diesem Zusammenhang ein "Einschachteln" in einen klassischen Planungszyklus, z.B. einem Quartals-, Halbjahres- oder Jahresplan. In einer klassisch aufgestellten umgebenden Organisation kann das ein einfacher erster Schritt in Richtung Agilität sein, da es die bestehenden Budgetierungs- und Planungsprozesse noch nicht angreift und so Konflikte vermeidet. Es besteht aber das Risiko, dass Sprints dadurch bewusst oder unbewusst lange im Voraus verplant werden, wodurch die eigentlich gewünschte Flexibilität verlorengeht.


Eine ebenfalls häufige Hybridform zwischen agilem und klassischem Vorgehen liegt vor, wenn mehrere Sprints der Dauer zwischen zwei Meilensteinen eines klassisch arbeitenden Teams entsprechen. Das macht vor allem Sinn wenn dieses andere Team zwar eine langfristige Grobplanung, dafür aber einen kürzeren Ausdetaillierungs-Rhythmus hat (eine so genannte Rolling Wave-Planung). Auch bei starrer geplanten Meilensteinen ist eine Synchronisierung mit Sprints möglich, dann aber erneut mit dem Risiko Flexibilität einzubüssen.



Selbst wenn verschachtelte Sprints vor allem in Hybrid-Kontexten häufig sind gibt es sie auch dort wo nur (mehr oder weniger) agile Teams zusammenarbeiten. Am bekanntesten dürften dabei die so genannten "Program Increments" im Scaled Agile Framework (SAFe) sein, die in der Regel vier bis fünf Sprints umfassen, ein anderes Beispiel sind die "light-weight, risk-based milestones" aus dem zum PMI gehörenden Disciplined Agile.


Zuletzt können mehrere Scrum Teams ihre Sprints ineinander verschachteln, etwa wenn ein Teil von ihnen Sprintlängen von einer Woche hat und ein anderer Teil von zwei Wochen. Ein Szenario in dem eine derartige Synchronisierung Sinn macht wäre zum Beispiel eines in dem gemeinsame Sprint Reviews stattfinden um die Kalender der Stakeholder zu entlasten. Ein anderes wäre gegeben wenn Nutzer einer Software um eine Zusammenlegung der Produktions-Releases am Sprintende bitten, um sich nur ein- oder zweimal pro Monat auf ein neues System-Verhalten einstellen zu müssen.


Zusammengefasst: es gibt viele gute, halbwegs gute oder schlechte Gründe dafür verschachtelte Sprints einzusetzen. Da nicht immer klar ist mit was man es zu tun hat (und da sich die Bewertung auch ändern kann) ist es sinnvoll ein regelmässiges Inspect & Adapt durchzuführen. Zum Glück ist das in derartigen Konstellationen leicht - gleichzeitig endende Sprints sind gute Anlässe für gemeinsame Retrospektiven.

Montag, 18. Januar 2021

Verknappung als Treiber für Kulturwandel

FS

Über die Jahre habe ich einige Versuche erleben dürfen Unternehmenskulturen zu verändern, und Simon Sinek fasst es gut zusammen: viele werden betrieben wie Marketing-Kampagnen, durch die möglichst viele Menschen möglichst schnell überzeugt werden sollen. Leider ist auch seine darauf aufbauende Beobachtung richtig, die meisten davon sind bestenfalls relativ erfolgreich. Sein Ansatz ist erkennbar anders - er basiert darauf sich auf die Gruppe der Early Adopters zu konzentrieren und zu Beginn die Möglichkeiten zur Teilnahme zu verknappen. Dadurch steigt in der Wahrnehmung des restlichen Unternehmens die Wertigkeit Change-Programms und damit auch der Wunsch daran teilzunehmen.



Man kann sicherlich lange darüber diskutieren wie realistisch ein derartiger Umsetzungsplan ist und auf welche Widerstände er stossen dürfte, sein Vortrag ist es aber auch aus einem zweiten Grund wert gesehen zu werden - er überträgt die bekannte Gruppeneinteilung potentieller Kunden innovativer Produkte auf Kulturwandel-Programme (Innovators, Early Adopters, Early Majority, Late Majority, Laggards). Das ist eigentlich naheliegend, wird aber (noch) zu selten gemacht.

Donnerstag, 14. Januar 2021

Digitalisierung (V)

FS
Grafik: Pixabay / Geralt - CC0 1.0

Einer der Gründe wegen denen ich diese kleine Website betreibe ist, dass ich das hier gesammelte Material zur Wissensvermittlung (und Meinungsäusserung) bei meinen Kunden einsetzen kann - und dass sie auch danach noch dauerhaft darauf zugreifen können. In diesem Zusammenhang sind nach und nach verschiedene Inhalts-Typen entstanden, unter anderem auch einer der mittlerweile so häufig geworden ist, dass er jetzt eine eigene Kategorie bekommt: die der Begriffsdifferenzierungen, in der es darum geht, dass man viele Begriffe auf unterschiedliche Weisen verstehen kann.


Auch heute gibt es wieder eine solche Differenzierung, diesesmal mit einem Klassiker: der Digitalisierung. Denn (Surprise!) auch hinter diesem Wort können sich durchaus verschiedene Bedeutungen verbergen. Diese hier sind aus meiner Sicht die Wichtigsten:


Digitalisierung von Dokumenten

Die vermutlich erste Variante der mit der die meisten der heute Berufstätigen in Kontakt gekommen sind, z.B. weil viele Universitäten seit Ende der 90er von ihren Studenten verlangen, dass Referatsunterlagen und Hausarbeiten auch als Word- oder Powerpoint-Dokument abzugeben sind. In vielen Organisationen bis heute die primäre Form der Digitalisierung. Ein Beispiel dafür wäre der Bundestag, der alle öffentlich zugänglichen Dokumente einfach in PDFs umwandelt und auf seine Website stellt.


Digitalisierung von Kommunikation

Ebenfalls eine grundlegende Form. Zu nennen ist hier zunächst die Digitalisierung der schriftlichen Kommunikation, die zunächst in Form von Emails und später in Messenger-Diensten wie WhatsApp stattfand, noch später kamen dazu die Digitalisierung von Gesprächen mit Voice over IP und von visueller Kommunikation mit den verschiedenen Videoconferencing-Diensten wie Skype oder Zoom. Da über sie nicht nur direkte Kommunikation sondern auch Meetings stattfinden gibt es einen fliessenden Übergang zum nächsten Typ.


Digitalisierung von Arbeitsprozessen

Wenn heute in grossen Organisationen Digitalisierungsprojekte gestartet werden ist meistens diese Variante gemeint, die sich in weiten Teilen mit der Prozess-Automatisierung überschneidet. Moderne Posteingangssysteme sind beispielsweise in der Lage bei eingehender Post die zuständige Abteilung zu erkennen und an sie weiterzuleiten, was früher von Hand passiert wäre. Ein Problem kann dabei auftreten wenn "historisch gewachsene" Abläufe eins zu eins digitalisiert werden. Mit den unsterblichen Worten von Thorsten Dirks: "Wenn sie einen Scheißprozess digitalisieren, dann haben sie einen digitalen Scheißprozess."


Digitalisierung von Geschäftsmodellen

Der heilige Gral der heutigen Digitalisierung, wenn man so will. Die Übertragung ganzer Geschäftsmodelle in die digitale Form macht völlig neue Produkte und Dienstleistungen möglich, etwa im Fall von Streaming-Diensten, die nicht nur ein digitalisierter Video-Versand sind, sondern auch Empfehlungs-Algorithmen und interaktive Filme umfassen oder im Fall von digitalen Notenheften, die es durch Software möglich machen aus Orchesterwerken einzelne Stimmen zu extrahieren, die Tonart einzelner Passagen zu verändern oder am Konzert-Ton zu erkennen wann umgeblättert oder gescrollt werden muss.


Digitalisierung von Kreativprozessen

Die höchste Stufe an der aktuell gearbeitet wird, und dazu eine die für viele Menschen leicht gruselig ist, da sie in einen Bereich hineingeht von dem man bis vor kurzem glaubte, dass ihn nur das menschliche Gehirn beherrscht. Da sich diese Entwicklung mit der (final noch ungeklärten) Frage überschneidet was eigentlich Kreativität ist fehlt hier noch eine allgemein anerkannte Definition. Klar ist aber auch, dass bereits heute Tätigkeiten von Computern ausgeübt werden die man früher als kreativ bezeichnet hätte, etwa das Malen von Bildern oder das Schreiben journalistischer Texte.


Digitalisierung des Bewusstseins

Im Moment noch Science Fiction. Auch hier besteht das Problem, dass die Phänomene "Intelligenz" und "Bewusstsein" nicht genau definiert sind, es besteht aber die theoretische Möglichkeit, dass der technische Fortschritt irgendwann zur technischen Singularität und künstlichem Bewusstsein führt. Eine mit Bewusstsein ausgestattete künstliche Intelligenz könnte dann (neben vielem Anderen) in der Lage sein selbst unternehmerische Entscheidungen zu treffen. Nach allem was wir wissen wäre das die Endstufe dessen was wir als Digitalisierung bezeichnen.

Montag, 11. Januar 2021

Der Vorteil von SAFe (I)

FS
Bild: Pexels / Skitterphoto - CC0 1.0
Der zunehmende Wunsch grosser Unternehmen durch Agilität erfolgreich zu werden hat im letzten Jahrzehnt zum Entstehen und zum Aufstieg des Scaled Agile Framework (SAFe) geführt. Das Problem an dieser eigentlich begrüssenswerten Entwicklung ist, dass sich in ihm vieles von dem wiederfindet was die agile Bewegung eigentlich überwinden wollte: hohe Regulierung sowie Strukturen und Abläufe die der "alten Welt" sehr ähnlich sind. Für viele agile Practitioner, Coaches und Scrum Master hat SAFe daher wenig mit echter Agilität zu tun.

Ohne diese Probleme bestreiten zu wollen kann man auf der anderen Seite in SAFe aber durchaus das Potential sehen agile Transitionen voranzutreiben. Es gibt sogar Aspekte von Transitionsvorhaben die mit ihm einfacher zu erreichen sind als mit anderen Frameworks, und unter diesen ist vor allem zu nennen, dass es mit ihm einfacher ist ein eher traditionelles Management davon zu überzeugen sich überhaupt auf die Veränderungen einzulassen.

Ursächlich dafür sind nachvollziehbarerweise die weiter oben genannten Faktoren die auf die agile Comunnity abstossend wirken, also Regulierung, Hierarchie und längere Lieferzyklen. Ein Management das so sozialisiert wurde, dass es an diesen Prinzipien hängt, wird SAFe ansprechender finden als z.B. LeSS. Und da auch in SAFe (gebremste, aber doch vorhandene) Feedbackschleifen und Dezentralisierungen eingebaut sind gelangen diese so in die Organisation. Sie mögen dann zwar noch eingeschränkt sein, aber sie sind schonmal eingeführt.

In diesem Zusammenhang findet sich mitunter das Argument, dass SAFe im Rahmen einer agilen Transition ein früher Zwischenstand ist, über den man hinauswachsen kann sobald man die agilen Prinzipien verinnerlicht hat. Das kann man so sehen (und dort wo es wirklich zu einer Verinnerlichung gekommen ist wird es tatsächlich entweder formell oder informell zum Regelabbau kommen), man muss sich aber bewusst sein, dass das kein Automatismus ist. Viele Organisationen werden mit SAFe zufrieden sein.

Vielleicht ist aber auch genau das ein weiterer der Vorteile des Scaled Agile Framework. Es ermöglicht Organisationen nur "ein bisschen agil" zu werden. Natürlich muss jeder Manager der das so entscheidet sich bewusst sein, dass man damit auch nur ein bisschen von den Vorteilen bekommt die mit Agilität verbunden sein können. Aber wenn das bewusst so gewollt wird ist eben auch klar - es ist noch immer ein Fortschritt im Vergleich zum Zustand vorher.

Donnerstag, 7. Januar 2021

... und sie schrien nach Klopapier

FS
Bild: Pixabay / Jasmin Sessler - CC0 1.0
Klopapier ist ein ganz besonderer Stoff. Während Pandemien und anderen Katastrophen gehört es zu den ersten ausverkauften Produkten, und auch in normalen Zeiten kann es als die symbolhafte Verkörperung der sprichwörtlichen dünnen Schicht zwischen der Sauberkeit moderner Zivilisationen und dem Schmutz des Mittelalters gelten. Ganz nebenbei ist es aber auch das Hauptthema einer Anekdote die ich gerne erzähle, einer in der es um die Risiken lokaler Optimierung geht und die auch ein schönes Beispiel für die etwas abwegigen Impediments liefert, mit denen ein Scrum Master mitunter konfrontiert sein kann.

Die Geschichte ereignete sich vor einigen Jahren in einem grossen IT-Projekt eines internationalen Konzerns, einem jener Projekte die so gross sind, dass dafür ein eigenes Gebäude angemietet wurde und das soviel Büro-, Küchen- und Hygiene-Artikel verbrauchte, dass diese regelmässig mit Lastwagen und Gabelstaplern angeliefert wurden. Im Gesamtbudget waren die dafür nötigen Ausgaben kaum sichtbar, für sich genommen ergaben sie aber einen erstaunlichen Betrag.

Nachdem das einmal aufgefallen war wurde hier direkt ein Sparpotential erkannt und das Project Management Office wurde angewiesen die Einkaufspreise zu drücken. Das geschah zum Teil durch die Auswahl billigerer Anbieter, zum Teil aber auch dadurch, dass auf Sonderangebote gewartet wurde. Sobald die irgendwo auftauchten wurden die Bestände aufgefüllt, wenn nicht wurde mit dem Einkauf weitergewartet bis das wieder der Fall war. Sogar definierte Grenzbeträge wurden festgelegt die die Preise nicht überschreiten durften.

Was dann irgendwann passierte dürfte nach dieser Vorrede wohl keinen mehr wundern - die Klopapier-Vorräte waren einmal mehr aufgebraucht, aber gerade zu diesem Zeitpunkt lag kein Anbieter und kein Geschäft mit seinem Preis unterhalb des Grenzbetrages. Das Project Management Office wusste das, ihm waren durch die internen Vorgaben aber die Hände gebunden - es wurde also kein Nachschub gekauft, womit das Drama seinen tragischen Verlauf nahm.

Zuerst verschwanden auch die Vorräte an Küchentüchern und Papier-Wischtüchern, als nächstes begannen die Projekt-Mitarbeiter die Toiletten der umliegenden Lokale zu benutzen, was diese schnell unterbanden. Schliesslich setzten extreme Massnahmen ein: einige Kollegen assen nur noch kleinste Mengen zum Frühstück und Mittagessen (und waren ständig hungrig und schlecht gelaunt), andere fuhren täglich quer durch die Stadt zu anderen Standorten um sich dort zu erleichtern, wieder andere erschienen einfach nicht mehr und arbeiteten nur noch von zu Hause.1

"Wenn das kein Impediment ist, was dann?" fragten die Teams, und da ich zu der Zeit dort Scrum Master war durfte ich nach einer Lösung suchen. Um die unmittelbare Not zu lindern überredete ich das PMO zu einem Akt brauchbarer Illegalität. Das Hygieneartikel-Beschaffungsbudget war zwar nicht erreichbar, wir beschlossen aber ein anderes zweckzuentfremden. Es war das Briefmarkenbudget, das irgendwie den Umstieg auf Email überstanden hatte, nicht mehr genutzt wurde und daher prall gefüllt war. Mit ihm in der Tasche und allen Praktikanten im Schlepptau kaufte ich die Regale des nächsten Drogeriemarktes leer.

Das kurzfristige Problem war damit gelöst, das langwierige war etwas hartnäckiger. Letzten Endes bedurfte es einer konzertierten Anstrengung von verschiedenen Seiten: der Projektleitung wurde aufgezeigt woher der Produktivitätsrückgang kam, mehrere festangestellte Kollegen aktivierten den Betriebsrat, andere drohten ihren Vorgesetzten mit Kündigung, mehrere Teams korrigierten ihre Aufwandsschätzungen deutlich nach oben. Was genau den letzten Anstoss gab liess sich nicht mehr feststellen, aber irgendwann wurden die Einkaufs-Beschränkungen aufgehoben.


Wie oben gesagt, die Anekdote kann zur Illustrierung einiger entgleister Mechanismen grosser Organisationen benutzt werden. Dazu gehören der Drang zur Optimierung jedes noch so unbedeutenden Betrages, das parallele Existieren von sinnlos-Budgets (Briefmarken) und die scheuklappenhafte Ignorierung der Bedürfnisse anderer Organisations-Silos, aber auch das Vermeiden ernsthafter Aufarbeitung von Problem durch das "rückwirkende Verschwindenlassen" der Ursachen (noch gar nicht erwähnt: per Dekret wurde erklärt, den Grenzbetrag habe es nie gegeben, es wäre alles nur ein Missverständnis gewesen).

Vor allem ist es aber eine schöne Geschichte die immer dann erzählt werden kann wenn ein Beispiel für das gebraucht wird was ein Scrum Master den ganzen Tag macht.


1Die Geschichte spielt vor Corona, sowohl die Prozesse als auch die Technik waren dafür nicht geeignet, die Produktivität sank

Montag, 4. Januar 2021

Dystopische Software-Entwicklung

FS
Bild: Pixabay / Crow Imagenes - CC0 1.0

Wer in Familie oder Bekanntenkreis passionierte Computerspieler hat wird in der Weihnachtspause um ein Thema nicht herumgekommen sein: die verheerend verlaufene Markteinführung des dystopischen Rollenspiels Cyberpunk 2077. Angekündigt als Meilenstein seines Genres und mit hohen Erwartungen begrüsst erwies es sich als so unausgereift und fehleranfällig, dass es auf vielen Endgeräten praktisch nicht spielbar war. Die damit für den Hersteller verbundenen Geld- und Reputationsverluste dürften kaum abzuschätzen sein.


Zahlreiche Medien haben über die Geschichte hinter diesem Fehlschlag geschrieben, unter anderem die New York Times, die Washington Post, Slate, der Guardian, die Zeit und Heise. Der Tenor dieser Berichterstattung ist, dass er durch lang bekannte systemische Ursachen herbeigeführt wurde, die typisch für die Computerspiel-Branche sind. Ich würde sogar noch weitergehen und sagen, dass diese Ursachen (mehr oder weniger stark ausgeprägt) in den meisten grossen Software-Projekten vorkommen. Sie alle sind mir schon mehrfach begegnet. Hier sind sie:


Unrealistische Zeitplanung

Nicht nur einer der frühesten Fehler sondern auch einer der schwerwiegendsten. In sehr vielen Firmen werden grosse IT-Projekte zu optimistisch geplant, sei es aus Selbstüberschätzung, aus Wunschdenken, wegen fehlendem Sachverstand oder um sie überhaupt genehmigt zu bekommen. Schlimmstenfalls werden diese Planungen noch mit weiteren verknüpft, von den Karriereplänen des Managements bis zur Ressourcenplanung des nachfolgenden Projekts.


Keine Anpassung der Zeitpläne während des Projekts

Aus den gerade genannten Gründen, aber auch weil Neuplanungsprozesse in der Regel sehr aufwändig gestaltet sind, versuchen viele Organisationen eine Anpassung der Zeitpläne so lange wie möglich zu vermeiden - selbst dann wenn allen Beteiligten klar ist, dass sie unrealistisch sind. Gerade bei langlaufenden Projekten kommt noch ein weiterer Faktor dazu: gelingt es die Anpassungen weit genug in die Zukunft zu schieben ist man selbst nicht mehr betroffen.


Frühes Aufbrauchen des Zeitpuffers

Eine Auswirkung des letzten Punkts. In praktisch jedem grossen Vorhaben wird ein Zeitpuffer eingeplant, mit dem es möglich ist Verspätungen zu kompensieren. Wenn aber selbst in frühen Projektphasen erkannte Planabweichungen nicht zu Neuplanungen führen sondern nur zum Aufbrauchen des Puffers, dann ist die Flexibilität die er liefert zum Projektende hin nicht mehr gegeben - gerade dann wenn sie am dringendsten gebraucht würde.


Aufwändige Vermarktung des unrealistischen Zieldatums

Egal ob es Werbekampagnen für B2C-Produkte sind, Messeauftritte für B2B-Produkte oder sonstige Marketing-Massnahmen - man kann hier erstaunliche Summen investieren. Eine Markteinführung für die die Vermarktung bereits begonnen hat lässt sich daher meistens nur gegen massive Widerstände verschieben, da dieses Geld dann abgeschrieben werden müsste. Dabei ist es dann auch egal ob der Marketing-Verantwortliche wusste wie realistisch das Zieldatum ist oder nicht.


Qualitätssicherung erst kurz vor der Veröffentlichung

Eine weitere Folge unrealistischer Zeitplanung. Um länger an der Fertigstellung von Features arbeiten zu können wird versucht die nachfolgenden Schritte zu komprimieren. Im Fall von Software-Test eine folgenschwere Entscheidung - entweder müssen sie unter hohem Zeitdruck stattfinden und sind dann unvollständig und schlampig oder es werden zeitgleich zu ihnen noch Features gebaut, worurch vor allem frühe Integrations- und Regressionstests wertlos werden.


Massive Überstunden in der Schlussphase

Im Grunde schon das erste Anzeichen dafür, dass die Planungen fehlgeschlagen sind. Das was in der normalen Arbeitszeit nicht zu schaffen ist soll jetzt nachts und am Wochenende stattfinden, was zu Überarbeitung, Fehlern und weiterer Mehrarbeit führt. Eine in diesem Zusammenhang häufige Dysfunktion: sobald Überstunden in Projekt-Schlussphasen normal werden, werden sie oft von Anfang an schon verplant, wodurch es nicht mehr möglich ist sie am Ende zum Aufholen von Rückständen einzusetzen.


Kurzfristiges Ausbauen von Features

Irgendwann kommt der Moment in dem auch der letzte sich die Situation nicht mehr schönreden kann und allen klar ist, dass zum Lieferzeitpunkt nicht alles fertig wird. Auch hier gibt es einen häufigen Reflex: alles was nicht Kernfunktion ist wird auf den letzten Metern wieder ausgebaut, selbst wenn das auf Kosten von Usability, Lastfähigkeit, einheitlicher Benutzererfahrung oder Systemstabilität geschieht und für gründliches Testen keine Zeit mehr da ist. Hauptsache irgendetwas wird fertig.


Ausliefern unvollständiger und fehlerhafter Ergebnisse

Man mag es nicht glauben, aber auch das geschieht immer wieder - Produkte die zum Teil noch unfertig sind gehen raus an den Benutzer. Der stellt dann die inzwischen sprichwörtlichen "Kinderkrankheiten" fest, die durch Hotfixes, Patches und Updates nach und nach behoben werden. Das bedeutet aber auch, dass die Überstunden und die halbgare Qualitätssicherung hinter den Kulissen weitergehen - mitsamt der damit verbundenen negativen Effekte.


---


Soweit die Problembeschreibung, wie so oft gefolgt von der Frage wie es besser gehen soll. Die wichtigste Antwort darauf: durch die Verabschiedung von der Illusion komplexe und neuartige Grossvorhaben im Voraus genau planen zu können. Jeder Versuch es doch zu tun wird in die hier beschriebene Dystopie führen. Stattdessen ist es nötig in kurzen, regelmässigen Abschnitten den Fortschritt zu überprüfen und alle Strukturen und Prozesse darauf zu optimieren, dass Änderungen schnell, einfach und ohne das Verschieben von Problemen in die Zukunft möglich sind. [Werbeblock für Agilität bitte hier einfügen]

Donnerstag, 31. Dezember 2020

Kommentierte Links (LXX)

FS
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" Texte aus dem letzten Jahr.

  • Mirco Hering: Segregation of Duties in a DevOps world

    Die Segregation of Duties (auch Separation of Duties) kann bei einer agilen Transformation einer der grossen Stolpersteine sein. Wie soll es möglich sein in schneller Taktung benutzbare Ergebnisse zu liefern wenn interne oder externe Vorschriften festlegen, dass bestimmte zusammengehörende Schritte nicht von den selben Personen durchgeführt werden dürfen? Mirco Hering gibt einige Denkanstösse um zu zeigen wie in solchen Situationen vorgegangen werden kann (und noch mehr dazu gibt es von Jez Humble in den kommentierten Links des Oktobers).

  • Elaine Pulakos: Organizational Agility – It’s Not What You Think

    Die "es ist alles anders als Du denkst"-Artikel sollte man immer mit einer gewissen Vorsicht lesen, aber das was Elaine Pulakos hier schreibt scheint Substanz zu haben. Basierend auf 300 untersuchten Unternehmen identifiziert ihr Team drei Voraussetzungen von organisationsweiter Agilität: Stability before Change (stabiler Ausgangszustand vor Beginn der Veränderungsmassnahmen), Rightsized Teamwork (ständige Evaluierung wo funktionsübergreifende Arbeit nötig ist und wo nicht) und Relentless Course Correction (beinhaltet neben schneller Entscheidungsfähigkeit auch Fehlerkultur und Delegation). Schade ist, dass die geplanten Fortsetzungen im Sand verlaufen zu scheinen. Von den drei weiteren angekündigten Artikeln ist in mehreren Monaten nur einer erschienen.

  • Len Lagestee: How Organizational Silos Form

  • Eines der zentralen Ziele einer agilen Organisation ist die Auflösung organisatorischer Silos, bzw. das Verhindern ihrer Entstehung. Vor diesem Hintergrund macht es Sinn sich damit zu beschäftigen was diese Silos sind und wie sie entstehen. Len Lagestee hat sich diesem Thema von verschiedenen Seiten genähert, angefangen mit der Frage was unter diesem Begriff eigentlich zu verstehen ist über die Indikatoren durch die man erkennt, dass sie da sind, bis zu den Faktoren die zu ihrem Entstehen beitragen. Passend zum Namen seines Blogs (Illustrated Agile) enthält sein Beitrag auch eine Visualisierung der zuletzt genannten Faktoren. Gerade für die Vermittlung derartig komplexer Sachverhalte ist so etwas immer gut zu gebrauchen.

  • Jasmine Chia & Samuel Hagen: The Org Chart as Political Map-Making

    Es gibt Management-Werkzeuge die mittlerweile so selbstverständlich geworden sind, dass kam noch jemand darüber nachdenkt wo sie herkommen und in welcher Form sie von ihrer Organisation beeinflusst werden (und sie beeinflussen). Der Organizational Chart, auch Organigramm genannt, ist eines davon. Jasmine Chia und Samuel Hagen haben einen näheren Blick darauf geworfen, und das aus einer ungewöhnlichen Perspektive: analog zur Annahme, dass moderne Staaten erst durch die Entwicklung der Kartografie (der Erstellung von Landkarten) möglich wurden, gehen sie davon aus, dass moderne Organisationen und ihre Organigramme eine ähnlich verbundene Entstehungsgeschichte haben und sich auch in der Gegenwart noch gegenseitig beeinflussen.

  • Akio Toyoda: What is Toyota Production System?

    Dass das Lean Management (und die daraus entstandene agile Produktentwicklung) aus dem Toyota Production System (TPS) entstanden sind dürfte für die agilen Methodiker zum Standardwissen gehören, was sich genau hinter diesem verbirgt ist dann aber für viele schon deutlich unklarer. Dieser Artikel der firmeneigenen Toyota Times hilft hier weiter, da er seine Zusammenfassung direkt von der "höchsten Stelle" erhalten hat: Quelle ist eine Ansprache von Aiko Toyoda, Präsident der Toyota Motor Corporation und Nachfahre des Firmengründers, vor Nachwuchsmanagern. Gut herausgearbeitet wird dabei, dass es im Lean Management/TPS trotz aller Klischees nicht um Effizienzsteigerung um jeden Preis geht, sondern dass der eigene Mitarbeiter im Mittelpunkt steht, dem die eigene Arbeit möglichst leicht gemacht werden soll.

  • Kai-Marian Pukall: OKR: eine kritische Betrachtung

    Ein Artikel der aus mehreren Gründen lesenswert ist. Zum einen liefert Kai-Marian Pukall einen guten Überblick darüber um was es sich bei "Objectives and Key Results" (OKR) und ihrem Vorgänger "Management by Objectives and Self-Control" (MBO) überhaupt handelt, zum anderen zeigt er auf welche Schwachstellen dieser in den letzten Jahren stark gehypete Ansatz hat. Vor allem sind das für ihn die nur scheinbare unternehmensweite Transparenz (niemand wird sich ständig über die OKRs aller Teams informieren), die schlechte Messbarkeit vieler Ziele, das regelmässige obsolet Werden von OKRs durch geänderte Realitäten und das parallele Existieren verschiedener Ziele in jeder grösseren Organisation. Ein guter Kontrapunkt zum in den letzten Jahren etwas überhandnehmenden Hochjubeln .

  • Gary Hamel, Michele Zanini: Harnessing Everyday Genius

    Was Gary Hamel und Michele Zanini hier abliefern ist eine Fallstudie für eine grundlegende Veränderung einer Organisation. Am Beispiel des französischen Reifenherstellers Michelin und seinem "Responsabilisation"-Programm zeigen sie auf wie ein Wechsel weg von traditionellem Command & Control und hin zu Delegation und Subsidiarität ein Unternehmen wirtschaftlich erfolgreicher machen kann. Das Bemerkenswerte dabei - wenn man dem Artikel glauben kann wurde hier keines der üblichen Frameworks eingeführt und nicht einmal die üblichen Schlagworte Lean und Agile wurden benutzt. Wer sie kennt wird trotzdem einiges von ihnen wiederfinden, was ein starkes Zeichen dafür ist, dass es sich um grundlegende Prinzipien handelt.

  • Robert N. Charette: Inside the Hidden World of Legacy IT Systems

    Vor allem in grossen und älteren Firmen (im IT-Kontext alle Firmen die älter als 40 Jahre sind) gehören der Betrieb und die Weiterentwicklung von so genannter Legacy-Software zu den grössten Zeit- und Kostentreibern, aber auch viele jüngere Unternehmen haben bereits in erstaunlich kurzer Zeit erschütternd grosse Probleme mit veralteten Systemen. Robert Charette fasst gut zusammen was Legacy Software ist, welche Auswirkungen es hat sobald sie da ist aber auch wie man damit umgeht. In seinen Worten: "The first step in fixing a massive problem is to admit you have one." und "The best way to deal with legacy IT is to never let IT become legacy." Zuletzt findet sich am Ende des Artikels eine schöne Argumentationshilfe für die nächste Diskussion warum Ablösungsprogramme wichtig sind: eine Liste von Kostenexpolisionen und Systemausfällen die durch veraltete Software entstanden sind.

  • Cal Newport: The Rise and Fall of Getting Things Done

    Der finale Longread. Die Methoden "Getting Things Done" und "Inbox Zero" galten lange als das Nonplusultra der persönlichen Produktivität, sind aber mittlerweile weitgehend in Vergessenheit geraten. Cal Newport erzählt wie es zu Aufstieg und Fall dieser Methoden kam, von den Rahmenbedingungen in denen sie entstanden sind (mit Exkurs zum bereits weiter oben erwähnten Management by Objectives) über den grossen Hype bis hin zu Auswirkungen auf spätere Ansätze wie den in modernen Softwareentwicklungsteams üblichen WIP-Limits.

Montag, 28. Dezember 2020

Kommentierte Links (LXIX)

FS
Leicht verfrüht: die Kommentierten Links des Dezembers. Am letzten Tag dieses Monats folgt eine weitere Ausgabe, dann mit den Artikeln die es zu Unrecht nicht in die Kommentierten Links der vergangenen Monate geschafft haben.
  • Barry O'Reilly: The Obstacles to Unlearning

    Eine oft unterschätzte Herausforderungen beim Navigieren in einer sich ständig verändernden Welt besteht darin, erlernte Glaubenssätze und Verhaltensmuster regelmässig darauf zu überprüfen ob sie noch immer genau so sinnvoll sind wie zum Zeitpunkt zu dem man sie sich angeeignet hat. Ist das nicht mehr der Fall muss das eigene Verhalten geändert werden, was schwerer ist als man denken möchte - Vieles von dem was wir regelmässig tun wird alleine aufgrund der Routine (und natürlich auch aufgrund der vergangenen Erfolge) als so intuitiv richtig wahrgenommen, dass jede Abweichung davon sich wie ein Fehler anfühlt. Die Trennung von diesen scheinbaren Gewissheiten hat Barry O'Reilly unter dem Label "Unlearning" zu seinem Thema gemacht. In diesem Artikel gibt er eine gute Übersicht, es geht also nicht nur um die im Titel genannten Hindernisse sondern auch darum was er überhaupt unter Unlearning versteht und was gute Beispiele für seine Umsetzung sind.

  • Jens Bergmann / Siegbert Warwitz: "Wenn ein Mensch von einem Bären angefallen wird, dann hat er etwas falsch gemacht"

    In diesem Interview geht es um Wagnisse und Risiken, beziehungsweise um den Umgang damit. Siegbert Warwitz ist Psychologe mit dem Schwerpunkt der Wagnisforschung, die er vor allem an Sportlern und Kindern betreibt, deren Erkenntnisse sich aber auch auf das Berufsleben übertragen lassen. Eine seiner zentralen Erkenntnisse ist dabei, dass das regelmässige Umgehen mit Wagnissen und Risiken zur Sicherheit im Umgang mit ihnen führt, wärend der Versuch sie zu vermeiden Ängste und Unsicherheiten verursacht, welche die Wahrscheinlichkeit von Unfällen sogar erhöhen. Interessant ist dabei auch die Abgrenzungen zwischen den ähnlichen Persönlichkeitstypen des "Wagenden", des (unverantwortlich handelnden) Hasardeurs und des das Wagnis nur simulierenden Teilnehmers an Pseudo-Risiko-Events (wie Bungee Jumping).

  • Stefan Kühl: Agilität – Und täglich grüßt das Murmeltier

    Stefan Kühl hat sich einen Namen gemacht als Kritiker des Hypes der mittlerweile um das Konzept der Agilität gemacht wird, und auch dieser Beitrag von ihm geht in diese Richtung. Im Gegensatz zu vielen anderen die sich an diesem Thema abarbeiten verfällt er allerdings nicht in undifferenziertes Bashing sondern arbeitet reale Probleme heraus, etwa die den Kontext ignorierende Übertragung aus der IT auf alle anderen Bereiche. Seine eigentlich bemerkenswerte These ist aber die, dass es seit den 60ern bereits eine Reihe von Management-Moden gegeben hat die er für weitgehend deckungsgleich mit der Agilität hält. An dieser Stelle hat er vermutlich Recht im Unrecht: ohne den IT-Bezug ist das Ganze tatsächlich nur noch einer von vielen Entbürokratisierungs- und Dezentralisierungs-Ansätzen - aber der IT-Bezug ist für die Agilität zentral und unterscheidet sie von ihren Vorläufern. Und in einer Zeit in der Prozesse und Systeme immer mehr verschmelzen ergibt sich daraus auch wieder eine übergreifende Bedeutung.

  • Jason Yip: Worse is better, also for organisational design

    Das hier passt irgendwie zu den weiter oben verlinkten Überlegungen zu Unlearning und Wagnis: Jason Yip geht davon aus, dass es gerade die Unvollständigkeit und Unausgereiftheit eines Ansatzes ist die zu einem Erfolgsfaktor werden kann. Die scheinbare Einfachheit sorgt dafür, dass zu Beginn wenig Ablehnungen und Widerstände auftreten und es schnell zu einer grossen Verbreitung kommt, gleichzeitig führt die eingeschränkte Praxistauglichkeit dazu, dass ein ständiger Verbesserungsprozess in Gang kommt der nicht nur das Vorgehen kontinuierlich optimiert sondern auch dafür sorgt, dass die Beteiligten Zeit und Energie investieren müssen, weshalb sie sich dem Ergebnis stärker verbunden fühlen. Mit einer gewissen Ironie verbunden ist seine Ansicht, dass ausgerechnet SAFe ein Paradebeispiel für Unvollständigkeit und Unausgereiftheit ist - die Wahrnehmung durch seine Beführworter ist schliesslich die genau umgekehrte.

  • Rob Lambert: How to find levers of change in your company

    Die zentrale These dieses Artikels von Rob Lambert ist, dass es in den meisten Organisationen nur wenige zentrale Hebel gibt die man bedienen muss um zu mehr Agilität zu kommen. Bewusst und richtigerweise behauptet er nicht im Besitz absoluter Wahrheiten zu sein, als Ausgangspunkt für eine Entwicklung einer Transitionsstrategie sind seine Überlegungen aber gut zu verwenden. Und obwohl es am Ende wieder auf sehr globale Phänomene wie Arbeitsfluss, Transparenz, Zielklarheit und Empowerment zurückkommt gibt er auch einige konkrete Hilfestellungen mit indem er erwähnt wo man nach ihnen suchen kann und wie man sie erkennt.
Powered by Blogger.