On Lean and Agility

So wie es aussieht, hat Scott Ambler, der Erfinder von Disciplined Agile, seine beiden viralen Linkedin-Posts The Agile Community Shat The Bed und How Agilists Can Move Forward After Shatting the Bed zu einem Vortrag ausgebaut. Die Wortwahl ist noch immer grenzwertig, seine Analyse der Fehlentwicklungen in der agilen Community bleiben aber richtig. Und immerhin gibt er dem Ganzen noch einen positiven Ausblick.

Abseits von der Inhaltlichen Ebene ist die Bildsprache seiner Präsentation noch bemerkenswert. Man muss Memes mögen, um an ihr Gefallen zu finden, dann ist die aber großartig. Daher: ein Vortrag den man auch sehen sollte, nicht nur hören.

Bild: Unsplash / Jessica Gale - Lizenz

Ich kann es nicht mehr genau nachvollziehen, aber mittlerweile dürfte ich über hundert Job-Interviews mit Scrum Mastern, Agile Coaches und Inhabern ähnlicher Rollen geführt haben, sowohl für meine eigene Firma als auch für verschiedene Kunden. Und selbst wenn es die eine entscheidende Antwort auf sie nicht gibt, mit der Zeit habe ich eine Frage gefunden, mit der sich gut feststellen lässt, ob mein aktueller Gegenüber wirklich verstanden hat, was es mit dem Konzept der Agilität auf sich hat.

Sie ist relativ einfach: "Gibt es irgendeinen Kontext, in dem es nicht sinnvoll ist, agil zu arbeiten?" Erstaunlich viele Bewerber verneinen das und versteifen sich darauf, dass es immer sinnvoll wäre, agil vorzugehen. Und wenn man darum bittet, das zu erklären, erfolgt fast immer die selbe Erläuterung: "Es gibt immer irgendetwas, was man besser machen kann. Deshalb ist es grundsätzlich in jeder Situation eine gute Idee, agil vorzugehen".

Der grundsätzliche Denkfehler, der dieser Argumentation zu Grunde liegt (und durch den man zeigt, die Idee der Agilität noch nicht zur Gänze verstanden zu haben) ist die Gleichsetzung von agilem Arbeiten mit der Suche nach Verbesserungspotential. Dabei handelt es sich allerdings um eine Verwechselung der notwendigen und der hinreichenden Bedingung. Wer agil arbeiten will, muss zwar nach Verbesserungen suchen, aber nicht jeder der nach Verbesserungen sucht, arbeitet agil.

Um das zu erläutern: eine agile Vorgehensweise unterscheidet sich von der blossen Suche nach Verbesserungspotential durch zwei Eigenschaften: sie findet kontinuierlich statt und sie ist potentiell disruptiv. Und auch die lassen sich nochmal besser erläutern, angefangen mit der ersten. Eine Suche nach Verbesserungen könnte auch jährlich oder quartalsweise stattfinden. Um das agil-typische ständige Inspect & Adapt zu erfüllen reicht das aber nicht - kontinuierlich bedeutet hier eher monatlich.¹

Jetzt zur zweiten, etwas schwerer zu erklärenden Eigenschaft: die blosse Suche nach Verbesserungen kann auch lediglich auf Effizienzsteigerungen ausgerichtet sein, also darauf, einfach schneller und reibungsloser zu arbeiten. Agiles Arbeiten ist dagegen auf Effektivitätssteigerung ausgerichtet, also auf die Frage, ob überhaupt noch am richtigen Thema gearbeitet wird, oder ob sich Rahmenbedingungen oder Ziele inzwischen so geändert haben, dass man eine grundsätzlich andere Richtung einschlagen solllte.

Diese Möglichkeit, die bisher verfolgten Zielsetzungen anzupassen, ist das, was agiles Arbeiten disruptiv macht. Und da diese Richtungsanpassung nichts ist, was man bei jeder Verbesserungsbemühung zwangsläufig machen sollte, sondern nur dann, wenn man darin einen Sinn erkennt, ist Agilität nicht zwangsläufig disruptiv sondern lediglich potentiell disruptiv. Es kann zu einer grundsätzlichen Anpassung kommen, es muss aber nicht. Notwendige und der hinreichende Bedingung.

Um auch die anderen Vorgehensmodelle beim Namen zu nennen - seltene (bzw. nicht-kontinuierliche) Veränderungen entsprechen dem klassischen Verbesserungsmanagement, dessen explizites oder implizites Ziel die (Wieder-)Herbeiführung eines stabilen Zustandes ist. Und kontinuierliche, aber nicht disruptive Optimierungen finden sich im Lean Management, das einen gleich bleibenden Ablauf nach und nach immer effizienter machen will.

