On Lean and Agility

Auf den ersten Blick ist das hier einer dieser Holy Shit-Momente. In gerade einmal fünf Minuten erstellt Henrik Kniberg hier mit Hilfe eines KI-Chatbots einen funktionsfähigen Prototypen einer mobile App in mehreren Versionen, samt Dokumentation und einem initialen Backlog mit den nötigen Anforderungen um daraus eine voll funktionsfähige erste Version zu erstellen. Früher wäre damit ein ganzes Team einen ganzen (Design-)Sprint lang beschäftigt gewesen, jetzt geht es in wenigen Momenten.

Wenn man weiss wie derartige Chatbots funktionieren relativiert sich die Leistung ein bisschen. Das Demonstrationsobjekt ist eine To Do-Listen-App, von denen es bereits unzählige gibt, deren Code hier Teil des Traningsmaterials der KI gewesen ist. Würde man sie dort einsetzen wo Prototypen normalerweise gebraucht werden, in der innovativen Neuentwicklung nämlich, wäre kaum Trainingsmaterial vorhanden und das Resultat wäre entsprechend wenig beeindruckend.

Trotzdem bleibt das Ergebnis dieser Vorführung natürlich beachtlich. Um das Potential dieser Technologie voll nutzen zu können, wird es darauf ankommen, zu wissen, wo sie einsetzbar ist und wo nicht. So werden sich beispielsweise die wenig innovativen Teile einer neuen Anwendung (Login, Profilseite, etc.) schnell generieren lassen, so dass mehr Zeit für die wirklich innovationsbringenden Tätigkeiten bleibt. Alleine das kann schon sehr viel bewirken.

Am Ende sollte trotzdem in jedem Fall klar sein, dass der auf diese Art entstandene Code mindestens durch ein gründliches Refactoring gehen, wenn nicht sogar neugeschrieben werden sollte, bevor er veröffentlicht wird. Wenn nicht, dürften einige unschöne Überraschungen bevorstehen. Selbst das kann im Vergleich zu einer vollständigen Selbstentwicklung aber immer noch deutlich effektiver und effizienter sein. Die Zukunft hat bereits begonnen.

Bild: Wikimedia Commons / Looniverse - CC BY-SA 4.0

Ein Massenphänomen sind sie noch immer nicht, aber die Anwendung agiler Arbeitsweisen in Bauprojekten ist mittlerweise nichts mehr was sich als unmöglich bezeichnen lässt, von Teslas MVP-Fabrikgebäuden bis hin zu "konfigurierbaren" und in Tagen errichtbaren Modulbau-Häusern gibt es zahlreiche funktionierende Beispiele. Zur Zeit wird agiles Bauen aber noch einmal einfacher, billiger und flexibler, denn eine weitere Technik ist im Bau angekommen: 3D-Druck.

Diese ursprünglich nur für Kunststoffe verwendete Technik ist mittlerweile durch technische Neuerungen auch für Baustoffe nutzbar, und ermöglicht so nicht nur die schnelle und ggf. individuelle Anfertigung von Bauelementen oder den erwähnten Modulen, sondern sogar von ganzen Gebäuden (davon ausgenommen bleiben weiterhin die Tiefbauarbeiten, und bei denen vor allem der Aushub und die Sicherung der Baugruben, die noch immer klassisch geplant und durchgeführt werden müssen).

Ein bekanntes Beispiel kann man seit 2021 in Amsterdam nicht nur betrachten sondern sogar betreten: eine ganze Brücke ist dort mit einem 3D-Drucker erstellt worden - aus Stahl. Dafür wurde schichtweise Metallpulver aufgetragen und so festgeschmolzen, dass dadurch nach und nach die Brückenform entstand. Darüber hinaus ist das ganze Bauwerk mit Sensoren versehen, die Belastungen messen und inspect & adapt ermöglichen - die nächste so gebaute Brücke wird stabiler und braucht weniger Material.

Auch Betonwände lassen sich mittlerweile schichtweise mit einem 3D-Druck-Roboter hochziehen, und auch hier können Ergebnisse in der Nähe betrachtet werden: in Heidelberg wurde 2023 das Gebäude eines Rechenzentrums mit einem Beton-3D-Drucker in nur sieben Tagen erstellt und seit 2024 steht in Beckum bei Münster das erste so entstandene Wohnhaus, dessen Bau nur zwei Wochen gedauert hat - beides ist also in einem Zeitraum fertig geworden, der einem Sprint entspricht.

