Kommentierte Links (CXXVII)

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

John Cutler: A Love Letter to Physical Boards (and What Comes Next)

Ich gestehe: diesen Liebesbrief von John Cutler an physische Task- und Kanban-Boards würde ich sofort unterschreiben. Tools wie Jira, Trello, Obsidian, Miro & Co haben zwar seit dem Corona-bedingten verstärkten Aufkommen von Remote-Arbeit massiv Funktionen und Nutzer dazugewonnen, sie haben die eigentlich einfache Idee visualisierter Arbeit aber auch massiv mit Regeln, Verlinkungen, Verschachtelungen und Formatierungen überladen. In diesem Fall war es tatsächlich früher besser.

Milan Milanović: How Google Measures and Manages Tech Debt

Die technischen Schulden gehören zu den Begriffen, die zwar weit verbreitet sind, unter denen sich aber auch jeder etwas anderes vorstellt. Milan Milanović teilt hier eine interessante Fallstudie, die der Firma Google die technische Schulden in 10 Kategorien unterteilt: Migration needed or in progress, Poor or missing documentation, Inadequate testing, Bad code quality, Dead code, Code degradation, Knowledge gaps, Problematic dependencies, Failed migrations und Outdated release processes.

Thomas Germain: Still booting after all these years - The people stuck using ancient Windows computers

Dass uralte Windows-Systeme bis heute die Grundlage für viele Geschäftsprozesse und kritische Infrastrukturen bilden ist schon lange ein Thema, so umfassend wie hier bei Thomas Germain habe ich es aber noch nicht aufbereitet gesehen. Was man von ihm mitnehmen kann: es gibt handfeste betriebswirtschaftliche Gründe dafür, dass sie nicht schon längst überall abgelöst wurden. Das macht es zwar verständlicher, im Ergebnis aber nicht besser.

Barry O'Reilly: The Bootstrapped Revolution: How Small Teams Are Redefining Entrepreneurship

Ein bisschen Kontext vorweg: was Barry O'Reilly hier über kleine Business Einheiten schreibt, die mit weniger als 10 Mitgliedern ganze Märkte aufrollen, ist sehr spezifisch für das technische und soziale Ökosystem des Silicon Valley. Selbst wenn es aber nicht zur Gänze auf den stärker regulierten und von Grossunternehmen dominierten europäischen Markt übertragbar sein sollte - es zeigt deutlich, zu was kleine Einheiten in der Lage sein können, wenn man ihnen die passenden Rahmenbedingungen gibt.

Alex Ewerlöf: When a team is too big

Je nach Sichtweise die Ergänzung oder das Gegenstück zum letzten verlinkten Text. Ausgehend von der Frage, ab wann ein Team zu gross wird um unbürokratisch arbeiten zu können, ist Alex Ewerlöf der grosse Rundumschlag gelungen. Synchrone und asynchrone Kommunikation, Silos und Taskforces, Software-Architektur, Generalisten, Spezialisten, Mob Programming, Lean Management, Ownership und künstliche Intelligenz - alles zusammen in einem lesenswerten Text.

Ein Bild sagt mehr als 1000 Worte (XLVIII)

 Ein etwas anrüchiges Meme, aber eines, das seit Jahren immer wieder geteilt wird. Quelle unbekannt.

I Don't Need Another Scrum Master, Get Me a Technical Coach!

Das hier geht ein bisschen in die Richtung der klassischen Diskussion, wieviel technisches Verständnis ein Scrum Master haben sollte. Die These von Emily Bache in diesem Vortrag hier ist, dass Scrum Master ohne technischen Hintergrund zwar einen Mehrwert haben, dass es aber ebenfalls etwas braucht, was sie "technical Leadership" nennt - eine Rolle die dafür sorgt, dass die technischen Praktiken und Prinzipien genutzt werden, die agile Softwareentwicklung im eigentlichen Sinn überhaupt erst möglich machen.

Insgesamt schlägt sie einen grossen Bogen von Pull Requests über Testability, Code Reviews, Test Driven Development und Pair Programming bis hin zu vielen weiteren Themen. Insgesamt sehr sehenswert, selbst wenn zeitweise die Bewerbung ihrer eigenen Dienstleistungen als externer technical Coach doch sehr stark in den Mittelpunkt rückt.

Construct to deconstruct

Bild: Javier Alvarez / Picryl - Public Domain

In der agilen Softwareentwicklung sollte man sich stets eines Grundsatzes bewusst sein: alle Methoden, Frameworks, Meetings, Rollen, Werte und Prinzipien sind schön und gut, wenn die entstehende Software aber nicht schnell und mit vertretbarem Aufwand anpassbar ist, ist all das nur von bescchränktem Wert. Auch Entwicklungs-Praktiken und Architektur-Muster sind daher von Bedeutung, unter anderem eines, der leider ralativ unbekannt ist: Construct to deconstruct.

