On Lean and Agility

Bild: CCnull /  Tim Reckmann - CC BY 2.0

Nachdem es hier schon länger keine Besprechung eines "Management-Gesetzes" mehr gab, ist hier ein besonders schönes: Prescott's Pickle Principle, geprägt 1985 vom Informatiker und Unternehmensberater Gerald M. Weinberg in seinem Buch The Secrets of Consulting, in dem er zahreiche derartiger halb ernstgemeinter Gesetzmässigkeiten gesammelt und z.T. mit selbst erfundenen Ursprungsgeschichten versehen hat. Ein derartiges, nach dem fiktiven Lebensmittelhändler Prescott benanntes Gesetz lautet:

Cucumbers get more pickled than brine gets cucumbered.

Gerald M. Weinberg: The Secrets of Consulting; S. 72

Die zugrundeliegende Idee ist gewissermassen aus der Mengenlehre abgeleitet: die Flüssigkeit in einer Gurke (Cucumber) ist so viel weniger als die im umgebenden Essigglas, dass im Endprodukt der Essiggurke vor allem der Geschmack von Essig (Brine) übrigbleibt, und nur wenig Gurkengeschmack. Dieses Phänomen übertrug Weinberg als ein plastisches Bild auf die Tätigkeit, mit der er beruflich grossteils beschäftigt war - das Change Management.

Übertragen auf Veränderungsprozesse beschrieb er damit das häufige Phänomen, dass Personen, die in eine Organisation geholt werden um neue Impulse einzubringen, sich nach und nach durch Kompromisse, Sachzwänge, Unternehmenspolitik und andere Faktoren an den ursprünglich vorherrschenden Zustand anpassen, bis sie irgendwann zu einem Teil von ihm geworden sind und aufgrunddessen keine Veränderungsimpulse mehr setzen können. Sachlicher ausgedrückt:

A small system that tries to change a big system through long and continued contact is more likely to be changed itself

Gerald M. Weinberg: The Secrets of Consulting; S. 73

Diese Betrachtungsweise mag zunächst pessimistisch oder sogar defätistisch wirken, da man sie so verstehen kann, dass am Ende alle Veränderungsvorhaben zum Scheitern verurteilt sind. Das allerdings würde weit an Weinbergs Interntion vorbeigehen, der genau die gegenteilige Aussage treffen wollte: Veränderungen sind möglich, allerdings nur dann, wenn man sich der Mechanismen von Prescott's Pickle Principle bewusst ist und ihnen entgegenwirkt.

Die Analogie der Gurke im Essigwasser wurde in The Secrets of Consulting nämlich noch weiter getrieben - genau wie die harte Schale einer Gurke eine Zeit lang das Eindringen des Essigs verhindert, kann ein Change Agent (oder wie auch immer das auf deutsch heisst) sich eine Zeit lang dagegen wehren, von dem ihn umgebenden sozialen System assimiliert zu werden. In dieser Zeit kann er Wirkung entfalten, er sollte aber in der Lage sein zu erkennen, ab wann das nicht mehr der Fall ist und dann wieder gehen.

Wie alles an derartigen "Gesetzmässigkeiten" ist auch dieser Schluss mit Vorsicht zu betrachten und sollte vor allem im Kontext von Weinbergs Einsätzen in grossen, veränderungs-aversen Organisationen gesehen werden. In diesem Rahmen hat er aber eine gewisse Gültigkeit und erklärt damit auch, warum viele Konzerne, Behörden und sonstige Grossorganisationen in einem Zustand der "Dauerberatung" befinden, und ständig neue Unternehmensberater beauftragen, ohne dass das irgendwann ein Ende findet.

 Die Pointe in Weinbergs Buch besteht übrigens daraus, dass der Lebensmittelhändler Prescott den Verkauf von Essiggurken so stark verinnerlicht hatte, dass er in seinem nächsten Geschäft, einem italienischen Restaurant, die Pizza damit belegte. Damit entspricht er dem Antipattern eines Change Agents, der nicht nur zum Teil des ursprünglichen Problems wurde, sondern das auch noch als scheinbare Lösung weiterverbreitete. Eine Mahnung, wie man im schlimmsten Fall selbst enden könnte.