Die beste Kombination aus Geschwindigkeit und Flexibilität bietet schliesslich die Kombination aus 3D-Druck und Modulbauweise. In Japan und den USA gibt es jetzt schon Baufirmen, die naben der Baustelle temporäre Fabriken errichten und in ihnen Baumodule erstellen, die dann gleich zusammengesetzt werden können. In diesem Rahmen können auch Schäden am Gebäude schnell behoben und etwahige Fehler der Planung schnell korrigiert werden. Auch hier also - inspect & adapt.

Bild: Wikimedia Commons / Matthias Klein - CC BY-SA 3.0

Eine Besonderheit der Rollen in agilen Frameworks ist, dass fast immer mehrere von ihnen auf der gleichen Hierarchieebene einer gemeinsamen Organisationseinheit vorkommen, wo die Aufgabengebiete unter ihnen aufgeteilt sind. Die häufigste derartige Aufteilung ist die in Paare, v.a. mit Scrum Master und Product Owner, es gibt aber auch verbreitet so genannte Trios, also Dreiergruppen. Welche drei Rollen das sind ist aber nicht einheitlich, es haben sich über die Zeit verschiedene Varianten entwickelt.

Die drei Amigos

Die vermutlich älteste Variante eines Trios wird auch die drei Amigos genannt. Es handelt sich um eine in der Frühzeit der agilen Softwareentwicklung (vor 2010) verbreitete kleinstmögliche Form eines crossfunktionalen agilen Entwicklungsteams, bestehend aus jeweils einem Vertreter von Business, Softwareentwicklung und Qualitätssicherung. Als Vorgänger der Scrum Teams arbeiteten diese Trios vor allem an der Product Delivery also dem (agilen) Abarbeiten eines Lieferplans von Features.

Das Product Trio

Eine ähnliche, aber deutlich später (ca. 2020) entstandene Form eines kleinen, crossfunktionalen agilen Teams ist das durch Thereresa Torres popularisierte Product Trio, bestehend aus einem Product Manager, einem Designer und einem Software Engineer. Der Unterschied zu den drei Amigos ist vor allem das Tätigkeitsfeld - statt in der Product Delivery arbeiten Product Trios vor allem in der Product Discovery, also der ergebnisoffenen Neuentwicklung von Produkten.

Das TPD Trio

In gewisser Weise die skalierte Version eines Product Trio, wenn auch ca. 10 Jahre früher entstanden. Entwickelt als Teil des Spotify Models besteht ein TPD Trio aus einem Tribe Lead (Eingineering Manager), einem Product Lead und einem Design Lead, die zu dritt einen Tribe, also eine Einheit aus mehreren Squads (Entwicklungsteams) leiten. Statt selbst an der Umsetzung mitzuarbeiten erstellen sie dabei in ihrem jeweiligen Themengebiet Anforderungen und Vorgaben für die Teams.

Das ART Trio

Zu einer ähnlichen Zeit wie das TPD Trio entstanden, erfüllt das Führungs-Trio eines Agilen Release Train (ART) in SAFe zwar einen ähnlichen Zweck, ist aber anders zusammengesetzt. Neben dem Product Manager sind hier ein für die Prozesse verantwortlicher Release Train Engineer (RTE) und ein System Architect Mitglied. Im "Full SAFe" gibt es noch eine Entsprechung auf der nächsthöheren Ebene, bestehend aus Solution Manager, Solution Train Engineer (STE) und Solution Architect.

Andere Trios

Je nach Kontext können noch zahhlreiche weitere Formen von Trios bestehen, gesehen habe ich z.B. schon UX, Entwicklung und QA oder Entwicklung, Operations und Security. Wichtig ist aber in allen Varianten, dass es sich um gleichberechtigte Teile eines kleinen, crossfunktionalen Entwicklungs- oder Führungsteams handelt, die in Summe alle Aufgaben abdecken können, die zur Erledigung ihres jeweiligen Auftrages notwendig sind.

Grafik: Pixabay / Geralt - Lizenz

Pim de Morree: The Anatomy of a Self-Managing Organization - Why Networks Trump Hierarchies

Erik de Bos: The Puzzle of Self-Organisation

Bob Galen: Shatters Anonymous

Prateek Singh: On Deterministic Fixed-Length Timeboxes

Charles Lambdin: What Is Cost of Delay?