Die Grundidee dahinter ist einfach: zum agilen Entwicklen von Software gehört auch, dass vergangene Erweiterungen oder Modifikationen wieder rückgängig gemacht werden, sei es, weil es sich bei ihnen um Übergangslösungen oder MVPs gehandelt hat, oder seit es weil sich herausgestellt hat, dass bei den Anwendern keine Nutzungs- oder Bezahlbereitschaft besteht. In diesen und in anderen Fällen macht ein rückgängig Machen Sinn, um Umfang und Komplexität der Codebase zu reduzieren.

Dort wo das nicht schnell und einfach möglich ist, können verschiedene negative Auswirkungen auftreten - bestenfalls ist die Wiederherstellung eines früheren Zustandes einfach nur aufwändig und beansprucht Zeit und Ressourcen, schlimmstenfalls ist es nicht möglich und eine mit dem früheren Zustand vergleichbare Ersatzlösung muss gebaut werden, was nicht nur aufwändig ist, sondern ggf. auf Kosten von Konsistenz, Updatefähigkeit (bei Standardsoftware) oder Ähnlichem geht.

In der Umsetzung besteht die häufigste und offensichtlichste Form einer Construction for Deconstruction aus einer modularen Architektur der jeweiligen Software. Diese ist gegeben, wenn die Anwendung in selbstständige, voneinander unabhängige Einheiten gegliedert ist, die jeweils eine bestimmte (bestenfalls fachliche) Funktion erfüllen, mit anderen Einheiten nur über fest definierte Schnittstellen verbunden sind und einzeln angepasst werden können, ohne die jeweils anderen auch verändern zu müssen.

Ebenfalls offensichtlich ist, dass der vorherige Zustand bekannt bleiben muss, um wiederhergestellt werden zu können. Das kann ganz banal durch ein Abspeichern eines bestimmten Entwicklungsstandes des Codes stattfinden (und nicht nur der jeweils letzten Versionen), aber auch durch ein Sichern des entsprechenden Standes der dazugehörigen Dokumentation, idealerweise in einer Form, die nicht nur den Zustand beschreibt, sondern auch auch die Entscheidungen die ihm zugrundeliegen.

Etwas weniger offensichtlich aber nicht weniger bedeutsam ist, dass auch der zwischenzeitlich angepasste und jetzt wieder zu entfernende, bzw. auf den früheren Zustand zurückzusetzende Code verständlich und gut dokumentiert ist. Nur wenn sicher ist was er tut und welche Abhängigkeiten von ihm ausgehen kann er entfernt, bzw. zurückgesetzt werden, ohne dass es dabei zu überraschenden Seitenauswirkungen kommt, die wiederum ungeplante Verzögerungen und Aufwände mit sich bringen.

Und natürlich sind auch hier Testabsicherung / Testabdeckung und Monitoring von Bedeutung. Sowohl bei der Validierung ob der "neue alte Zustand" funktionsfähig ist, als auch bei der Sicherstellung, dass die Entfernung des "alten neuen Zustandes" keine unerwarteten Probleme mit sich bringt sind sie für eine schnelle und sichere Umsetzung unverzichtbar (bzw. wenn sie nicht gegeben sind ist mit hohen Aufwänden und verspätet erkannten Überraschungen zu rechnen).

Zuletzt noch eine nicht-technische Anmerkung: dass der Construct to deconstruct-Grundsatz nur verhältnismässig selten befolgt wird hat unter anderem einen sehr menschlichen Grund: es erscheint (bewusst und unterbewusst) naheliegender Veränderungen herbeizuführen, indem man etwas Bestehendem etwas Neues hinzufügt, und weniger naheliegend, dafür etwas Bestehendes zu entfernen. Mehr dazu hier, im Nature-Magazin.

Forward-deployed Engineers

Wer sich inspirieren lassen will, wie ein über Scrum und SAFe hinausgehendes individuelles agiles Framework aussehen könnte, der findet bei erfolgreichen Tech-Unternehmen eine Vielzahl von Beispielen, von Youtube über Amazon und Spotify bis hin zu Netflix und X/Twitter. Ohne nachzudenken kopieren sollte man nichts davon, aber Ideen zum Ausprobieren sind immer wieder dabei. Hier ist eine weitere: die forward-deployed Engineers (FDEs) der Firma Palantir.

Die an verschiedenen Stellen (z.B. hier, hier und hier) erklärte Idee ist einem Gründungsmythos zufolge nach dem Besuch in einem französischen Restaurant entstanden, in dem die Kellner viel Zeit mit den Gästen verbrachten, zusammen mit ihnen von der Karte abweichende Menüs erstellten und diese dann in Teilen selbst mit zubereiteten. In ähnlicher Form sollen zum Kunden entsandte (forward deployed) Teams von Palantir direkt mit den Anwendern Software-Features entwerfen und für sie erstellen.