Diese drei Typen (agiles Arbeiten, klassisches Verbesserungsmanagement und Lean Management) unterscheiden zu können ist etwas, das jeder Scrum Master oder Agile Coach eigentlich beherrschen sollte - zumindest dann, wenn er in einer beratenden Funktion arbeitet, sei es extern (wie in meiner Firma) oder intern (als Change Agent innerhalb einer Organisation). Kann man das noch nicht ist das zwar kein Drama, aber ein deutlicher Hinweis darauf, wo noch dazugelernt werden muss.

Bild: Wikimedia Commons / Japanische Akademie der Wissenschaften - CC BY 4.0

Manchmal kommen die tragischen Entwicklungen schnell und unverhofft. Nur zwei Tage nachdem ich sein bahnbrechendes Paper The New New Product Development Game empfohlen habe ist Ikujirō Nonaka gestorben, einer der grossen Vordenker der Methoden, die wir heute ale Agil bezeichnen würden. Was dadurch in Erinnerung gerufen wird: leider müssen wir uns in den nächsten Jahren auf weitere derartige Trauer-Nachrichten einstellen - und die werden Folgen haben.

Zur Einordnung: grossteils aufbauend auf das oben erwähnte Paper sind die meisten agilen Vorgehensmodelle (Scrum, XP, IT-Kanban, Agile Testing, etc) zwischen den späten 80er und frühen 2000er Jahren entstanden. Da ihre Erfinder bereits damals über einige Jahre oder sogar Jahrzehnte Berufserfahrung verfügten, sind sie mittlerweile in ihren 60ern, 70ern oder 80ern angekommen. Und obwohl sie hoffentlich noch lange leben werden - nicht jeder dürfte 90 werden, so wie Nonaka.

Das ist deshalb von Bedeutung, weil diese Vordenker bisher durch ihre öffentlichen Meinungsäusserungen ein Korrektiv zu den verbreiteten esoterischen oder komerziell getriebenen Fehldeutungen ihrer Arbeit bilden konnten, legitimiert dadurch, dass sie schliesslich selbst am Besten sagen können, was sie mit ihren Ansätzen beabsichtigt haben und was nicht (das bekannteste Beispiel dafür dürfte ihre einhellige Ablehnung des Scaled Agile Framework / SAFe sein).

Mit dem absehbaren Verschwinden dieser Stimmen (das auch bereits durch einen altersbedingten Rückzug aus der Öffentlichkeit geschehen kann) dürfte es in der Zukunft immer weniger mit einer derartigen Autorität ausgestattete Widersprüche gegen absichtliche oder versehentliche Verfremdungen der agilen Ideen und Prinzipien geben. Und noch bedenklicher: kommerzielle Organisationen wie Scrum Alliance, SAFe, Kanban University und PMI werden diese Autorität vermutlich für sich beanspruchen.

Um so wichtiger wird es werden, die von den agilen Pionieren verfassen Originalquellen (von denen es aufgrund der Entstehung der Agilität in den Schatten ohnehin viel zu wenige gibt) in Erinnerung zu behalten und als Massstab für die Bewertung neuer Entwicklungen zu benutzen, von der Forschung Nonakas und Takeuchis über die frühen Vorträge auf den OOPSLA- und Agile-Konferenzen bis zu den Büchern und Artikeln der Verfasser des Manifests für agile Softwareentwicklung.

Die grosse Herausforderung dabei wird es sein, derartig auf den Schultern der Riesen zu stehen, dass deren Absichten gewahrt bleiben, ohne dass es zu einer rückwärtsgewandten Erstarrung der damit verbundenen Methoden kommt. Andererseits - verglichen mit dem, was zwischen den späten 80er und frühen 2000er Jahren geleistet wurde, ist das eine fast schon einfache Aufgabe. Und noch haben wir genug Zeit um uns von den agilen Vordenkern inspirieren zu lassen.

Manchmal sind die Dinge die man im Internet findet so gut, dass man sie nicht weiter verbessern muss. So auch in diesem Fall, der Beschreibung der Eigenschaften guter und schlechter Prozesse durch John Cutler auf Linkedin. Das einzige was ich gemacht habe, war die Übersetzung ind Deutsche, sonst sind sie so geblieben wie von ihm verfasst. Ich bin versucht, diese Liste von jetzt an auf jeden Einsatz mitzunehmen und dort mit allen anderen zu teilen.

Ein guter Prozess

• ermutigt zu Achtsamkeit.
• flexibel für lokale Belange.
• anpassungsfähig, häufig in Frage gestellt/verbessert.
• meistens gewollt, weil es wertvoll ist.
• Grundprinzipien werden verstanden.
• ermutigt zu Gesprächen/Kollaboration.
• mit den Anwendern gemeinsam erstellt/entworfen.
• Wert für alle Beteiligten.
• stärkt das Vertrauen in die Ergebnisse.
• reduziert auf die Kernaufgabe (leichtgewichtig).
• erzielt lokale Konsistenz mit minimalen Auswirkungen auf die Resilienz. Verbessert globale Ergebnisse.
• Verbesserung des Nutzens für die Endkunden.
• Leitfaden/Werkzeug/Navigieren/Erinnern.
• verbessert das Vertrauen/die Sicherheit.