Bild: Pexels / Ivan Samkov - Lizenz

Dass "agile Methodiker" (Agile Coaches, Scrum Master, etc.) mit der Zeit eine eher negative Weltsicht entwickeln, ist leider ein verbreitetes Phänomen. Das ist auch irgendwie verständlich, wer sich ständig mit dem Beseitigen von Impediments und dem Kampf gegen Change Fatigue und Konzern-Trolle beschäftigen muss, kann schnell in Frustration abrutschen. Um nicht selbst in dieses Muster verfallen, möchte ich dagegenhalten, indem ich ab und zu selbst erlebte "agile Erfolgsgeschichten" veröffentliche.

Diese hier beginnt mit einem Problem. In einem Konzern, dessen agile Transformation ich begleiten durfte, galt das Verhältnis zwischen der internen Softwareentwicklung und den Anwendern in den Filialen als zerrüttet. Die Software würde schwer zu verstehen und zu bedienen sein, hiess es von den Filialkräften, umgekehrt beschwerten sich die Entwickler über unvollständige und erratische Anforderungen und Fehlermeldungen. Jede Seite sah das Problem bei der anderen.

Nach kurzem Nachforschen liess sich ein Grund für diese Missstände identifizieren: der Anforderungsmanagement-Prozess war (freundlich gesagt) suboptimal. Neue Anforderungen wurden (wenn sie überhaupt aus den Filialen kamen) von deren Leitern gestellt, die gar nicht mit den jeweiligen Systemen arbeiteten. Auf dieser Basis erstellte die IT-Konzeptionsabteilung eine Detailspezifikation und gab diese ohne Rücksprache mit dem Anforderer an die Entwicklung weiter, die nur noch umsetzte.

Natürlich kam es entlang dieser Strecke fast schon zwangsläufig zu Missverständnissen und Stille Post-Effekten, die dann in den oben genannten Problemen resultierten. Um das zukünftig zu verhindern, sah der neue Prozess etwas für diese Firma geradezu Revolutionäres vor: Anwender und Entwickler sollten diekt miteinander sprechen, und das nicht nur ab und zu sondern regelmässig. Und mit regelmässig war gemeint mindestens einmal pro Monat.

Umgesetzt wurde das, indem der gewählte Arbeitsmodus Scrum etwas angepasst wurde. Nach jedem zweiten Sprint fanden die Sprint Reviews in einer der Filialen statt. Im Mittelpunkt standen dabei nicht die Ergebnisse des letzten Sprints (die wurden in den dazwischenliegenden "normalen" Reviews besprochen) sondern das Feedback der Filialkräfte, und zwar sowohl zu Verständlichkeit und Bedienbarkeit der Anwendungen als auch zur Sinnhaftigkeit der als nächtes geplanten Funktionen.

Diese Filialbesuche brachten regelmässig erhellende Erkenntnisse. Immer wieder kam es vor, dass Funktionen, die Management und IT-Konzeption für zentral gehalten hatten, sich in der Realität als unbenötigt herausstellten, umgekehrt wurden von den Anwendern wiederholt Features gewünscht, die an die niemand gedacht hatte. Und nachdem dieser Arbeitsmodus eine Zeit lang gelaufen war, wurden die Reviewss immer positiver, da mehr und mehr der Wunsch-Features tatsächlich gebaut wurden.

Zur ganzen Wahrheit gehört, dass die Veränderungen nicht für alle Beteiligten positiv waren. Besonders die IT-Konzeptionsabteilung musste damit leben, in der Entwicklung der Filial-Software praktisch nicht mehr benötigt zu werden - und dass dann noch betont wurde, dass erst durch die direkte Kommunikation zwischen Entwicklern und Anwendern die Zufriedenheit mit der Software besser geworden war, dürfte für die bisher zwischen ihnen vermittelnden IT-Konzepter deprimierend gewesen sein.

Bild: Pixabay / The Digital Artist - Lizenz

Eine der grossen Gemeinheiten beim Thema Firmenkultur ist es, dass man sie nur sehr schwer und langsam zum Besseren verändern kann, aber erstaunlich schnell zum Schlechteren. Und während eine Verbesserung immer nur durch eine Gemeinschaftsleistung erreichbar ist, kann eine Verschlechterung sogar von nur einem einzigen Manager herbeigeführt werden, wenn er denn nur weit genug oben in der Hierarchie seine Position hat. Das klingt unglaublich, ist aber immer wieder zu beobachten.

