On Lean and Agility

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.

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.

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.

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?

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.

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.

Grafik: Pixabay / Brian Penny - Lizenz

John Cutler: The 4 Framework Jobs (And Why It Matters)

Sjoerd Nijland: How to Say “It Depends” with Data

Hunter Schwarz: This 3D-printed train station in Japan took less than 6 hours to build

Maarten Dalmijn: The Explosive Nature of 'Big Bang' Rewrites

Luís Gonçalves: Scaling Startups - The Ultimate Guide For Founders

Für sich genommen klingt die Idee der Objectives and Key Results (OKRs) erstmal einfach. Man setzt ein abstraktes, mittelfristiges Ziel (z.B. Erschliessung eines neuen Kundensegments im nächsten Quartal) und verbindet es mit wenigen konkreten, messbaren Ergebnissen (z.B. X Nutzer nach dem ersten Monat, Y Wachstumsrate im 2. Monat, Z Prozent Verlängerungen nach der Probezeit). Die Herausforderung, die dadurch entsteht ist aber: wie lässt sich das mit dem Alltagsgeschäft verbinden?

Die erste und naheliegende Antwort ist es, in kurzen Abständen (z.B. wöchentlich) zu überprüfen, ob Forschritt in der gewünschten Richtung stattfindet und ggf. Anpassungsmassnahmen zu beschiessen, falls die bisherigen Ergebnisse zu wünschen übriglassen. Auch hier bleibt aber offen, was genau es ist, das da begutachtet wird. Natürlich kann man sich immer wieder die OKRs selbst vorlegen, die Verbindung zum Alltagsgeschäft wäre damit aber noch immer nicht gegeben.

Ein häufig anzutreffender Ansatz zum Schliessen dieser Lücke ist, für die jeweiligen Key Results einen weiteren Work Breakdown durchzuführen und die Umsetzung der sich so ergebenden Arbeitspakete mit Hilfe eines Backlogs oder einer Roadmap zu planen.¹ Damit wird nicht nur die Umsetzungslücke geschlossen, es ist darüber hinaus möglich, die OKR-Aufwände und die sonstigen Tätigkeiten in einer gemeinsamen Planungssicht zusammenzufassen und so Redundanzen und Überplanung zu vermeiden.

Die Art der jeweiligen Arbeitspakete kann schliesslich variieren. Sie können die Bereitstellung der (Infra-)Strukturen zum Gegenstand haben, die für die Erbringung von Leistungen Voraussetzung sind, sie können aus der Fertig- und Bereitstellung von neuen Produkten, Features oder Services bestehen, sie können aber auch die Form von Business-Experimenten haben, durch die erforscht wird, auf welche Art und Weise sich Nutzergewohnheiten ändern oder Kaufanreize setzen lassen.

Wichtig bei der Definition dieses Unterbaus unterhalb der OKRs ist dabei weniger, um was für Arbeitspakete es sich genau handelt, sondern eher ob sie zur Erreichung der übergeordneten messbaren Ergebnisse, der Key Results, beitragen. Stellt sich heraus, dass sie einen Beitrag leisten, sollten sie ggf. wiederholt und intensiviert werden können, leisten sie keinen erkennbaren Beitrag muss es möglich sein, sie unbürokratisch zu variieren oder zu verwerfen. Auf keinen Fall dürfen sie zum Selbstzweck werden.

Der Vollständigkeit halber sei noch erwähnt, dass diese Art mit Objectives and Key Results zu arbeiten weder die einzige ist, noch eine die per Definition besser als andere Vorgehensweisen wäre. Es ist aber eine, mit der sich die Verbindung zwischen OKRs und Alltagsgeschäft gut herstellen lässt. Wer in diesem Bereich Verbesserungspotential sieht, kann daher einen Versuch wagen und überprüfen, wie gut dieser Ansatz für ihn funktioniert - idealerweise anhand von im voraus definierten Erfolgskriterien.