Grafik: Pixabay / Brian Penny - Lizenz

Gregor Hohpe: Transformation Gremlins

Tim Ottinger: Why is working faster not working?

John Cutler: Vertical vs. Horizontal Org Coupling

Kent Beck: Programming Deflation

Jamil Zaki: Every Team Needs a Super Facilitator

Zu den wichtigsten Kompetenzen eines Agile Coach, Scrum Master, Agile Consultant oder ähnlicher Rollen gehört es, die Idee agilen Arbeitens so zu erklären, dass sie auch von Menschen für gut befunden wird, die sich wenig mit dem Thema beschäftigt haben. Ein Patentrezept gibt es dafür natürlich nicht, aber einen Ansatz mit dem ich immer wieder sehr gute Erfahrungen gemacht habe: das Buzzwords in Conversation Limit, kurz BIC Limit.

Zur Erklärung: selbst für die Management-Sprache sind die agilen Frameworks mit sehr vielen so genannten Buzzwords überladen, also ungewöhnlich klingenden Begriffen oder Phrasen, die Sachverhalte kurz und prägnant wiedergeben sowie bei der Zielgruppe Interesse und Wiedererkennen hervorrufen sollen. Beispiele dafür sind Agil(e) und Framework selbst, aber auch leichtgewichtig, crossfunktional, iterativ-incrementell und viele weitere mehr. 

Das Problem von Buzzwords: um ihren prägnanten Charakter zu behalten, müssen sie zwangsläufig auf Details, Genauigkeit und Kontext und Klarheit verzichten. Das macht auch Sinn, kommt aber mit einem Preis - um sie im Sinn der ursprünglichen Intention voll zu verstehen, benötigt man entsprechendes Vorwissen. Hat man das nicht, klingen Buzzwords schnell wie leere Worthülsen, was eine im Umfeld agiler Frameworks durchaus häufige Aussenwahrnehmung ist.

Gleichzeitig können Buzzwords durch ihre minimalistische Natur sehr schnell zum Gegenstand von Interpretationen, Missverständnissen und Umdeutungen werden, ohne dass das zwangsläufig auffällt. Servant Leadership zum Beispiel kann auf derartig viele verschiedene Weisen verstanden werden, dass selbst innerhalb einzelner Unternehmen die Bedeutungen und Anwendungen so weit auseinanderlaufen, dass kaum noch Gemeinsamkeiten bestehen.

Beides, sowohl die (ohne Vorwissen scheinbar gegebene) Inhaltslosigkeit als auch die mitunter willkürlich und erratisch wirkenden Deutungen und Missverständnisse, tragen dazu bei, dass Buzzwords von vielen Menschen misstrauisch betrachtet oder sogar rundheraus abgelehnt werden. Und damit kommen wir zu einem Problem bei der Vermittlung agiler Arbeitsweisen - die Benutzung zu vieler Buzzwords kann hier eher schaden als helfen.

Das BIC Limit ist ein Weg um derartige negative Effekte zu begrenzen. Wenige Buzzwords, dafür aber auch weniger Misstrauen und weniger Ablehnung. Welche Begrenzungsmenge sinnvoll ist kann jeder für sich entscheiden, ich selber halte aber ein BIIC Limit von Eins für sinnvoll. Das heisst: Agil, Framework, leichtgewichtig, crossfunktional, iterativ-incrementell und ähnliche Begriffe benutze ich nach Möglichkeit in einem beruflichen Gespräch nur einmal.

Natürlich kann es dabei vorkommen, dass ein Konzept mehr als einmal thematisiert werden muss, allerdings ist das ab dem zweiten mal auch ohne Buzzword möglich. Agil bedeutet für mich zum Beispiel, in kurzen Zyklen Reaktions- und Lieferfähig zu sein. Das lässt sich auch genau so sagen, und es ist für die meisten Menschen auch sehr gut nachvollziehbar, was damit gemeint ist, und was nicht. Mein Erfahrungswert: Gespräche werden so besser.