Bewusst oder unbewusst scheint dieses Vorgehen eine (je nach Sichtweise) Weiterentwicklung oder Umdrehung der Rolle des Onsite Customers aus dem Extreme Programming zu sein. In beiden Fällen ist es das Ziel, Entwickler und Anwender möglichst nah zusammenzubringen. Während das im Extreme Programming aber dadurch stattfand, dass Kundenvertreter in die Entwicklungsteams integriert wurden, ist es bei den forward-deployed Engineers umgekehrt.

Die sich daraus ergebenden Vorteile (enger Zielgruppenkontakt, sofortige Erprobung neuer Ideen, unmittelbares Feedback) sind offensichtlich, allerdings sollte sich jeder bewusst sein, dass diese mit einem Preis kommen, und das ist in diesem Fall wörtlich zu nehmen. Bei Kunden eingesetzte FDEs werden dort lokale Lösungen entwickeln, die ggf. mit anderen lokalen Lösungen redundant oder inkompatibel sind, ihre Integration oder ihr parallel-Betrieb sind aufwändig, die Synergie-Effekte gering.

Dass dieser Weg für Palantir trotzdem der richtige ist, hat mit der Kundenstruktur dieser Firma zu tun. Sie ist im Rüstungssektor tätig und hat darum wenige, dafür aber potentiell riesige Kunden (v.a. die Armeen verschiedener Länder und grosse Rüstungskonzerne, wie z.B. Airbus). Diese Grosskunden sind problemlos in der Lage, die mit diesem Vorgehen verbundenen Kosten zu stemmen, gleichzeitig ist ihre Anzahl so überschaubar, dass die Varianz der entstehenden Lösungen handhabbar bleibt.

Von Bedeutung ist ausserdem, dass es sich bei den in diesem Kundensegment erstellten Palantir-Produkten um Individualsoftware handelt, die zum Grossteil bewusst nicht an andere Kunden verkauft werden soll (und zum Teil aufgrund von Geheimhaltungs- und Exklusivitätsvereinbarungen auch gar nicht verkauft werden darf). Die bei der Erstellung von Standardsoftware normalen und sinnvollen Vereinheitlichungs- und Effizienz-Bestebungen spielen daher hier keine Rolle.

Die forward-deployed Engineers sind daher in gleich doppelter Hinsicht ein interessanter Anschauungsfall. Zum einen weil sie einen Weg zu extrem effektiver und intensiver Kunden- und Nutzer-Interaktion darstellen, zum anderen weil es bei ihnen sehr deutlich erkennbar ist, wie kontextspezifisch ihr Einsatz ist und wie wenig übertragbar er auf die meisten anderen Unternehmen wäre. Daher, wie oben gesagt - eine Inspiration können sie sein, einfach kopieren sollte man sie aber nicht.

120. Scrumtisch Bonn

Jubiläum, Jubiläum! Der bonner Scrumtisch wird 10 Jahre alt, und da er monatlich ausgerichtet wird bedeutet das folgerichtig, dass er heute Abend zum 120sten mal stattfindet. Selbst wenn ich es natürlich nicht jedes mal geschafft habe an ihm teilzunehmen, biin ich von Anfang an dabei gewesen, in den ersten Monaten noch als normaler Teilnehmer, später dann als Teil des Organisationsteams, und das bis heute. Darum an dieser Stelle ein kleiner Blick zurück.

Was den Scrumtisch in Bonn von Anfang an ausgemacht hat, ist zunächst sein Format gewesen. Mit einer einzigen Ausnahme hat er jedes mal als Open Space oder Lean Coffee stattgefunden. Wie genau dieses Format abläuft habe ich hier beschrieben, der zentrale Punkt dabei ist aber, dass es keine vorbereitete Agenda, Themenliste oder Redner-Auswahl gibt. Stattdessen kann jeder das Thema mitbringen, dass ihn gerade bewegt und zusammen mit den anderen diskutieren.

Ein weiterer Punkt der für diese Veranstaltungsreihe prägend gewesen ist, sind seine ständig welchselnden Gastgeber. Anders als es der Name vermuten lässt findet der Scrumtisch nicht in einer Kneipe statt, sondern in Unternehmen die selbst nach Scrum (oder einem anderen agilen Framework) arbeiten. Dadurch kommen immer wieder neue Impulse auf, da die Gastgeber in der Regel bereit sind, Einblicke in die jeweils eigene Art des agilen Arbeitens zu gewähren.

