On Lean and Agility

Bild: Unsplash / Olga Guryanova - Lizenz

Mit dem Scrum-Framework haben Jeff Sutherland und Ken Schwaber etwas Bemerkenswertes geleistet: es ist ihnen gelungen, das de facto-Standard-Vorgehen der globalen Software-Industrie zu entwickeln. Der Minimalismus, der die Stärke von Scrum bildet, ist dabei gleichzeitig seine Schwäche - es ist schnell zu verstehen, lässt dabei aber auch einen Freiraum, der mit komplizierten und umfangreichen Regelwerken gefüllt werden kann, von denen SAFe und Disciplined Agile (DA) die bekanntesten sein dürften.

Da ein Grossteil der agilen Community diese beiden Ansätze ablehnt, gibt es bereits seit langem den Wunsch, ihnen eine dem ursprünglichen Geist von Scrum eher entsprechende Erweiterung entgegenzusetzen, idealerweise beruhend auf bereits verbreiteten Praktiken. Large Scale Scrum (LeSS) ist vor diesem Hintergrund entstanden, hat aber nur einen eher inoffiziellen Status. Erst seit Juni 2025 gibt es eine quasi-offizielle Erweiterung, verfasst (u.a.) von Jeff Sutherland: das Scrum Guide Expansion Pack.

Dieses Expansion Pack (mit ca 50 Seiten deutlich umfangreicher als der 13-seitige Scrum Guide, aber auch deutlich schlanker als SAFe und DA) wurde neben Sutherland von John Coleman und Ralph Jocham mitverfasst und besteht aus vier Sektionen: der eigentlichen Erweiterung mit dem Namen Adaptation of: The original Scrum Guide und einem Appendix aus den drei Teilen MORE executive SUCCESS extract, Cynefin Framework Kind of Explanation unofficial & unauthorized und Emergent Strategy.

In die erste Sektion ist auch der eigentliche Scrum Guide eingebettet, um ihn zu ergänzen enthalten alle vier Sektionen weiterführende Erläuterungen, einige der erwähnten verbreiteten Praktiken und historische Hintergründe. Das ist zum Teil banal (etwa wenn erklärt wird, dass "self managing" ein von aussen kommendes Management ausschliesst) zum Teil aber auch durchaus aufschlussreich (z.B. dann wenn erklärt wird, welche Untergruppen die eher diffuse Gesamtgruppe der "Stakeholder" haben kann).

An einigen Stellen finden de facto Erweiterungen des Scrum Guides statt, so gibt es jetzt nicht mehr lediglich drei Artefakte (Product Backlog, Sprint Backlog und Increment) sondern mit dem Product ein viertes; aus der einen Definition of Done sind die Definition of Outcome Done und die Definition of Output Done geworden; zu den drei Rollen, bzw. Accountabilies (Developer, Product Owner, Scrum Master) kommt mit den Stakeholdern eine vierte.

Zu den aufgenommenen Praktiken gehören am prominentesten die Produkt Vision (die das Product Goal nicht ersetzt sondern ergänzt), die Akzeptanzkriterien (die nochmal aufgeteilt werden in die eigentlichen Akzeptanzkriterien und so genannte Outcome-Kriterien) und die häufigsten in Retrospektiven besprochenen Themen (u.a. Professionalität, Effektivität und Teamdynamiken), über den Text verstreut finden sich aber auch weitere, etwa Systems Thinking, (Product) Discovery und Beyond Budgeting.

Eher in den Berech der Nerd-Wissens gehören einige Exkurse zu historischen Begrifflichkeiten und Dokumenten. So werden die Scrum Werte Focus, Openness, Courage, Commitment und Respect aus dem amerikanischen Militär-Begriff OODA (Observe, Orient, Decide, Act) abgeleitet und gleich mehrere Absätze widmen sich dem wissenschaftlichen Paper The New New Product Development Game von 1986, das eine zentrale Inspirationsquelle für Sutherland und Schwaber war.

Im Gegenzug dazu gibt es mit einem eigenen Teil zum Thema der künstlichen Intelligenz (KI) auch etwas, das erkennbar von aktuellen Entwicklungen getrieben ist. Kurioserweise eingeordnet zwischen den Rollen, bzw. Accountabilies werden die damit verbundenen Möglichkeiten und Risiken herausgestrichen (und es wird hervorgehoben, dass der Scrum Master keine KI sein darf). Das ist nicht falsch, aber etwas willkürlich, mit gleicher Berechtigung hätte man z.B. auch Big Data oder Cloud mit aufnehmen können. 