Zuletzt noch eine kurze Meta-Betrachtung - ja, mir ist bewusst, dass ein BIC Limit ebenfalls ein Buzzword ist. Ironie der Geschichte.

Wer im Augenblick auf agilen Meetups oder Konferenzen unterwegs ist, findet die dort versammelten Scrum Master, Agile Coaches und Agile Consultants oft in einer pessimistischen Stimmung vor, wie man beispielhaft an der oben zu sehenden Session der letzten Agile Cologne sehen kann. Diese Stimmung ist erst einmal so wie sie ist, wie immer lohnt es sich aber auch hier, den Sachverhalt im grossen Kontext zu betrachten, da sich dann einiges relativiert.

Um mit der wichtigsten Differenzierung zu beginnen - wenn agile Methodiker darüber sprechen, dass "Agile tot ist", meinen sie in der Regel nicht, dass schnelle Reaktions- und Lieferfähigkeit in der Software-Industrie nicht mehr wichtig sind (in Krisen ist sogar das Gegenteil der Fall). Was sie meistens tatsächlich meinen ist, dass der "agile Jobmarkt", also der für Scrum Master, Agile Coaches/Consultants und ähnliche Rollen, zu verschwinden droht.¹ Und selbst das ist so nicht ganz richtig.

Wenn man das (durchaus reale) Schrumpfen des agilen Jobmarkts betrachtet, sollte man sich zunächst bewusst machen, dass er trotz des Übergreifens agiler Vorgehensweisen in andere Bereiche im Wesentlichen noch immer ein Teil des IT-Jobmarktes ist, und der ist bedingt durch die Rezession als Ganzer in der Krise. Es ist für die Betroffenen zwar nur ein schwacher Trost, aber (agilen und nicht-agilen) Entwicklern, Testern, Architekten und IT-Managern geht es gerade auch nicht besser.

Aus dieser vergleichbaren Situation anderer IT-Berufe ergeben sich aber besondere Folgen für die agilen Methodiker. Eine davon, die fast immer übersehen wird: in Zeiten eines schwierigen Arbeitsmarktes sind die Entwicklungsteams tendenziell weniger rebellisch als zu Fachkräftemangel-Zeiten, in dem sie schnell andere Jobs hätten. Und wenn Widerstände gegen kurze Lieferzyklen, hohe Transparenz und häufige Kommunikation zurückgehen, dann bedeutet das auch, dass es weniger Bedarf für agile Coaching gibt.

Ebenfalls zu beachten ist, dass während wirtschaftlicher Krisen sparsam mit Budgets umgegangen wird. In Folge dessen werden weniger Projekte neu gestartet und weniger neue Mitarbeiter eingestellt, was wiederum erneute Auswirkungen auf den Bedarf nach agilen Methodikern hat - es gibt weniger Trainings, Schulungen und Teambuilding-Workshops die gehalten werden müssen, und es gibt weniger Teams die durch ihe Storming-Phase begleitet werden müssen.

Zuletzt gibt es in vielen Firmen die Tendenz, (vorrübergehend) Dysfunktionen in den Entwicklungsteams in Kauf zu nehmen, wenn sich dadurch Geld einsparen lässt. Eine typische Ausprägung dieses Phänomens ist es, Rollen ohne unmittelbare eigene Wertschöpfung zu streichen oder mehreren Teams gleichzeitig zuzuordnen. Das betrifft häufig Scrum Master und Agile Coaches/Consultants, aber z.B. auch UX Designer, Product Owner, Architekten und weitere "Meta-Rollen".

Um die zentrale Botschaft zu wiederholen: für viele agile Methodiker mag es sich zur Zeit anfühlen, als würde die "Nachfrage nach agilem Arbeiten" zurückgehen. Das ist aber eine Verwechselung, was zurückgeht ist lediglich die Anzahl der Scrum Master-, Agile Coach- und Agile Consultant-Jobs. Und selbst die verschwinden auch nicht wesentlich stärker als der Branchenschnitt, bzw. ähnlich abstrakte Stabs- Koordinations- und Management-Jobs.

