On Lean and Agility

Schon seit langem gibt es in den menschlichen Gesellschaften Bemühungen, in großen Organisationen Positionen zu schaffen, die (bis zu einem gewissen Grad) von Anstand und Hierarchie befreit sind, um unangenehme Wahrheiten aussprechen zu können. In der Antike war es der Diener, der den siegreichen römischen Kaiser an seine Sterblichkeit erinnerte, im Mittelalter waren es die Hofnarren und später die Kabarettisten, die herrschende Personen und vorherrschende Ideen ungestraft angreifen durften.

Die Grundidee hinter diesen Traditionen war, dass die für die unangenehmen Wahrheiten zuständige Person gleich doppelt frei von Bedenken sein konnte: zum einen war sie durch ihre Narren-Stellung von zukünftigen Führungspositionen ausgeschlossen, und musste sich daher keine Sorgen darum machen, durch zu grosse Offenheit ihre Karriere zu gefährden. Zum anderen war sie durch die sprichwörtliche Narrenfreiheit vor Sanktionen durch die von ihr blossgestellten Mächtigen geschützt.

Auch in der Welt der moderenen Wirtschaft gibt es immer wieder Bemühungen, vergleichbare Rollen zu schaffen, die den Finger in die Wunde legen und ungestraft Group Think, Hierarchiegläubigkeit, Methodismus und unrealistischen Planungsoptimismus beim Namen nennen dürfen. Der amerikanische Ökonom Russell Ackoff prägte dafür in einem 1993 erschienenen Artikel den Begriff des "Corporate Jester", ungefähr übersetzbar mit dem "Unternehmens-Hofnarren".

Derartige Positionen hat es tatsächlich immer wieder gegeben (am vermutlich bekanntesten in Person von Paul Birch, dessen Position bei British Airways tatsächlich den Namen Corporate Jester trug), und auch im Rahmen der agilen Frameworks ist sie immer wieder als anzustrebende Positionierung genannt worden. Gerade für die Rollen des Scrum Masters und des Agile Coaches, denen so die Möglichkeit gegeben werden soll, Missstände in der Organisation zu thematisieren, ohne sich selbst zu beschädigen.

Dieser Ansatz kann auch tatsächlich funktionieren, ich habe in verschiedenen Unternehmen Menschen kennengelernt, die in der modernen Hofnarren-Rolle ihre Erfüllung gefunden haben, in ihr aufgegangen sind und für sie geschätzt wurden - bis hin zu dem Punkt, dass sie bewusst in Entscheidungsrunden eingeladen wurden, um dort durch das Infragestellen scheinbarer Gewissheiten die Diskussionen offener und kritischer zu gestalten.

Was aber auch klar sein muss: diese Positionierung kommt häufig mit einem Preis. Genau wie im Mittelalter werden auch vielen modernen Hofnarren ihre schmerzhaften Wahrheiten vor allem dann verziehen, wenn sie aus einer Position der tatsächlichen Machtlosigkeit heraus erfolgen. und nicht selten wird dafür gesorgt, dass sie in dieser auch verbleiben müssen - nicht einmal zwangsläufig aus Rache, oft einfach dadurch, dass für diese Rollen keine weiteren Aufstiegsmöglichkeiten vorgesehen sind.

Eine Möglichkeit um diesem Dilemma zu entgehen, ist der gezielte Einsatz in bestimmten Kontexten (gewissermassen als "situativer Corporate Jester"), während das Auftreten in anderen Zusammenhängen zurückhaltender und seriöser ist. In gewisser Weise ist man dann eher der Karnevalist als der Hofnarr - zu bestimmten Zeiten respektlos und rebellisch, im restlichen (Berufs-)Leben eine respektierte Stütze der Gesellschaft. Funktioniert besonders gut im Rheinland, aber nicht nur dort.

Die ikonische Schleife, die fast durchgehend zur Visualisierung der verschiedenen agilen Vorgehensmodelle genutzt wird, ist immer wieder zum Gegenstand von Spott und Kritik geworden. Dadurch, dass sie sich nach kurzer Aufwärtsbewegung nach hinten wölbt, kommt man am Ende wieder da an, wo man gestartet ist. Für viele Kritiker ist das auch die tragische aber treffende Beschreibung der agilen Bewegung, 25 Jahre nachdem sie im Februar 2001 auf einer Skihütte gestartet wurde.