Nehmen wir den Fall von Peter, den ich selbst miterleben durfte (und der in Wirklichkeit natürlich anders heisst). Peter war relativ neu in einer Führungsposition in einem Konzern, der bis dahin eine vergleichsweise gute Unternehmenskultur gehabt hatte. Auf die traf jetzt Peter, der zuvor in einer anderen Landesgesellschaft gearbeitet hatte, und sich dort einen besonderen Glaubenssatz angeeignet hatte: der Chef muss möglichst allen wichtigen Entscheidungen selber treffen, sonst sind sie nicht gut.

Am Anfang hatten alle gedacht, dass das alleine daran scheitern würde, dass Peter gar nicht die Zeit finden würde, um sich um alle Themen zu kümmern. Aber er war anderer Meinung und glaubte, mit einem strikten Zeitmanagement wäre das kein Problem. Er teilte seinen Tag in eine ununterbrochene Reihe von dreissig- oder sechzigminütigen Calls und Meetings ein, von Acht Uhr morgens bis Neun Uhr Abends. In denen hörte er sich jeweils die Sachstände an, traf Entscheidungen und setzte Deadlines.¹

Mit diesem strikten Zeitmanagement war allerdings ein Risiko verbunden - wenn es einmal nicht zu einer Entscheidung kam, wurden Folgetermine nötig, die aber in den vollen Kalender nicht mehr hineinpassten. Um es nicht dazu kommen zu lassen, versuchte Peter in möglichst jedem Termin eine Entscheidung zu erzwingen. Und sobald die einmal stand, durfte das Thema nicht nochmal aufgebracht werden. "Warum reden wir darüber?" fragte er dann, "Ich habe doch schon entschieden, nächsten Thema."

Für die anderen Angestellten waren diese Verhaltensweisen ein Problem. Nicht nur mussten sie die Erklärung ihrer z.T. hochkomplexen Themen so zusammenkürzen, dass wichtige Aspekte fehlten, die auf dieses Basis getroffenen (und praktisch irreversiblen) Entscheidungen waren dementsprechend auch nicht immer die besten und führten oft zu neuen Problemen, vermeidbarer Mehrarbeit, verärgerten Kunden oder verpassten Geschäftspotentialen.

Schon bald begannen sich daher die in Peters Termine mitgebrachten Unterlagen zu verändern. Um ihn an vorschnellen Entscheidungen zu hindern, wurde prominent auf noch fehlende wichtige Informationen hingewiesen, auf unabsehbare Konsequenzen zu früher Entscheidungen, auf eine unklare Rechtslage oder ähnliche Faktoren. Mit anderen Worten: die ursprünglich sehr lösungsorientierten Menschen in Peters Umfeld entwickelten mehr und mehr eine Problemfixierung und Bedenkenträger-Argumentation.

Bereits das wäre schon problematisch gewesen, es ging aber noch weiter. Immer wieder kam es vor, dass Peter zwar mit Verweisen auf fehlende Informationen oder unabschätzbare Risiken von Schnellschüssen abgehalten werden konnte, er aber in einem anderen Termin von anderen Mitarbeitern versehentlich Informationen bekam, die ihm doch eine Entscheidung ermöglichten. Von der dann nur noch in Kenntnis gesetzt zu werden war eine erstaunlich häufige Frustrations-Erfahrung.

Um dieser Erfahrung nach Möglichkeit nicht ausgesesetzt zu sein, begannen die Mitarbeiter damit, Informationen nicht mehr untereinander zu teilen oder sie möglichst unklar zu formulieren. Da es sich oft im Nachhinein herausstellte, dass einige dieser Informationen auch für andere wichtig gewesen wären, verschlechterte sich die Stimmung in der Belegschaft deutlich. Während vorher ein kollegialer und hilfsbereiter Umgang vorherrschte, entstand jetzt eine Misstrauens- und Blaming-Kultur.

Die Geschichte hatte noch einige weitere unschöne Aspekte, aus den hier beschriebenen lässt es sich aber erkennen, dass tatsächlich ein einziger Manager eine Firmenkultur herunterwirtschaften kann. Und selbst wenn dieser Fall hier ein besonders plakativer ist, es gibt noch viele andere Möglichkeiten, es zu tun, von falsch gesetzen finanziellen Anreizen über bürokratische Prozessvorgaben bis hin zur gezielten Einstellung und Beförderung nicht teamfähiger "Rockstars".

