On Lean and Agility

Grafik: Pixabay / Brian Penny - Lizenz

Steve Blank: The Depart.ment of War Just Shot the Accountants and Opted for Speed

John Cutler: 'Functional' Feature Factories Explained

Maik Seyfert: Shadow Structures - The Unofficial Systems That Actually Run Your Organization

Kent Beck: Why Does Development Slow?

Christina Wodtke: The Premortem - Your Product’s Autopsy Before Launch

Wenn man sich auf die Betrachtungsweise einlässt, Organisationsentwicklung als ein Produkt oder einen Service zu betrachten, wird man sie deutlich besser verstehen und beeinflussen können. Das gilt sowohl für die Art wie an ihr gearbeitet wird, als auch für die Wahrnehmung und Behandlung von wichtigen Stakeholdern. Und da sich unter diesen ganz besonders höhere Manager befinden, ist die frage naheliegend - was treibt die eigentlich um?

Eine der wichtigsten Antworten darauf ist: das Geld. Genauer gesagt, die Fähigkeit der Organisation, durch profitables Arbeiten Geld zu erwirtschaften, schliesslich ist es genau das, woran Manager in der Regel von noch höheren Managern, Aktionären, Eigentümern oder Aufsichtsräten gemessen werden. Und mit diesem Gedanken im Hinterkopf ergibt die Ablehnung selbstorganisierter Teams durch viele Manager einen neuen Sinn - dahinter steckt oft die Sorge vor nachlassender Wirtschaftlichkeit.

Dass diese Sorge nicht völlig unbegründet ist, kann man bei vielen in die Selbstorganisation startenden Teams beobachten. Roadmaps und Zeitpläne? Budgetierung und Kostendeckel? Das in Frage stellen von technischem Perfektionismus? All das gilt plötzlich als Teil eines überkommenen Top Down-Managements. Dass durch diese Ablehnung die Profitabilität von Features und Produkten leidet, wird nicht gesehen - und die Verwunderung ist gross, wenn das Management auf einmal interveniert.

Wer es nicht so weit kommen lassen will sollte sich auf ein mittlerweile nicht mehr neues Konzept besinnen, das der Intrapreneurship, womit die Haltung von Angestellten gemeint ist, nicht nur wirtschaftliches Denken und Handeln anzustreben, sondern auch bereit zu sein, sich das dazu notwendige Wissen aus Marketing, Vertrieb, Rechnungswesen, Kundenservice und sonstigen relevanten Bereichen anzueignen und regelmässig aufzufrischen.

Natürlich wird das nicht bei jedem Team Begeisterung auslösen, die oben erwähnte Ablehnung vieler Management-Praktiken führt häufig zur fehlenden Bereitschaft, sich mit diesen manchmal anstrengenden Themen überhaupt auseinanderzusetzen. Das ist auch nachvollziehbar, blendet aber aus, dass diese Auseinandersetzung ein Preis ist, der für die Selbstorganisation (bzw. deren Duldung oder Förderung durch das Management) gezahlt werden muss.

Erst wenn die Führungsebenen die Zuversicht haben, dass auch ohne ihr Zutun Wirtschaftlichkeit und Profitabilität nicht vernachlässigt werden, werden sie die Bereitschaft entwickeln, Entscheidungs-Kompetenzen in nennenswertem Ausmass nach unten zu delegieren. Und noch  weitergedacht: wenn man ihnen glaubhaft machen kann, dass Selbstorganisation zu mehr wirtschaftlichem Denken führen wird als Steuerung und Anleitung, werden sie sogar aktiv nach ihr verlangen.

Und um auch die Manager selbst in die Pflicht zu nehmen: dafür zu sorgen, dass ihre Mitarbeiter wirtschaftlich denken können ist eine ihrer wesentlichen Aufgaben und sollte in Ausbildungen, Weiterbildungen und Personalentwicklung verankert werden. Es handelt sich dabei schliesslich um die Mehrung von Humankapital, die eine zentrale Aufgabe jeder Führungskraft ist - ein weiterer Aspekt des Denkens als Intrapreneur, nur eine Ebene weiter oben.

Ich glaube ja, dass man die Entstehungsgeschichte von Ideen und Praktiken kennen sollte, wenn man wissen will, wie sie gedacht sind, welche Probleme sie lösen sollen und wofür sie nicht gedacht sind. Vor diesem Hintergrund bin ich sehr angetan von diesen Ausführungen von Hana Amiri, die sehr schön darstellt wo DevOps herkommt, wie es sich entwickelt hat, was es erleichtert hat und zu welchen neuen Problemen es geführt hat.

Der Gedanke hinter dem provokanten Titel, der das Paradigma "You build it, you run it" negiert, ist, dass diese doppelte Verantwortung viele Teams übermässig belastet und daher nicht skaliert. Der sich daraus ergebende Schluss, dass Platform Engineering die beste Form von DevOps at Scale ist, dürfte kontroverse Debatten auslösen - genau wie gute Vorträge es sollen.