Ein schlechter Prozess

• ermutigt zu Unachtsamkeit.
• unflexibel gegenüber lokalen Belangen.
• in Stein gemeißelt/nicht verhandelbar.
  
• meistens den Teilnehmern aufgezwungen.
• automatische/erzwungene Befolgung.
• reduziert die Qualität/Quantität von Gesprächen.
• entworfen im Vakuum und aufgezwungen.
• einseitiger Wert.
• losgelöst von den Ergebnissen.
• belastet durch viele Aufgaben/Zuständigkeiten.
• erzielt lokale Konsistenz zum Nachteil der Resilienz und der globalen Ergebnisse.
• abgekoppelt vom Kundenwert.
• Kontrolle/Anleitung.
• Vertrauensersatz, Sicherheitsersatz.

Und für eine bessere Übersicht ist es hier nochmal als Gegenüberstellung:

Es gibt diese Momente, in denen jemand bewusst oder unbewusst etwas Augenöffnendes sagt, das komplexe Sachverhalte, mit deren prägnanter Formulierung man sich bis dahin schwer getan hätte, auf einmal kurz und klar zusammenfasst. Ich habe diesen Moment früher in diesem Jahr im Rahmen eines Einsatzes bei einem Kunden gehabt, bei dem ein Mitarbeiter beschrieb, wie sich seine Wahrnehmung der Scrum Master über die Zeit geändert hatte. Seine Aussage war:

Back in the days, talking to Agilists was like talking to a bunch of tech-nerds. Today it's like talking to HR.

Ins Deutsche übersetzt: damals (der Mitarbeiter war schon seit deutlich über zehn Jahren im Unternehmen), fühlten sich Unterhaltungen mit den Agilisten wie Gespräche mit technikverliebten Spezialisten an. Heute ist es so, als würde man mit der Personalabteilung reden. In diesem Satz (der so in vielen Firmen fallen könnte) steckt unglaublich viel an Inhalt, da er aber ein bisschen Vorwissen benötigt, kommt hier etwas Kontext. Was wollte der Herr uns sagen?

Schauen wir uns zunächst den ersten Teil an, dass die Unterhaltungen mit Scrum Mastern früher denen mit Tech-Nerds entsprochen hätten. Die dahinterstehende implizite Aussage ist die, dass man bei hochspezialisierten (IT-)Technikern zwar niemals zur Gänze versteht, wovon sie eigentlich reden, dass daraus aber Ergebnisse entstehen, die immer wieder beeindruckend sind. Für die frühen Scrum Master und Agile Coaches (ca. zwischen 1995 und 2015) eine durchaus treffende Beschreibung.

Der zweite Teil, demzufolge sich die Gespäche heute wie solche mit HR anfühlen, ist weniger schmeichelhaft. In der breiten Wahrnehmung vieler Mitarbeiter hat die Arbeit der Personal-Einheiten zwar einen sinnvollen Kern, besteht aber darüber hinaus zu einem Grossteil aus dem Erzeugen von Regeln, Prozessen und Sprach-Vorgaben, deren Mehrwert nicht wirklich nachvollziehbar ist.¹ Und man muss es leider sagen - die Wahrnehmung vieler agiler Methodenmenschen ist nicht weit davon weg. Autsch.

Wer schon etwas Zeit mit oder in der agilen Community verbracht hat wird entsprechende Aussagen kennen: "Das ist nicht DevOps", "So formuliert man User Stories nicht", "Steht im Daily bitte auf", "Darüber sprechen wir erst in der Retrospektive", "Diese Daten darf ausserhalb des Teams niemand sehen", etc. Ähnlich wie bei den meisten HR-Bemühungen stecken dahinter gute Ideen, wahrgenommen wird es aber meistens als Bevormundung und Gängelung.

Ganz unabhängig davon, ob diese Sicht gerechtfertigt oder berechtigt ist - sie ist real, und findet sich in vielen Unternehmen explizit oder implizit bei den Mitarbeitern wieder. Und wenn diese Sicht einmal Mehrheitsmeinung ist, dann kann man darauf wetten, dass früher oder später jemand die Frage stellen wird, warum man diese Rollen denn braucht, wenn alles was man von denen mitbekommt, die Erzeugung von Regeln, Prozessen und Sprach-Vorgaben mit zweifelhaftem Mehrwert ist.