In der Theorie klingt das Arbeiten in Sprints ganz einfach. Zu Beginn wird ein fachliches Ziel mit hohem Business Value ausgewählt und ggf. noch einmal in kleinere (Teil-)Ziele aufgeteilt, die jeweils in einen Sprint passen. Während dieses Zeitraums (meistens zwei oder drei Wochen) wird konzentriert an der Fertigstellung gearbeitet, danach wird das Ergebnis den Stakeholdern vorgestellt und mit ihnen besprochen, im Anschluss daran wird ein neuer Sprint mit einem neuen Ziel geplant.

In der Realität ist es meistens schwieriger. Zum Einen ist es meistens so, dass es auch Aufgaben gibt, die nicht den höchsten Business Value haben, die aber irgendwann erledigt werden müssen (Einspielen von Versionsupgrades, Vereinheitlichung von Farbschemata, etc). Meistens sind die auch nicht gross genug für ein eigenes Sprintziel. Zum anderen füllen Sprintziele einen Sprint fast nie völlig aus, es bleibt immer eine gewisse Restkapazität übrig.

Viele Teams gehen mit dieser Situation um indem sie etwas Naheliegendes machen: sie planen zuerst alles ein, was für die Erreichung des Sprintziels nötig ist und füllen die verbleibende Kapazität auf indem sie in der restlichen Zeit die anderen Aufgaben abarbeiten. Das ist auch grundsätzlich sinnvoll - unter der Voraussetzung, dass diese Arbeiten auch im verbleibenden Sprint abgeschlossen werden können und nicht halbfertig in den nächsten rutschen und dort Kapazität blockieren.

Ein Weg um das sicherzustellen trägt den Namen Rocks, Pebbles, Sand. Angeblich bei PayPal erfunden und durch die PayPal Mafia popularisiert funktioniert er folgendermassen: zu Beginn eines Planungstermins plant man die grossen Arbeitspakete ein, die "Felsbrocken" (Rocks). Als nächstes füllt man die verbleibende Zeit mit mittelgrossen Aufgaben, den "Steinen" (Pebbles). Die zuletzt verbleibende Zeit ist schliesslich für Kleinst-Aufgaben vorgesehen, den "Sand".

Was der Schlüssel für eine erfolgreiche Anwendung dieses Vorgehens ist, ist ein Focus auf dem Erstellen von Aufgaben, die so klein sind, dass sie die eingeplante Zeit möglichst nicht sprengen. Rocks sollten maximal so gross sein wie ein Sprint, Pebbles maximal so gross wie die im Sprint verbleibende Zeit nach dem Abzug des für die Rocks eingeplanten Aufwandes, die "Sandkörner" maximal so gross wie das, was danach noch übrig ist.

Natürlich ist damit das Risiko verbunden, dass eine derartige Kapazitätsplanung zu einer versehentlichen Überlastung führt, oder zu einer Situation in der bereits kleine zusätzliche Aufwände den verfügbaren Zeitrahmen sprengen. Es empfiehlt sich daher, auch in diesem Vorgehen einen gewissen Teil der Zeit unverplant zu lassen. Ebenfalls möglich ist es, die Aufgaben des Sand-Typs nur dann in den Sprint zu ziehen, wenn gerade kurzfristiger Leerlauf besteht.

Heute ein etwas abseitiges Thema: COBOL. Es handelt sich dabei um eine Programmiersprache aus den 50er Jahren (!), auf der bis heute (!!) der Grossteil der Kern-Anwendungen in Banken, Versicherungen, der öffentlichen Verwaltung und vielen anderen grossen Organisationen beruht. In Coding mit Dee gibt es dankenswerterweise einen Überblick darüber was COBOL ist, und was man zu seiner Geschichte und Anwendung wissen muss.

Was mir an Dees Ausführungen besonders gefällt ist die neutrale Einordnung, samt aller Vor- und Nachteile. Sie legt Wert darauf, dass nicht die veraltete Programmiersprache selbst das Problem ist, sondern dass es stattdessen Faktoren wie fehlende Dokumentation, die Verrentung der Wissensträger und die "historisch gewachsenen" Systemstrukturen sind, die zu den Schwierigkeiten führen, über die sich bei COBOL häufig beklagt wird (und wegen denen oft behauptet wird, COBOL-Anwendungen nicht agil weiterentwickeln zu können).