Bild: Pexels / Sternsteiger Stahlwaren - Lizenz

Eine der kontroverseren agilen Praktiken sind die so genannten "Hardening Sprints", in denen keine neuen Funktionalitäten entwickelt werden, sondern in denen stattdessen die noch fehlenden Restarbeiten erledigt werden, die nötig sind um mit Betrieb, Benutzung, Verkauf, o.Ä. beginnen zu können. Warum sie kontrovers ist? Weil sie dem Anspruch zuwiderläuft, nach jedem Sprint durch Erfüllung der Definition of Done "potentially shippable", also direkt gebrauchsfertig zu sein.

Trotz dieser umstrittenen Natur gehören Hardening Sprints zu den ältesten und langlebigsten Scrum-Praktiken. Bereits 2007 wurden sie vom Scrum-Pioneer Mike Cohn (moch unter dem Namen Release Sprint) als ein übliches Vorgehen beschrieben, zu Beginn der 2010er Jahre waren sie Teil von SAFe, (wo aus ihnen später die Innovation and Planning Iteration wurde) und bis heute werden sie von vielen Teams und Unternehmen vor Releases durchgeführt.

Vermutlich geht die kategorische Verteidigung oder Ablehnung von Hardening Sprints aber ohnehin in die falsche Richtung. Statt dogmatisch auf einer dieser Positionen zu verharren könnte man sich fragen, was in einem solchen Sprint stattfinden könnte, selbst wenn das in der vorherigen Zeit entwickelte Produkt nach jedem Sprint potentially shippable gewesen ist (zur Abgrenzung: um Kontexte in denen kontinuierliches potentially shippable nicht möglich ist geht es hier nicht, das ist ein eigenes Thema).

Refactoring

Es kann vorkommen, dass eine Anwendung funktionierend auf Production deployed ist, ohne dass es unter der Motorhaube durchgehend Clean Code, eingehaltene Benennungskonventionen, konsistente Architektur, o.Ä. gibt. Das kann in einem nachgelagerten Sprint nachgeholt werden, um sicherzustellen, dass auch zukünftig alles verstanden und mit geringem Aufwand erweitert werden kann.

Langlaufende Tests

Es ist zugegebermassen ein Edge Case, aber es in manchen Kontexten (z.B. bei kombinierten Hardware-/Software-Produkten) gibt Last- und Regressiontests, die mehrere Tage lang laufen, und damit gegebenfalls sogar länger als ein Sprint dauert. Diese Tests zu Ende zu führen kann sinnvoll und notwendig sein um sicherzustellen, dass wirklich alles funktioniert.

Löschen von Testdaten

Mitunter können sich an erstaunlich vielen Stellen eines Systems noch Testdaten befinden, was ggf. auch unvermeidbar ist, wenn bis zum letzten Tag des letzten richtigen Sprints noch entwickelt und getestet wird. Ein System vor dem Go Live auf derartige Datensätze fiktiver Produkte, Nutzer, etc. zu durchsuchen, bzw. sie mit Probe-Durchläufen sichtbar zu machen, kann eine gute Idee sein.

Aufspielen von Produktionsdaten

Der umgekehrte Fall. Bei vielen der im Echtbetrieb verwendeten Daten ist es wichtig, dass sie so aktuell und genau wie möglich sind, etwa im Fall von Zahlungs- und Auslieferungsbelegen. Dazu kommt, dass ihre Aufspielung auf Entwicklungs- und Testsysteme oft datenschutz- und haftungsrechlich problematisch wäre. Ihre Übertragung kann eine der Entwicklung nachgelagerte Arbeit sein. 

Monitoring (und ggf. Bugfixing)

Auch nach dem Übertragen aller Funktionen und Daten auf die Produktionsumgebung können noch zu erledigende Arbeiten übrigbleiben. Da sich der echte Livebetrieb nie völlig simulieren lässt, beginnt er oft mit einer "Hypercare"-Phase in der durch intensives Monitoring sichergestellt wird, dass nur dort auftretende Bugs schnell gefunden und behoben werden.

Schulung der Service-Mitarbeiter

Ein in vielen Fällen nicht zu unterschätzender Aufwand ist die Schulung der Service-Mitarbeiter, die für die Betreuung der Anwender einer neuen Software zuständig sind. Gerade wenn agil bin in den letzten Sprint Features entwickelt werden, kann sich das Systemverhalten auch bis zum letzten Entwicklungstag ändern, so dass eine Schulung in einer stabilen Phase sinnvoll sein kann.

User Onboarding