Ob das Scrum Guide Expansion Pack weite Verbreitung finden und noch weiter modifiziert werden wird, wird sich zeigen, wahrscheinlich ist aber in Analogie zum eigentlichen Scrum Guide (den es nur ergänzt, aber nicht ersetzt) beides. Ob es sich als Ersatz oder Gegenmodell zu den kommerziell erfolgreichen und von professionellem Marketing unterstützen Ansätzen SAFe und DA durchsetzen wird ist dagegen weit weniger klar, das in den nächsten Jahren zu beobachten wird sicherlich spannend sein.

Auf jeden Fall wird man es aber gut nutzen können, um zu erkennen, wer sich wirklich für das Thema Scrum interessiert. Denn ganz sicher werden nus solche Personen bereit sein, die gesamten ca 50 Seiten durchzulesen. Alle anderen werden das vermutlich geflissentlich an ihren Scrum Master delegieren.

Bild: Pexels / Ketut Subiyanto - Lizenz

Dass viele "agile Methodiker" (Agile Coaches, Scrum Master, etc.) mit der Zeit eine eher negative Weltsicht entwickeln ist schade, aber erklärbar. Wer sich ständig mit dem Beseitigen von Impediments und dem Kampf gegen Change Fatigue, Overcompliance und Konzern-Trolle beschäftigen muss, kann leicht zynisch und sarkastisch werden. Um nicht selbst irgendwann so zu enden, möchte ich dagegenhalten, indem ich ab und zu selbst erlebte "agile Erfolgsgeschichten" veröffentliche.

Am Anfang von dieser hier stand wie so oft ein Frustrationserlebnis. Eine grosse Firma, bei der ich im Einsatz war, hatte sich in einem Pilotprojekt auf die Idee crossfunktionaler Entwicklungsteams eingelassen, in der Hoffnung, dadurch die alles verzögernden Warte- und Übergabephasen zwischen den bisherigen Spezialistenteams deutlich verkürzen zu können. Bis zu einem gewissen Grad war das auch eingetreten, allerdings bei Weitem nicht in dem von allen erhofften Ausmass.

Eine Untersuchung der betroffenen Einheiten und Prozesse konnte dann klar aufzeigen, woran das lag: das Team war nur crossfunktional innterhalb der Softwareentwicklung (Frontend, Backend, Data Science, UX), was aber bei weitem nicht alle Arbeitsschritte abdeckte. Das Produkt (ein Kundenservice-Chatbot) musste nach der Entwicklung noch zur Fachabteilung, um von der mit Daten versorgt und trainiert zu werden, um dann von der Rechtsabteilung freigegeben zu werden. Hier entstanden weiter Wartezeiten.

Auch Mitglieder dieser beiden Abteilungen in das crossfunktionale Teams aufzunehmen war die offensichtliche Lösung, führte aber zu Beginn zu heftigen Abwehrreaktionen; dafür gäbe doch gar nicht genug Zeit, und es gäbe zu viel Anderes zu tun, das wichtig wäre. Auch hier führte eine Nachforschung schnell zu einer Identifikation des eigentlichen Problems: die betroffenen Kollegen waren stark überplant und hatten nur wenige Stunden pro Woche für das Pilotprojekt zur Verfügung - deutlich zu wenig.

Es brauchte mehrere Wochen und Eskalationen bis ins Top-Management um dieses Problem zu lösen, aber am Ende stand ein deutlich besseres Setup. Aus der Fachabteilung wurden mehrere Mitarbeiter für vier Tage pro Woche exklusiv für das Projekt freigestellt, aus der Rechtsabteilung immerhin ein Kollege für drei halbe Tage pro Woche. Damit konnten sie in das jetzt wirklich crossfunktionale Team eingegliedert werden, an dessen Meetings teilnehmen und eng mit den anderen Teammitgliedern zusammenarbeiten.

Durch diese Neuorganisation trat dann endlich die angestrebte Beschleunigung ein. Durch die täglichen Abstimmungen war jetzt jederzeit klar, wann die Übergaben zwischen den Teilteams stattfinden würden, und durch die realistischere Kapazitätsplanung konnten sie auch fast immer sofort stattfinden. Die Durchschnittlsdauer der Warte- und Übergabephasen sank von Tagen und Wochen auf Stunden (und als Nebeneffekt konnten die Meetings entfallen, in denen die zu übergebende Arbeit verwaltet wurde).