Tatsächlich sind Projektmanagement und Softwareentwicklung in vieler Hinsicht wieder dort angekommen, wo sie damals bereits waren: schwergewichtige, bürokratische Prozessvorgaben werden an der Spitze grosser Organisationen definiert und den auf Effizienz statt auf Effektivität getrimmten Einheiten übergestülpt, Abhängigkeiten werden gemanaged statt aufgelöst und innerhalb der so gebildeten Prozess-Schicht bestehen prozesszentrierte, von der eigentlichen Arbeit entkoppelte Berufe.

Die Pointe: all das geschieht mittlerweile unter dem Label "Agile", also ausgerechnet jener Begrifflichkeit, die ursprünglich als Gegenwurf zu all dem gerade Gesagten entwickelt wurde. Die schwergewichtigen Prozessvorgabwn sind die Skalierungsframeworks, innerhalb derer die Effizienz der Teams an der Velocity ihres Outputs gemessen wird, koordiniert von einer Prozessschicht aus (Proxy-) Product Ownern, Scrum Mastern, Agile Coaches, Solution Managern und Release Train Engineers.

War also alles umsonst? Nicht unbedingt. Der Spott über die im Rahmen ihrer Schleifenform stehts zum Ausgangspunkt zurückkehrenden agilen Iterationen übersieht nämlich etwas Zentrales: jede einzelne Wiederholung führt zu Lerneffekten, und jeder neue Durchlauf ist dadurch anders (und oft besser) als die davor - was auch bedeuten kann, dass man dafür zurück auf Los gehen muss. Das gilt in der digitalen Produktentwicklung, es gilt aber genauso in der Weiterentwicklung der agilen Vorgehensmodelle selbst.

In dem Vierteljahrhundert seit der Erfindung des Begriffs der Agilität in den schneebedeckten Bergen haben zahlreiche derartige Lernschleifen stattgefunden. Reine Teamzentrierung führt zu Machtlosigkeit, zu grosse Management-Nähe dagegen zu Entkoppelung von der Praxis. Zu grosse Technik-Nähe führt zurück in organisatorische Silos, ein zu grosser Abstand zur Technik dagegen zu Meeting-Theater und Machbarkeitsphantasien. Jede dieser Schleifen hat geschmerzt, jede war wertvoll.

Denn auch das gehört zum Gesamtbild - vorgegebene Prozesse, Effizienzfixierung und umfangreiches Abhängigkeitsmanagement sind zwar wieder (oder immer noch) da, aber sie werden anders gesehen: nicht mehr als zwangsläufig richtig, sondern als notwendiges Übel, das es immer wieder zurückzuschneiden gilt. Und bei aller Problematik, die in der Aussage steckt, dass der Scrum Master sich selbst überflüssig machen soll - diese Sicht ist ein Paradigmenwechsel.

Und sogar sich selbst stellt die agile Bewegung in Frage. Der sich gerade vollziehende Abschied von Zertifizierungs-Kommerzialisierung, formalisierten Meeting-Ritualen und sich jeglicher Verantwortung verweigernden Methoden-Coaches mag sich oberflächlich betrachtet wie die Trennung von einem gescheiterten methodischen Ansatz anfühlen, man kann ihn aber auch als Teil des agilen Lernschleifen-Durchlaufs sehen. Wir haben dazugelernt, trennen uns von Fehlentwicklungen und starten neu.

Natürlich wird auch das wieder mit Skepsis und Ablehnung begleitet werden, mit Appellen, doch stattdessen auf "bewährte" Methoden zu setzen und mit dem Verweis darauf, dass dezentrale Selbstorganisation angeblich noch nie funktioniert hätte, was mittlerweile ja bewiesen wäre. Mit anderen Worten: die agile Bewegung ist zurück in der Rolle des Underdogs, dem man die Wirksamkeit seiner Ideen erst glaubt, wenn es sie beweisen kann. Sollte uns das Sorgen machen?