Was im Umkehrschluss angenommen werden kann: sobald die Wirtschaft wieder anzieht, neue Vorhaben gestartet und neue Mitarbeiter eingestellt werden, wird das auch zu einer Verbesserung auf dem "agilen Jobmarkt" führen, sei es weil der Fachkräftemangel wieder zu rebellischeren Teams führt, weil es wieder mehr zu begleitende Storming-Phasen gibt oder weil wieder eigesehen wird, dass es Sinn macht, jemanden zu haben, der regelmässig aus dem Hamsterrad heraustreten kann.

Ich gestehe, als Lesley Cordero ihren Vortrag damit begann, dass sie soziotechnische Systeme auf ihre einzelnen Teile herunterbrechen möchte, war ich schon angetan. Und als sich herausstellte, dass sie dabei über die Dichotomie von Produktentwicklung und Platform Engineering spricht, war ich überzeugt, dass es sich lohnt, bis zum Ende dabeizubleiben.

Inhaltlich geht es um eine Vielzahl von Aspekten, vom Organisationsaufbau über Architektur-Paradigmen und Führungsstile bis hin zu autonomen Teams und robustem Systemdesign. Ein guter Rundumschlag, in dem auch ganz nebenbei der Unterschied zwischen Platform Engineering und DevOps erklärt wird.

Heute gibt es einmal mehr ein Praxisbeispiel, diesesmal von Airtable, einem KI Startup aus dem Silicon Valley. Wie alle Startups muss auch dieses hier agil im eigentlichen Sinn sein, also in der Lage, schnell auf sich ändernde Kundenwünsche und Marktbedingungen zu reagieren. Anders als man denken könnte sind dort aber nicht alle Teams mit dem Ziel einer schnellen Reaktionsfähigkeit aufgesetzt, wie Firmengründer Howie Liu in Lenny's Podcast erklärt.

Es gibt bei Airtable zwei verschiedene Arten von Teams, deren jeweiliges Organisationsmodell an die zwei Arten des Denkens aus Daniel Kahnemans Bestseller Thinking, Fast and Slow angelehnt ist - auf der einen Seite die Fast-thinking Teams, die schnell, proaktiv, intuitiv und experimentgetrieben vorgehen sollen und auf der anderen Seite die Slow-thinking Teams, die abwägend, analytisch, strukturiert und sorgfältig arbeiten.

Wichtig für das Verständnis dieses Ansatzes ist, dass keine der beiden Team-Kategorien grundsätzlich besser oder schlechter ist als die jeweils andere (weder Kahnemann noch Liu sehen in dem Konzept des "langsamen Denkens" etwas Negatives), beide haben in ihrem jeweiligen Kontext ihre Vorzüge. Und diese unterschiedlichen Kontexte (und die Zuordnung der Kategorien zu ihnen) sind es auch, die die Idee der Fast- and slow-thinking Teams so interessant machen.

Fast-thinking Teams werden dort eingesetzt, wo neue Features und Produkte entwickelt werden, was besonders auf dem Markt für KI-Produkte hochgradig anspruchsvoll ist. Ein geradezu rasender technischer Fortschritt, ständige Innovationen, starker Wettbewerb und volatile Kundenbedürfnisse machen schnelles Agieren und Reagieren nötig, weshalb in diesem Bereich eine iterativ-incrementelle Auslieferung von Features im Wochenrhythmus vorgesehen ist.

Slow-thinking Teams sind dagegen dort angesiedelt, wo die Infrastruktur entwickelt wird, die die Basis dafür bildet, dass die von den Fast-thinking Teams entwickelten Features von einer rapide wachsenden Nutzerbasis in hoher Frequenz genutzt werden können. Hier stehen eher Verlässlichkeit, Skalierbarkeit, Resilienz und Berechenbarkeit im Focus, wodurch die Entwicklungsschritte hier deutlich langsamer, dafür aber mit grösserer Sorgfalt und Planung erfolgen.