Der mit Sicherheit wichtigste unter den Faktoren, die dafür gesorgt haben, dass es den bonner Scrumtisch nach 10 Jahren noch gibt, ist die lokale Community aus Frenden und Anwendern von Scrum, Kanban, DevOps & Co, die wiederum dadurch bedingt ist, dass es in Bonn eine wesentlich grössere Digital-Wirtschaft gibt als man von Aussen vermuten würde. Von der Regierungs-IT und die Staatsunternehmen über Mittelstand, und Versicherungen bis hin zu Startups ist alles dabei.

Natürlich gäbe es noch viel mehr zu erzählen, von den Anfängen als Spinnoff des Scrumtisch in Köln über das langsame Wächstum der nächsten Jahre und die virtuelle Durchführung während der Corona Lockdowns bis hin zu den negativen und positiven Auswirkungen der aktuellen Wirtschaftskrise. Aber das ist viel besser in Gespräch und Diskussion möglich, weshalb es sich anbietet, das heute Abend auf dem 120. bonner Scrumtisch selbst zu machen. Vielleicht sehen wir uns da?

Deine Muda: Inspect ohne Adapt

Bild: Unsplash / Glenn Carstens-Peters - Lizenz

Elfter 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: Inspect ohne Adapt.

In gewisserweise handelt es sich bei dieser speziellen Ausprägung um eine (wenn nicht sogar die) "agile Muda", da sie vor allem im Umfeld von (schlecht laufender) agiler Produktentwicklung anzutreffen ist. Sie liegt vor, wenn zwar regelmässig nach Verbesserungspotentialen oder Dysfunktionen gesucht wird, ein Auffinden einer solchen aber keine Schritte zur Folge hat, die den Zustand verbessern sollen. Ein klassisches Beispiel dafür wären Retrospektiven ohne Action Items.

Der Verschwendungs-Charakter dieses (Nicht-)Vorgehens ist offensichtlich: für das Suchen, Identifizieren, Beschreiben und Besprechen schlecht laufender Dinge ist Arbeitszeit nötig, und Zeit ist im Unternehmenskontext gleich Geld. Das ist in gewisser Weise gleich doppelt fällig - zum einen für die gerade genannten Tätigkeiten, zum anderen für das Nachholen anderer Aktivitäten, die wegen der so bereits vergebenen Arbeitskapazitäten in die Zukunft verschoben werden mussten.

Ein weniger offensichtlicher aber in seinen Auswirkungen nicht zu unterschätzender Effekt ist der in diesem Rahmen eintretende Motivationsverlust der Mitarbeiter, die erkennen, dass ihnen mit ihren Problemen nicht geholfen wird. Zum einen kann die daraus entstehende Frustration zu nachlassender Arbeitsleistung führen, zum anderen dazu, dass neu auftretende Probleme gar nicht mehr addressiert und bearbeitet werden, da mit ihrer Lösung gar nicht mehr gerechnet wird.

Im schlimmsten Fall entsteht zusätzlich zu diesen Effekten nochmal ein weiterer Verwaltungsaufwand, nämlich dadurch, dass die identifizierten aber nicht gelösten Verbesserungspotentiale und Dysfunktionen ggf. aufbewahrt und aktuell gehalten werden müssen. Die damit verbundenen Untersuchungs-, Informations-, Aktualisierungs- und Repriorisierungs-Aufwände überfrachten das ohnehin schon sinnlose Inspect ohne Adapt nochmal mit einer weiteren Muda, der Lagerhaltung.

Ein derartiges Verhalten abzustellen sollte aus diesen Gründen für jedes agile Team (aber auch für jedes andere Team bei dem es auftritt) eine hohe Priorität haben. Notwendig dafür ist es allerdings, den Teufelskreis einmal initial zu durchbrechen und dem Inspect auch ein tatsächliches Adapt folgen zu lassen, in diesem Fall eine Verhaltensänderung. Ist das aber einmal gelungen, kann in dem so gestarteten Verbesserungszyklus kontinuierlich an Fortschritten gearbeitet werden.

The Future of Agile Isn’t Sh*t

So wie es aussieht, hat Scott Ambler, der Erfinder von Disciplined Agile, seine beiden viralen Linkedin-Posts The Agile Community Shat The Bed und How Agilists Can Move Forward After Shatting the Bed zu einem Vortrag ausgebaut. Die Wortwahl ist noch immer grenzwertig, seine Analyse der Fehlentwicklungen in der agilen Community bleiben aber richtig. Und immerhin gibt er dem Ganzen noch einen positiven Ausblick.

Abseits von der Inhaltlichen Ebene ist die Bildsprache seiner Präsentation noch bemerkenswert. Man muss Memes mögen, um an ihr Gefallen zu finden, dann ist die aber großartig. Daher: ein Vortrag den man auch sehen sollte, nicht nur hören.