Ganz im Gegenteil: eine idealere Startbedingung für ihre nächste Iteration, die basierend auf evidenzgetriebenem Lernen besser sein kann als die davor, gibt es nicht. 

Die meisten "Gesetze" der Softwareentwicklung oder des Projektmanagement gehen auf Zitate ihrer Urheber zurück (Conway's Law, Hofstadter's Law, Brooks's Law, etc.) und spiegeln daher deren Auffassungen wieder. Ziv's Law, benannt nach Hadar Ziv, Professor der University of California, ist in dieser Hinsicht ein Sonderfall, da es seine ursprünglichen Aussagen verfremdend verkürzt. Bevor wir auf seine eigentliche Form schauen, ist aber hier zunächst die verkürzte:

Software specifications and requirements will never be fully understood

frei nach Hadar Ziv, ca. 1996

Zurückgeführt wird Ziv's Law auf seine im Jahr 1996 zusammen mit Debra J. Richardson veröffentlichte Studie The Uncertainty Principle in Software Engineering. Diese beschäftigte sich trotz ihres Namens allerdings nicht mit der Softwareentwicklung im Allgemeinen, sondern nur mit einem ihrer Teilgebiete: dem Software-Testen. Und in diesem Kontext sollte die Aussage der niemals vollständig verstehbaren Anforderungen und Spezifikationen auch gesehen werden.

Ziv und Richardson legten in ihrer Studie dar, dass sämtliche Anforderungen, und damit auch sämtliche Versuche, durch Tests sicherzustellen, dass sie korrekt umgesetzt wurden, Unsicherheits-fördernden Faktoren unterliegen: die Problembeschreibung muss Umgebungsfaktoren ausblenden um nicht zu ausufernd zu werden, die Lösungsbeschreibung kann nur bekannte mögliche Implikationen enthalten und keine noch unbekannten, und ihre menschlichen Verfasser sind fehlbar und können sich irren.

Bedingt durch diese Faktoren sind praktisch sämtliche Versuche, eine zu erstellende Software zu beschreiben, unvollständig, weshalb sowohl in Bezug auf die Umsetzung als auch in Bezug auf den Test unklar sein muss, ob die zugrunde liegenden Anforderungen wirklich im Sinne ihrer Verfasser verstanden wurden. Diese Unklarheit und ihre Folgen werden bereits auf einer der ersten Seiten von The Uncertainty Principle in Software Engineering adressiert:

Software systems under test include, among others, requirements specications, design representations, source code modules, and the relationships among them. These software artifacts are produced by requirements analysis, architectural design, and coding processes, respectively. Following UPSE [the Uncertainty Principles in Software Engineering], uncertainty permeates those development processes and, consequently, the resulting software artifacts. Plans to test them, therefore, will carry these uncertainties forward

Ziv & Richardson, The Uncertainty Principle in Software Engineering , S.4

Diese Darlegungen wird jeder, der sich schon einmal mit Softwareentwicklung beschäftigt hat, bestätigen können. Ihre grosse Schwäche ist aber, dass sie relativ langatmig und kompliziert formuliert wurden, so dass man sie sich kaum merken kann. Der Versuch, sie auf eine gut zu behaltende Zeile zu verkürzen, ist nachvollziehbar, allerdings kam diese Prägnanz mit einem Preis - der ursprüngliche Bezug zum Software-Test ging verloren, genau wie der Verweis zu den erforschten Unsicherheits-Faktoren.

Die verfälschend verkürzte Version von Ziv's Gesetz, die nur noch besagt, dass Anforderungen und Spezifikationen nie zur Gänze verstanden werden, ist übrigens nicht zwingend unzutreffend. Praxis-Beobachtungen sprechen sogar dafür. Anders als Zivs und Richardsons differenziertere Aussagen ist sie aber nicht mehr durch wissenschaftliche Forschungsergebnisse belegt. Sie ist damit lediglich eine durch anekdotische Evidenz belegte starke Meinung, dessen sollte man sich bewusst sein.

Manchmal hilft bei der Vermittlung komplexer Sachverhalte ein Video ungemein, so auch in diesem Fall. Erklärt wird die Idee der Verspätungskosten, bzw. der Cost of Delay. Gut verständlich und kompakt zusammengefasst, in nur wenigen Minuten.

Cost of Delay – An Introduction from Joshua Arnold on Vimeo.

Bemerkenswert ist, dass das Video bereits mehr als ein Jahrzehnt als ist. Was seine Erstellung damals für einen Aufwand bedeutet hat mag man sich kaum vorstellen. Heute mit KI ginge es sicher in einem Bruchteil der Zeit.

Bis zur Überarbeitung des Scrum Guide im Jahr 2020 enthielt er in Bezug auf die Definition of Done (DoD), sein zentrales Quality Gate, durch das alle neu erstellten Funktionalitäten passieren müssen, eine Formulierung, die zumindest aus meiner Sicht hochgradig kontrovers war. Sinngemäss stand in ihr, dass die Qualität des erzeugten Produkt oder Service sich verbessern liesse, indem der Umfang der DoD vergrössert würde. Oder im englischen Original:

As Scrum Teams mature, it is expected that their definitions of “Done” will expand to include more stringent criteria for higher quality.

Scrum Guide, 2017 Version

Nun ist dieser Passus wie gesagt seit dem Jahr 2020 Geschichte, er ist aber in vielen Teams und Organisationen noch immer im expliziten oder impliziten Verständnis von Scrum hängengeblieben. Daher lohnt sich eine nähere Betrachtung - warum kann die Idee einer "expandierenden Definition of Done" problematisch sein, und unter welchen Umständen ist es möglich, diese negativen Aspekte zu vermeiden oder sogar ins Vorteilhafte zu drehen?

Um mit dem problematischen Teil zu beginnen: eine DoD, die versucht, umfassend alle Eventualitäten zu regeln, wird zwangsläufig zu ausufernd grossen Kriterienkatalogen führen, die alleine aufgrund ihres Umfangs nicht mehr zu übersehen und kaum zu befolgen sind. Das ist eine Falle, in die viele Teams tappen. Vor allem in Wikis oder shared Docs mit ihrem unbegrenzten Platz kann es zu einem wuchenden Wachstum von manchmal geradezu absurdem Ausmass kommen.¹

Derartig aufgeblähte Dokumente sorgen dafür, dass die von ihnen betroffenen Teams und Projekte in einer Zwickmühle sitzen. Entweder stellen sie sicher, dass alles was dort steht befolgt und eingehalten wird, verbunden mit einem erheblichen Verwaltungs- und Dokumentationsaufwand. Oder sie riskieren, dass sie einzelne Elemente vergessen und übersehen und damit nicht einhalten (oder die Unübersichtlichkeit führt versehentlich dazu, dass einzelne Teile sich gegenseitig widersprechen).

Jetzt zum positiven Fall, bzw. zu der Frage, wie dieser aussehen kann. Die (vor allem für IT-Produkte naheliegende) Antwort - automatisiert. Genauer gesagt, die Einhaltungs-Überprüfung der DoD findet automatisiert statt. Vorgaben wie Testabdeckung, Lastfähigkeit, maximale Verschachtelungstiefe des Code, das Nichtvorhandensein von auskommentierten oder ausgetoggleten Features oder sogar korrekte Rechtschreibung lassen sich durch automatisierte Tests schnell validieren - auch in grossem Umfang.

Für Teams und Organisationen die so vorgehen wollen, ergibt sich dadurch die folgende Richtlinie: eine Definition of Done wird nur dann durch einen zunehmenden Umfang besser, wenn die enthaltenen Vorgaben zum Grossteil automatisiert validierbar sind.² Die nicht automatisiert überprüfbaren Teile können zwar ihre Berechtigung haben, um Unübersichtlichkeit und Bürokratie zu vermeiden, sollten sie aber regelmässig überprüft und ggf. verschlankt werden.

Bild: Pexels / Ekam Juneja - Lizenz

Stefan Kühl: Die Komplexitätsreduktion durch Managementmoden

Stefan Norrvall: Three Axes — Now What?

Stephanie Ockerman: Self-Managing Teams - From Compliance to Collaboration

Maarten Dalmijn: Red Vs Blue Roadmaps - Why Most Roadmaps Suck

Mike Fisher: Culture Debt

Ich sage es schon seit langem: eine der Hauptzielgruppen von Change-Vorhaben sind Manager, und im Sinn eines zielgruppenorientierten Vorgehens sollte man daher seine Botschaft so verfassen können, dass sie für Manager Sinn ergibt. Alan Holub hat da einige schöne Ideen.

Eine gewisse Ironie der Geschichte ist übrigens, dass Holub plötzlich aus einem unerwarteten Grund zusätzlich Management-kompatibel ist: durch seine Ablehnung des Begriffs "Agile". Die Gründe dafür sind unterschiedliche (bei ihm die mit der Zeit stattgefundene Kommerzialisierug und Formalisierung der agilen Frameworks, bei vielen Managern die enttäuschte Hoffnung auf ein Wundermittel), in der grundsätzlichen Abwehrhaltung kommen sie aber zusammen.

Bild: Unsplash / Vitaly Gariev - Lizenz

Eine der interessanteren Studien der letzten Zeit trägt den schönen Namen Führungsetage leer?¹ und kommt vom Kompetenzzentrum Fachkräftesicherung des Instituts der deutschen Wirtschaft. Ihr zufolge sind in deutschen Unternehmen fast 30.000 Führungskräfte-Positionen unbesetzt, gleichzeitig können sich aber nur wenige Nicht-Führungskräfte vorstellen, dorthin nachzurücken - nur 14 Prozent aller Angestellten wären ohne Vorbehalte bereit. Wir laufen damit in eine Art von Führungsproblem hinein.

Auch die Gründe dafür hat die Studie unter 5000 Teilnehmern abgefragt. Es sind hohe Arbeitsbelastung, zu grosse Verantwortung, zu grosse Einschnitte ins Privatleben, zu geringe finanzielle Anreize, der Kontaktverlust zur eigentlichen Arbeit (bzw. den dort arbeitenden Kollegen) und eine zu geringe Unterstützung von mittleren Führungspositionen durch das Topmanagement. Das sagt viel aus über die befragten Menschen, aber noch mehr über ihre Unternehmen.

Als jemand der seit 15 Jahren als externer Berater in zig Unternehmen unterwegs war muss ich leider sagen, dass diese Befürchtungen in vielen Fällen berechtigt sind, da es systemische Ursachen gibt, die zu genau diesen Ergebnissen führen. Zu grosse Aufgabenteilung und die Delegation von Verantwortung ohne Gestaltungsspielraum führen zu ständigen Abstimmungen und Eskalationen, wodurch die Rollen immer politischer werden und sich immer stärker von der eigentlichen Arbeit entfremden.

In diesen Zusammenhängen liegt aber auch die Chance es besser zu machen. Durch eine auf Produkte oder Kunden (statt auf Ressouceneffizienz) ausgerichtete Organisation lässt sich der Abstimmungs- und Eskalationsaufwand reduzieren, durch ein Konnexitätsprinzig kann Verantwortung an Gestaltungsspielraum gekoppelt werden und durch beides geht der Politik- und Bürokratie-Anteil der Arbeit zurück, wodurch wieder mehr Zeit für Fachlichkeit und Technikbezug bleibt.

Das ist natürlich in der Umsetzung eine alles andere als einfache Aufgabe, und die in diesen Ansätzen enthaltenen Ideen von dezentraler Autonomie und bewusstem Verzicht auf (temporäre) finanzielle Optimierung sind genau gegenläufig zur mehrheitlich gelebten Praxis grosser Organisationen. Eine Umgestaltung in diese Richtung wird daher in vielen Fällen auf Skepsis und Widerstände stossen. Stattfinden sollten sie aber trotzdem.

Ist das nämlich nicht der Fall, drohen sich die Tendenzen aus der Studie des Kompetenzzentrum Fachkräftesicherung zu verstärken. Dann wird (oder bleibt) die Arbeit als Führungskraft so unattraktiv, dass zu wenige sie ausüben wollen. Die zwangsläufige Konsequenz ist, dass Führungspositionen gar nicht besetzt werden, oder in Ermangelung geeigneter Kandidaten durch ungeeignete Personen. Und da kann ich wieder aus eigener Beratererfahrung sprechen: beides ist etwas, das man besser vermeiden sollte.