Eine ähnliche, und häufig auf den letzten Punkt aufbauende Tätigkeit. Vor allem bei grossflächig firmeninternen Anwendungen kann es notwendig sein, den Anwendern neuer Funktionen die Möglichkeit zu geben, sie auszuprobieren, Fragen zu stellen und Erklärungen zu erhalten. Das kann ggf. bereits im Echtbetrieb stattfinden.

Natürlich ist diese Aufzählung nicht vollständig. Es sind noch viele weitere Tätigkeiten denkbar, die in einem nach dem Ende der Entwicklung stattfindenden Hardening Sprint stattfinden können, ohne dass es sich dabei um Dinge handelt, die bei Einhaltung der Definition of Done früher hätten erledigt werden müssen. Und mit diesem Wissen im Hintergrund sollte es möglich sein, die Diskussion um derartige Sprints sachlich und undogmatisch zu führen.

Bild: Pexels / Sharath G. - Lizenz

Unter den vielen Arten, den Umgang mit Veränderungen zu strukturieren, gehört es, sich nicht nur eine Grundhaltung zuzulegen, sondern mehrere. Das geht ein bisschen gegen gängige Weisheiten und Faustregeln, die meistens nur eine derartige Haltung empfehlen, wie z.B. kritischen Rationalismus, Bias for Action, Being like a River und viele weitere. Der Wechsel zwischen Haltungen macht aber Sinn, und ich empfehle besonders zwei: Aktivismus und Stoizismus.

Unter Aktivismus versteht man eine Einstellung in deren Rahmen man bewusste Handlungen durchführt, die das Ziel haben, Veränderungen zu fördern, meistens solche, die man persönlich für wichtig oder dringlich hält. Wie diese Veränderungs-Förderung aussieht kann von Fall zu Fall unterschiedlich sein, vom Schaffen eines Sense of Urgency über das Beschleunigen bereits stattfindender Veränderungen bis hin zum Beseitigen von Hindernissen.

Beim Stoizismus dagegen steht im Mittelpunkt die Fähigkeit, gelassen mit Veränderungen umzugehen, vor allem solchen, die sich nicht verhindern lassen. Mögliche Mittel zu diesem Zweck sind die Bewusstmachung der relativen Nichtigkeit und Flüchtigkeit vieler Sachverhalte, das Gegenüberstellen grösserer, von den Veränderungen nicht betroffener Werte und Zusammenhänge, das Einüben von Anpassungsfähigkeit und Resilienz und der Verzicht auf übermässige Emotionalität.

Beide Haltungen haben in bestimmten Kontexten ihren Sinn. Dort wo Veränderungen möglich, aber ggf. schwierig sind, hilft der Aktivismus. Mit ihm kann man ständig neue Impulse setzen, andere überzeugen und ein Zurückfallen in alte Muster vermeiden. Dort wo unerwünschte oder gegenläufige Veränderungen nicht zu verhindern sind, hilft dagegen der Stoizismus gegen Frustration und ergebnisloses Aufreiben im Kampf gegen das Unvermeidbare.

Die entscheidende Frage ist jetzt "nur noch" wann welcher der beiden Kontexte gegeben ist. Das lässt sich natürlich nicht kategorisch beantworten, allerdings kann man mit der Zeit die Fähigkeit entwickeln, Merkmale zu identifizieren, die starke Indikatoren für einen der beiden sind. Diese Erfahrungsweisheit ist der Schlüssel für den situationsgemäss passenden Einsatz von Aktivismus und Stoizismus. Oder mit einem bekannten Stossgebet gesagt:

Gott, gib mir die Gelassenheit, Dinge hinzunehmen, die ich nicht ändern kann,
den Mut, Dinge zu ändern, die ich ändern kann,
und die Weisheit, das eine vom anderen zu unterscheiden.

Reinhold Niebuhr: Gelassenheitsgebet, ca. 1940

Ich bitte um Entschuldigung, aber hier wird jetzt geflucht. Genauer gesagt wird es um Bullshit gehen, die englische (und wesentlich obszönere) Übersetzung des deutschen Wortes Bockmist, und dabei um ein Phänomen, das viel zu selten beachtet wird - das der Bullshit-Artefakte. Gemeint sind damit Hinterlassenschaften und Ergebnisse von Tätigkeiten, die keinen sinnvollen Zweck erfüllen, aber trotzdem aus irgendeinem Grund stattfinden.

Zuerst ein kurzer Blick zurück. Als Schimpfwort existiert Bullshit etwa seit dem ersten Weltkrieg und stammt angeblich ursprünglich aus Australien und Neuseeland. Zu Beginn ein blosser Ausruf der Frustration, wandelte er sich mit der Zeit zu einem Werturteil über eklatant unsinnige Zustände oder Sachverhalte. In dieser Bedeutung erstmalig  umfassend beschrieben wurde er 1986 vom amerikanischen Philosophen Harry G. Frankfurt in seinem legendären Aufsatz On Bullshit.

