Mittwoch, 30. November 2022

Kommentierte Links (XCIV)

Bild: Pixabay / Buffik - 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.

Kunal Bhalla: Eating Elephants

Mal wieder ein Artikel bei dem bereits der Entstehungsprozess interessant ist - Kunal Bhalla hat ihn nach und nach in einem öffentlich zugänglichen Google Doc verfasst und so bereits zu frühen Versionen Feedback erhalten können. Das seit diesem Monat weitgehend fertige Ergebnis ist ein ausführlicher Überblick über alle Aspekte die beim Starten und Durchführen grosser IT-Projekte zu beachten sind. Das ist z.T. etwas technisch, viele Passagen beschäftigen sich aber auch mit Organisations-, Kommunikations- und Denkmustern. Und obwohl das Wort Agile kein einziges mal vorkommt würde eine Umsetzung aller Empfehlungen definitiv dazu führen, dass das Projekt in dem sie umgesetzt werden weitgehend agil aufgestellt ist.

Liam Kane: Agile Portfolio Management

Ein häufiges Antipattern in agilen Teams und Projekten ist, dass zu wenig über den nächsten Sprint hinaus geplant wird. Die Motive dafür sind zwar grundsätzlich verständlich, schliesslich würde eine zu detaillierte Langfristplanung auf Kosten der Agilität gehen, zu wenig Planung führt aber oft zu "Fahren auf Sicht" und zu unnötig häufigen Kurswechseln. Liam Kane versucht hier aufzuzeigen wie sich Planungsvorlauf und Agilität kombinieren lassen. Dazu kombiniert er das Drei Horizonte-Modell mit Portfolio-Kanban und dem Weighted Shortest Job First-Modell. Wie immer in solchen Fällen ist zwar davon abzuraten seinen Ansatz unreflektiert zu kopieren, einen interessanten Impuls bieten kann er aber auf jeden Fall.

Kent Beck: Cloud Development Environments Tame Complexity By Reducing State

Noch einmal ein etwas technischeres Thema. Kent Beck, der Erfinder des Extreme Programming, teilt in seinem Blog seine Gedanken zu einem Thema, das selbst die meisten Experten vermutlich nicht als entscheidend für mehr oder weniger Agilität sehen würden: sollte sich die Entwicklungsumgebung eines Entwicklers auf seinem lokalen Rechner befinden oder in der Cloud? Basierend auf vier Faktoren die zu Kontrollverlust in Softwareentwicklungs-Vorhaben führen können (Variabilität, Vernetztheit, Status-(Un)eindeutigkeit, Irreversibilität) kommt er zu dem Ergebnis, dass Cloud-Umgebungen wesentlich besser geeignet sind um schnell arbeits-, liefer- und reaktionsfähig zu sein.

Michael Lloyd: Dysfunction Mapping; A tool for effective Agile Coaching

Wie oben bereits gesagt, methodische Ansätze und Werkzeuge sollten nicht unreflektiert kopiert werden, können aber wertvolle Inspirationen sein. Auch auf das Dysfunction Mapping von Michael Lloyd trifft das zu. Mit ihm hat er eine Möglichkeit gefunden mit Hilfe einer grafischen Zuordnung Dysfunktionen und ihre Symptome voneinander zu differenzieren und mit den verschiedenen Organisationsprinzipien zu verbinden, die von ihnen negativ beeinflusst werden. Auch ein Umsetzungsweg gehört dazu, der die Phasen Themensammlung, Verknüpfung, Zweck-Analyse und Lösungs-Hypothese umfasst. Mit ihm kann man das Dysfunction Mapping nach und nach vor sich entstehen lassen.

Jason Yip: “What improves developer productivity?” is the wrong question

Als letztes wieder ein Klassiker. Jason Yip nimmt sich einmal mehr des Themas an, warum es nicht zielführend ist Organisationen auf maximale Entwickler-Produktivität zu optimieren (was aufgrund des missverständlichen Slogans "Doing twice the work in half the time" immer wieder das Ziel agiler Transitionen ist). Mit Hilfe einer einfachen Wertstrom-Visualisierung zeigt er auf, dass die Effekte im Zweifel sogar das Gegenteil von dem sein werden was gewünscht ist. Die altbekannte Erkenntnis am Ende: wer eine bessere Systemleistung will muss auch das Gesamtsystem optimieren, nicht nur seine Einzelteile.

Related Articles