Natürlich gab es noch weitere positive Effekte dieses Vorgehens, z.B. die oben erwähnte Aufdeckung der strukturellen Überplanung vieler Mitarbeiter, da schnellere Durchlaufzeiten durch crossfunktionalere Teams aber das Hauptziel der Umstellung auf agiles Arbeiten waren, steht auch das hier im Focus dieser "agilen Erfolgsgeschichte". Und darüber hinaus ist es ein gutes Beispiel dafür, wie weit wirkliche Crossfunktionalität gehen kann.

Eine häufige Beschwerde bei Veränderungsvorhaben in grossen Organisationen ist, dass unverhältnismässig viel Zeit in Meetings aller Art verloren geht. Workshop folgt auf Workshop, Steuerungskreis auf Steuerungskreis, Entscheidungsrunde auf Entscheidungsrunde - nur damit am Ende ein Ergebnis steht, für dessen Festlegung bereits ganz am Anfang alle Informationen zur Verfügung gestanden hätten. Warum tut man sich das an?

Eine interessante Erklärung dafür bietet der Soziologie-Professor Stefan Kühl im wie immer hörenswerten Podcast "Der ganz formale Wahnsinn". Ihm zufolge dienen derartiger Meetings nicht nur der rationalen Entscheidungsfindung, sondern auch dem Austragen von Machtkämpfen, deren Stattfinden zu derartigen Anlässen nicht nur möglich, sondern sogar gewünscht ist, die dort aber nach Möglichkeit auch abgeschlossen werden sollen - etwas, was ich mehrfach genau so erlebt habe.

Um das zu verstehen holen wir zunächst etwas aus: Veränderungen führen in sehr vielen Fällen dazu, dass es Gewinner und Verlierer gibt. Ein Abbau von Hierarchien reduziert Bürokratie, verknappt aber dafür die Karriereoptionen; die Schaffung von Spezialistenlaufbahnen ermöglicht individuellen Statusgewinn, das aber auf Kosten der Gleichbehandlung in Teams; etc. etc. Das ist meistens schon früh erkennbar und löst bei den negativ Betroffenen die erwartbaren Widerstände aus.

Werden Veränderungen jetzt (zu) schnell beschlossen, finden diese Widerstände im Rahmen der bereits neu geordneten Organisation statt, was diese von Beginn an lähmen kann. Gelingt es dagegen, die Widerstände (und die Anstrengungen zu ihrer Überwindung) vor die Entscheidung zur Neuordnung zu legen, und zwar so, dass die Gewinnerseite des dadurch entstehende Machtkampfes diese Entscheidung prägen darf, dann kann die Startphase der neuen Organisation weitgehend ungestört beginnen.

Die verschiedenen Workshops, Steuerungskreise und Entscheidungsrunden bilden in dieser Betrachtungsweise eine Arena, in der die verschiedenen Parteien vor den Augen der restlichen Organisation gegeneinander antreten, einzelne Auseinandersetzungen gewinnen, andere verlieren, nach und nach ermüden, neue Kraft schöpfen, Bündnisse schliessen und Rückzugsgefechte führen, bis letztendlich eindeutig klar ist, wer sich in welchem Bereich durchgesetzt hat.

Am Ende dieser Vorgänge stehen gleich mehrere Ergebnistypen: zum einen die Entscheidungen der Machtkämpfe, und mit ihnen auch die über das Ausmass und die Weiterführung der Veränderungen, zum anderen aber auch eine Legitimation und Delegitimation von Standpunkten. Die Gewinner können sich zukünftig auf den langen und ausführlichen Entscheidungsprozess berufen, den Verlierern kann vorgehalten werden, dass sie trotz ausreichender Zeit keine Mehrheiten für ihre Ideen finden konnten.

Was mit dieser Art einer Change-Herbeiführung verbunden ist, ist natürlich das Risiko einer hochemotionalen Konfliktaustragung, da jede Seite befürchten muss, nach einer Niederlage auf unabsehbare Zeit kein Gehör für Ihr Anliegen mehr zu finden. Schlimmstenfalls kann sogar das Gegenteil des Angestrebten erreicht werden, einer belasteter statt eines unbelasteten Neustarts, nur mit einer Belastung durch Verbitterung und Verletzungen statt durch weitergehende Widerstände.

Um das zu vermeiden kann es sich anbieten, Veränderungen nicht in seltenen, grossen Programmen durchzuführen, sondern in einer stetigen Reihe von kleineren Vorhaben. Der Arena-Effekt verschwindet dadurch zwar nicht, dadurch dass die Auseinandersetzungen kleiner und reversibler werden, gehen aber die zur Schau Stellung und die potentielle Emotionalität zurück. Und als ein Seiteneffekt sind in jedem einzelnen Fall auch weniger Meetings nötig, was wiederum zu weniger Beschwerden führt.