Alleine um die eigene berufliche Existenz zu sichern, sollten sich Scrum Master und Agile Coaches daher regelmässig fragen, ob das was sie tun von aussen als besserwisserisch, bevormundend und bürokratisch wahrgenommen werden könnte.² Und wenn das der Fall ist, dann ist damit ein Verbesserungspotential entdeckt, dessen Realisierung deutlich mehr bewirken kann als das dogmatische Bestehen auf bestimmten Prozessen und Begrifflichkeiten.

Bild: Unsplash / Miguel A. Amutio - Lizenz

Wenn von der Gruppe aller Menschen die Rede ist, die in irgendeiner Form agil arbeiten (oder denen das zumindest zugeschrieben wird) fallen häufig Begriffe wie "die agile Bewegung" oder "die agile Community". Was damit genau gemeint ist bleibt in der Regel offen, was aber keineswegs bedeutet, dass diese Gruppe nicht beschreibbar wäre. Tatsächlich gibt es in der Wissenschaft sogar eine ganze Kategorie sozialer Zusammenschlüsse, die hier passend ist: die der sozialen Bewegungen.

Ein wichtiges Merkmal an dem soziale Bewegungen erkennbar sind, sind übergeordnete, gesellschafts-verändernde oder gesellschafts-stabilisierende Ziele. Das ist offensichtlich bei Bürgerrechts- oder Umweltbewegungen, kann aber auch in Berufskontexten stattfinden. Hier ist die agile Bewegung neben New Work sogar eine der Wichtigsten. Ihr aus dem agilen Manifest abgeleitetes grosses Ziel: die Schaffung einer besseren, humaneren, nachhaltigeren und effektiveren Arbeitswelt.

Was soziale Bewegungen ausserdem von anderen Gruppen unterscheidet, ist die nur schwer überprüfbare Zugehörigkeit. Weder wird man in sie hineingeboren (wie in Familien oder Stämme) noch gibt es klar formalisierte Zugehörigkeits-Kriterien und Aufnahmebedingungen (wie in Unternehmen oder Vereinen). Was es stattdessen gibt sind Selbst- oder Fremdzuordnungen, die sich auch widersprechen können. Man denke z.B. an die Debatten, oder SAFe und OKRs agile Frameworks sind oder nicht.

Eine Folge dieser nicht-formalen Zugehörigkeit ist das weitgehende Fehlen von Macht-Mitteln und Ressourcen-Kontrolle. Bis zu einem gewissen Grad ergeben die sich zwar indirekt aus charismatischer Führung, bzw. der sich daraus ergebenden Gefolgschaft, es gibt aber keine Budgets, keine Karrierepfade und keine bei Fehlverhalten drohenden Konsequenzen. Das ist auch ein Hauptgrund für den in sozialen Bewegungen verbreiteten Idealismus, der als Motivator an die Stelle materieller Anreize tritt.

Dieser unklare und von materiellen Zielen getrennte Status wird allerdings weiter verkompliziert durch das Phänomen, dass es mit der Zeit zu Formalisierungen von Teilen sozialer Bewegungen kommen kann, die dann parallel zu den unformalisierten Teilen bestehen. Eines der bekanntesten Beispiele dürfte die Entstehung der grünen Parteien aus der Umweltbewegung sein, formalisierte Teile der agilen Bewegung sind u.a. die Agile Alliance oder die Scrum Alliance.

Diese letzten Beispiele zeigen auch ein Problem auf, dass soziale Bewegungen bekommen können, wenn sich Teile von ihnen formalisieren. Ob nur zur Finanzierung der eigenen Strukturen oder aufgrund einer Gewinnerzielungsabsicht - mit Formalisierung geht praktisch immer der ein Geldbedarf einher, der alleine aus Selbsterhaltungstrieb doch als materielles Ziel neben die ursprünglichen, idealistischen Ziele tritt - was von den nicht-formalisierten Teilen der Bewegung z.T. vehement abgelehnt wird.

Verstärkt werden derartige Konflikte durch ein weiteres Phänomen, den so genannten Sog der Addition. Er tritt auf, wenn ähnliche soziale Bewegungen gemeinsame Teilziele verfolgen und sich dadurch teilweise überlagern. Sobald diese Überlagerung eine kritische Masse überschreitet, werden auch ursprünglich nicht geteilte Ziele übernommen, im Fall weiter Teile der agilen Bewegung z.B. das Streben nach Basisdemokratie oder die Ablehnung von Shareholder Value-Orientierung.

Nochmal von einer anderen Seite betrachtet können Soziale Bewegungen derartige interne Konflikte aber besser bewältigen und kompensieren als stärker formalisierte Gruppen, zum Einen weil sie eben aufgrund der fehlenden Formalität und Ressoucenverteilung in einem weitgehend konsequenzfreien Raum operieren, zum Anderen weil ihre übergreifenden idealistischen gesellschaftlichen Ziele eine Bindekraft haben können, die grösser ist als die Zentrifugalkräfte der verschiedenen internen Interessen.