Aufbauend darauf definierte der amerikanische Anthropologe David Graeber 2018 die Kategorie der Bullshit Jobs, also von Berufen, die ihrem Wesen nach unsinnig oder überflüssig sind, die aber trotzdem in Organisationen vorgeschrieben oder von ihren Inhabern ausgeübt werden. Beispiele dafür sind der Manager, der aussagefreie Statistiken erhebt oder der Büroarbeiter, der nicht wertstiftende oder nicht nachhaltige Tätigkeiten durchführt.

Die Bullshit Jobs haben seitdem einen festen Platz in der Betrachtung grosser Organisationen gefunden, was aber eher wenig betrachtet wird sind ihre Arbeitsergebnisse. Auf den ersten Blick ist das auch unnötig, schliesslich werden sie ja gerade durch ihre Nicht-Wertschöpfung charakterisiert. Auf den zweiten Blick ist eine Beschäftigung damit aber um so dringlicher, schliesslich stellt sich die Frage, ob nicht doch Ergebnisse entstehen, die genauso unsinnig sind wie die Tätigkeiten.

Und tatsächlich ist genau das der Fall. Zwar entsteht kein nutzbarer Mehrwert, dafür aber Hinterlassenschaften (organisationssoziologisch: Artefakte), verschiedener Art. Diese sind sogar noch kritischer zu betrachten, als man denken könnte, denn nicht nur werden bei ihrer Erstellung Zeit und Ressourcen verbraucht, sie sind häufig auch Ausgangspunkt für weitere, ebenso wenig wertvolle Tätigkeiten, die wiederum weitere derartige Hinterlassenschaften erzeugen, etc.

Bei genauerer Betrachtung lassen sich zwei Typen derartiger Bullshit-Artefakte erkennen. Bei der ersten handelt es sich um die Ergebnisse von Sinnlos-Tätigkeiten. Beispiele dafür sind von niemandem angeforderte und von niemandem gelesene Berichte, die Einhaltung irrelevanter Formatierungen (z.B. der alphabetischen Anordnung von Email-Empfängern) oder das Ausdrucken, Stempeln und wieder Einscannen von Formularen. Schwierig wird das, wenn es zur Vorschrift wird, die alle erfüllen müssen.

Der zweite Typ liegt vor, wenn eigentlich sinnvolle Tätigkeiten mit Sinnlos-Prozessen überzogen werden. Beispiele dafür sind (schein-)genaue Aufwandsschätzungen in volatilen Markt- oder Technik-Umfeldern, die übergreifende Priorisierung aller Aufgaben in Unternehmen, in denen die Teams so spezialisiert sind, dass sie die höher priorisierten Aufgaben im Zweifel gar nicht übernehmen können, oder die Erstellung von Fortschrittsberichten auf Basis unfertiger Arbeitspakete.

Besonders der zweite Typ kann in immensem Ausmass Bullshit-Folgetätigkeiten nach sich ziehen, nämlich dann, wenn versucht wird, die Realität an die Inhalte des jeweiligen Bullshit-Artefakts anzupassen. Das geschieht in derartigen Kontexten nämlich meistens durch noch mehr Bullshit Jobs, also durch weitere unrealistische Aufwandsschätzungen, weitere nicht umsetzbare Priorisierungen, weitere aussagefreie Fortschrittsberichte, etc.

Wichtig beim Gegensteuern gegen derartige Verhältnisse ist übrigens, bei der Wurzel anzufangen. Dort wo sich Bullshit-Artefakte häufen, wird es nur wenig helfen, auf eine bessere Qualität der offensichtlich unsinnigen Berichte, Priorisierungen, Schätzungen, etc. zu dringen. Die erfolgversprechendste Methode ist die ersatzlose Abschaffung der dahinterliegenden Bullshit Jobs. Mit ihnen verschwinden dann auch die von ihnen produzierten unsinnigen Ergebnisse.

In Frankreich und Deutschland hat die Passage "Passierschein A38" aus dem Film Asterix erobert Rom es geschafft, sprichwörtlich für die Exzesse überbordender Verwaltungsappareate zu werden, die die Betroffenen durch nicht enden wollende Bürokratie in den Wahnsinn treiben. Mittlerweile kann man sich durchgehend an ihr erfreuen, denn der Rechte-Inhaber Canal+ hat sie auf Youtube veröffentlicht.

Ein häufiger unterschätzter, die Realität gut darstellender Seitenaspekt ist dabei, dass die Bürokraten selbst keineswegs Teil einer sinistren Verschwörung sind, sondern eigentlich normale Menschen, die nur irgendwann durch die sie umgebenden absurden Abläufe abgestumpft wurden, und die ihnen gegebenenfalls ebenfalls als Betroffene ausgeliefert sind.