Bild: Pexels / Polina Tankilevitch - Lizenz

In den meisten agilen Teams sind die Daily Meetings (Daily Scrum, Daily Standup, Daily Symc, etc) ein fester Bestandteil ihrer Arbeitsweise. In einzelnen Fällen stösst dieses Konzept aber an Grenzen, etwa wegen nicht gegebener gleichzeitiger Verfügbarkeit, wegen Introvertiertheit oder (bei remote-Arbeit) wegen schlechter Internet-Verbindung. Um trotzdem im engen Austausch bleiben zu können, gibt es für solche Teams eine mögliche Alternaltive: digitales Working Out Loud (WOL).

Um Missverständnissen vorzubeugen: bei Working Out Loud handelt es sich in diesem Fall nicht um die seit 2015 entwickelte formalisierte Social Learning-Methode gleichen Namens, sondern um die dahinterstehende, 2010 von Bryce Williams entwickelte Grundidee, die lediglich aus zwei Prinzipien besteht: die eigene Arbeit sichtbar zu machen und sie in Erzählform zu vermitteln. Diese Prinzipien lassen sich auch in Team-interne Kommunikation übertragen.

Um das (in einer nicht-verbalen Form) zu tun braucht es zunächst einen gemeinsamen digitalen Kommunikationskanal. Das kann in der rudimentärsten Form eine Whatsapp-Gruppe sein. in den meisten Firmen sind aber professionelle Tools vorhanden (Teams, Slack, etc.), in denen sich eigene Kanäle für ein Team anlegen lassen. In diesen Chat kann man dann alles eintragen, woran man gerade arbeitet. Damit ist bereits das erste Prinzip erfüllt, die Sichtbarkeit.

Das zweite Prinzip, die Erzählform, ist nötig um die Information über die eigene Arbeit mit dem nötigen Kontext zu versehen. "Ich arbeite an Komponente XY" würde z.B. nicht klar machen, warum diese Arbeit stattfindet. "Ich arbeite wie besprochen an Komponente XY, damit unser Hauptkunde rechtzeitig die Exportfunktion bekommt die wir ihm bis Ende des Monats versprochen haben" macht dagegen den Hintergrund und die Prioritäten deutlich klarer.

Wichtig ist dabei, dass diese Information im Voraus stattfindet. Falls eines der anderen Teammitglieder Einwände, Fragen, Hinweise oder Verbesserungsvorschläge hat, können die dann noch eingebracht werden bevor die Arbeit begonnen wurde. Das Risiko, versehentlich unnötige oder in Relation unwichtige Arbeiten zu beginnen wird so minimiert. Und natürlich kann der Chat bei Unklarheiten auch für schnelle Klärungen und Abstimmungen genutzt werden.

Mit ein bisschen Übung kann diese Art des Working Out Loud einen Grossteil der Kommunikation ersetzen, die sonst in einem Daily Meeting stattfinden würde. Bei entsprechender Nutzung können die ausgetauschten Informationen sogar noch weiter angereichert werden, etwa durch Links zu Anforderungen oder Build Reports, durch angehängte Dateien oder in den Text eingebettete Screenshots und Diagramme. An diesen Stellen kann ein Chatt sogar besser sein als ein Meeting.

Schlechter als in einem Meeting lassen sich in einem Chat dagegen Stimmungen, Emotionen und sonstige soziale Aspekte sichtbar machen. Schlimmstenfalls kann es sogar zu Konflikten kommen, da Sorgen, Ungeduld oder Verärgerung nicht erkannt werden. Ein weiterer wichtiger Punkt ist, dass digitales WOL eine ständige Beachtung des Chats erfordert, was ggf. störend für Konzentration und Produktivität sein kann und zu Stress führen kann.

Digitales Working Out Loud kann also eine brauchbare Alternative zum klassischen Daily Meeting sein, es kommt aber mit einem Preis, dessen man sich bewusst sein sollte. Wenn nicht die oben genannten Gründe (oder ähnlich schwerwiegende) gegeben sind sollte man daher vor einer Umstellung die Vor- und Nachteile gegenüberstellen, und ggf. in einer Testphase erproben, wie der neue Modus funktioniert und mit welchen Effekten er verbunden ist.

Grafik: Pixabay / Brian Penny - Lizenz

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

Milan Milanović: How Google Measures and Manages Tech Debt

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

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

Alex Ewerlöf: When a team is too big

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.