Dieses bewusste gleichzeitige Aufsetzen von zwei verschiedenen und komplementären Vorgehensmodellen ist in modernen Tech-Unternehmen eher selten, viel häufiger wird versucht, alles nach einem gleichen Muster zu organisieren, dass dann im Einzelfall unpassend ist. Der Denkanstoss, den sich viele mitnehmen können, ist, dass Uneinheitlichkeit durchaus Sinn machen kann. Die kann dann in Form von Fast- and Slow-thinking Teams auftreten, ggf. aber auch ganz anders.

Sieh dir diesen Beitrag auf Instagram an

Ein Beitrag geteilt von Sam Lau (@samlauhaus)

Kommen wir noch einmal zurück zum Cult of the agile Amateur, also zu dem Phänomen, dass ein Grossteil der Agile Coaches, Scrum Master und Agile Consultants nur eine eher schmale Datenbasis zur Untermauerung ihrer Konzepte vorweisen kann und stattdessen sein Vorgehen vor allem auf Buchwissen, starke Meinungen (eigene und andere), subjektive Erfahrungen, unvalidierte Hypothesen, anekdotische Evidenz und ähnliche nicht-empirische Ansätze aufbaut.

Dieser Zustand hat sich mittlerweile in grossen Teilen verflüchtigt oder wenigstens abgeschwächt, da zumindest die grossen agilen Frameworks (Scrum, Kanban und SAFe) mittlerweile auf eine Anwendungsdauer von mehreren Jahrzehnten und eine Anwenderbasis von tausenden verschiedener Organisationen zurückblicken können, die auch in zahllosen Studien, Konferenzvorträgen, Fachartikeln und Erfahrungsberichten dokumentiert wurden.

Unabhängig davon gibt es aber weiterhin ein Phänomen, auf das der Name des Cult of the agile Amateur zutreffend ist: die Überzeugung, dass man den Job des Scrum Masters, Agile Coaches oder Agile Consultant nicht nur ohne technisches, fachliches und betriebswissenschaftliches Vorwissen ergreifen kann, sondern dass es auch dauerhaft unbedenklich möglich ist (oder sogar erstrebenswert ist), ihn ohne derartige Kenntnisse auszuüben.

Egal ob auf Konferenzen, auf Meetups oder in den Unternehmen selbst - regelmässig kann man hier agilen Methodikern begegnen, die nicht nur offen gestehen, die genannten Wissensgebiete nicht einmal in Ansätzen durchdrungen zu haben, sondern die es sogar als für ihre Berufsausübung als förderlich ansehen, diesen Zustand beizubehalten, um sich ausschliesslich auf die menschlichen und zwischenmenschlichen Aspekte ihrer Arbeit konzentrieren zu können.

Das mag zwar auf den ersten Blick irgendwie rational wirken, schliesslich gibt es für diese Wissensgebiete bereits Spezialisten, deren Berufs sich explizit um diese dreht. Was aber bei einer solchen Betrachtung vergessen wird, ist, dass technische, fachliche und betriebswissenschaftliche Aspekte sich in einem agilen Arbeitsmodus ändern müssen, und dass das jemandem in einem eher traditionellen Arbeitsmodus sozialisiert wurde nicht immer von alleine klar wird.

Egal ob es sich um continuous Integration, modulare Architektur, outcome-orientierte Anforderungen, Minimum Viable Products oder incrementelle Auslieferung handelt - im Vergleich zu klassischen Prozessen sind diese Ideen so anders und ungewohnt, dass oft grössere Erklär- und Überzeugungsarbeiten zu leisten sind, bevor sich darauf eingelassen wird. Und um diese leisten zu können, braucht es zumindest ein Grundverständnis in diesen Bereichen.

Das heisst natürlich nicht, dass man das alles von Beginn an können muss. Es heisst aber, das man bereit sein muss, sich in diese Wissensgebiete einzuarbeiten und sie sich anzueignen. Und die Bereitschaft dazu sinkt, wenn einem von den Anhängern des Cult of the agile Amateur eingeredet wird, dass das unnötig oder sogar nicht zielführend wäre. Wer daher auf Konferenzen, Meetups oder in Unternehmen derartige Aussagen hört, tut sich und Anderen einen Gefallen, wenn er ihnen wiederspricht.