On Lean and Agility

Es gibt Begrifflichkeiten, die man irgendwann benutzt ohne gross darüber nachzudenken. Im IT-Projektmanagement gehört dazu das Gegensatzpaar Greenfield und Brownfield, welches vereinfacht gesagt für Neuentwicklungen und Weiterentwicklungen von Systemen steht. Wie ich vor kurzem erfahren habe, gibt es aber auch noch eine dritte, bisher neue Kategorie - die des Blackfield, wobei ausgerechnet die in meinem Umfeld relativ häufig ist.

Alle drei sind Teile der metaphorischen Sprache, einer alten, durch das Extreme Programming popularisierten Praktik des Software-Projektmanagement, bei der man komplexe Sachverhalte dadurch nachvollziehbar macht, dass man für ihre Beschreibung Worte des alltäglichen Lebens benutzt. Da die drei "Feldtypen" jeweils typische Ausgangslagen von Entwicklungsprojekten beschreiben, lohnt es sich, sie zu kennen. Hier sind sie:

Greenfield

Zu Greenfield gibt es in der deutschen Sprache sogar eine Entsprechung, nämlich das Beginnen eines Vorhabens "auf der grünen Wiese", wo vorher noch nichts war. Das bedeutet keine bestehenden Strukturen und Architekturen, keine technischen Schulden und keine hohen Betriebsaufwände, auf der anderen Seite aber auch keine Bestandskunden und kein bereits existierendes Business Model. Wenig überraschend: Entwickler lieben Greenfield, Manager sind eher Misstrauisch ihnen gegenüber.

Brownfield

Ohne dass es eine gebräuchliche deutsche Übersetzung gibt, kann man sich Brownfield-Projekte wie Vorhaben auf einem schlammigem Acker vorstellen, in dem die Reste vergangener Vorhaben versunken oder untergepflügt sind. Bestehende Strukturen, Architekturen und technische Schulden (und Business Models) gibt es hier mehr als genug, weshalb alle weiteren Schritte mit etwas "Archäologie" beginnen müssen, um zu verstehen auf was für Fundamente man aufbaut und in welchem Zustand diese sind.

Blackfield

Blackfield ist die neue, mir bisher noch unbekannte Analogie. Um beim Bild zu bleiben: man steht hier auf verbrannter Erde. Gescheiterte Ablöseprojekte, abgebrochene Weiterentwicklungen, hastige Notlösungen und nicht dokumentierte Hotfixes haben ein fragiles Trümmerfeld zurückgelassen, auf dem selbst kleine Veränderungen zu Destabilisierungen und Zusammenbrüchen führen können, die umfangreiche (und teure) Stütz- und Reparaturmassnahmen notwendig machen.

Was vielen nicht bewusst ist: in grösseren und älteren Organisationen (Banken, Behörden, etc.) sind Brownfield-Umgebungen der Normalfall und Blackfield-Umgebungen keine Seltenheit, da IT-Systeme hier z.T. seit Jahrzehnten unter hohem Spardruck entwickelt wurden. Das hat zur Folge, dass bei jedem neuen Vorhaben mit ungeplanten Mehrarbeiten von nicht genau vorhersagbarem Umfang zu rechnen ist, im Extremfall bis hin zu einer Vervielfachung des ursprünglich angenommenen Arbeitsaufwandes.

Um nicht in diese Situation zu geraten, macht es Sinn, die alten Relikte und Ruinen von Zeit zu Zeit zu abzureissen, den Untergrund wieder zu verfestigen und schädliche Rückstände zu entsorgen. Refactoring, wie man in der Softwareentwicklung sagt. Um die Metapher auf die Spitze zu treiben: dabei kann ein Revierpark entstehen, also eine renaturisierte Industriebrache, auf der dann wieder erneut mit einem Greenfield-Ansatz begonnen werden kann.

Grafik: CCNull / Marco Verch - CC BY 2.0

Beim Lesen von David Epsteins Buch Range sind verschiedene Konzepte aus meinem Psychologie-Studium wieder emporgestiegen, unter anderem die Prozeduralen und Konzeptionellen Probleme, bzw. der zu ihrer Lösung notwendigen Wissensgebiete des Prozeduralen und Konzeptionellen Wissens. Es handelt sich dabei um universell anwendbare Ansätze, die aber in meinem beruflichen Umfeld noch einmal besondere Implikationen haben.

Prozedurales Wissen (umgangssprachlich auch als Know-How bezeichnet) umfasst Informationen, die unmittelbar anwendbar sind, seien es mathematische Rechenwege, Navigationsanweisungen oder Kochrezepte. Die Prozeduralen Probleme, für deren Lösung sie gedacht sind, treten regelmässig und in immer vergleichbarer Form auf, so dass die Problemlösung im Wesentlichen aus der Wiederholung früherer Lösungen bestehen kann.

Konzeptionelles Wissen umfasst dagegen Informationen über abstrakte aber universell gültige Wirkungszusammenhänge, etwa Grundrechenarten, die Bedeutung von Strassenschild-Formen und die geschmacklichen und chemischen Eigenheiten und (In)Kompatibilitäten von Kochzutaten. Die Konzeptionellen Probleme, für deren Lösung sie gedacht sind, sind komplex, dynamisch oder neuartig, so dass die Problemlösung jeweils neu gefunden und validiert werden muss.

In der Welt der Organisation von Arbeitsabläufen lassen sich diese beiden Wissensgebiete im Wesentlichen auf zwei bekannte Vorgehensmodelle mappen: Prozedurales Wissen findet sich vor allem im Lean Management, mit dem Fertigungsstrassen, Callcenter und ähnliche Einrichtungen optimiert werden können, während sich Konzeptionelles Wissen vor allem in agilen Arbeitsweisen wiederfindet, die in Produkt-Neuentwicklungen innovative Wege finden müssen.

Was Epstein nun in seinem Buch schreibt (und durch wissenschaftliche Studien belegt) ist aber, dass die Menschen eine grundsätzliche Neigung zu Prozeduralem Wissen haben, da es einfache Verständlichkeit, sofort nachvollziehbare Lösungswege und schnelle Fortschritte ermöglicht. Diese verzerrten Präferenzen gehen so weit, dass oft selbst bei der Lösung Konzeptioneller Probleme versucht wird, diese mit Prozeduralem Wissen zu lösen - selbst dann, wenn das gar keinen Sinn macht.

Auf die moderne Arbeitswelt übertragen: selbst für die Lösung neuartiger Probleme, für die eigentlich Systems Thinking, Mustererkennung, Inspect & Adapt und ähnliche abstrakte Ansätze die Richtigen wären, versuchen viele Menschen und Organisationen zunächst reflexartig auf Best Practices, Industrie-Standards, Playbooks und ähnliche Anleitungen zurückzugreifen. Das Scheitern vieler digitalen, agilen und sonstigen Transformationen dürfte darin begründet sein.

Um noch tiefer zu bohren: auch den Grund für die Bevorzugung Prozeduralen Wissens fasst Epstein zusammen, und es ist auch ein ganz einfacher - im Gegensatz zum anspruchsvolleren und vergleichsweise schwer zu durchdringenden Konzeptionellen Wissen erfordert das Prozedurale Wissen weniger gedankliche Anstrengung und weniger Lernaufwand. Dass es bevorzugt wird, liegt also schlicht an der geistigen Bequemlichkeit vieler Menschen.

Für das Innovations- und Change Management beutet das, dass seine Vertreter bereit sein müssen, auch als unbequem wahrgenommen zu werden, zumindest so lange bis im jeweiligen Einzelfall beweisbar ist, dass Konzeptionelles Wissen auch tatsächlich der passende Weg zur Lösung Konzeptioneller Probleme ist. Und als Schlusspointe: auch die Kategorisierung von Wissen und Problemen in Konzeptionell und Prozedural ist Konzeptionelles Wissen. Hilfreich, aber nicht für jeden sofort zugänglich.

Was wäre die Welt ohne KI? Zumindest wäre sie ärmer an Liedern wie diesem hier, das herrlich durchgeknallt die Zuneigung eines Softwareentwicklers zu seinem (in agilen Methoden bewanderten) Projektmanager besingt.

Und als wäre das nicht bereits genug, sind im Text ausserdem noch zahlreiche IT-Fachbegriffe untergebracht. Ein wahres Nerd-Feuerwerk.

Manche Erkenntnisse hat man unbewusst bereits seit langem, man muss aber einmal darauf hingewiesen werden, damit sie es explizit ins Bewusstsein schaffen. Einen derartigen Aha-Effekt habe ich vor kurzem während des Auftritts der Psychologin Rebecca Hinds im Unsiloed Podcast gehabt, in dem sie ein verbreitetes Problem auf den Punkt brachte: die meisten Menschen werden unbewusst darauf konditioniert Meetings schlimm zu finden und abzulehnen.

Die Art auf die das stattfindet dürfte jeder schon irgendwann erlebt haben. Wenn (aus welchem Grund auch immer) das Gespräch auf das Thema Meetings kommt, werden Augen verdreht und es wird gestöhnt. Nur noch Meetings habe man im Kalender, heisst es dann in der Regel, man käme zu nichts anderem mehr. Und sinnlos seien sie auch, eine einzige Zeitverschwendung. Und früher oder später kommt der Spruch, dass statt des Meetings auch eine Email gereicht hätte, darauf kann man wetten.

Natürlich sind diese Klagen in dieser Absolutheit nicht gerechtfertigt. Es ist zwar sicher ein grosser Teil aller Meetings hinterfragbar, viele haben aber einen sinnvollen oder sogar unverzichtbaren Zweck (mehr dazu hier). Was aber durch die Dauerbeschwerden entsteht, ist schlimmstenfalls sogar ein starker Konformitätsdruck, Meetings in der Öffentlichkeit ebenfalls kategorisch schlecht zu finden - selbst wenn man das selbst gar nicht so sieht.

Rebecca Hinds stellte im Podcast dazu ein bemerkenswertes Forschungsergebnis vor: wenn Personen sowohl einzeln als auch Gruppen gefragt wurden, was sie von Meetings hielten, gingen die Antworten deutlich auseinander. In der Gruppe waren die Bewertungen signifikant negativer als in Einzelbefragungen, was ein klarer Indikator dafür ist, dass diese Aussagen nicht auf Fakten zurückzuführen waren, sondern auf die (angenommenen) Erwartungshaltungen der Gruppe.

Um das Ganze ins Positive zu drehen: wenn die weit verbreitete und für die Zusammenarbeit letztendlich schädliche übertriebene Ablehnung von Meetings jeglicher Art im Wesentlichen auf fehlgeleitete Gruppendynamiken zurückgeht, dann können wir selbst dafür sorgen, dass sich diese Dynamiken umdrehen. Das Einzige was wird dafür tun müssen ist, positiv über Meetings zu reden, selbst wenn uns das aus den genannten Gründen zu Beginn schwerfällt.

Das heisst natürlich nicht, dass die zweifellos in vielen Meetings vorhandenen Missstände beschönigt oder verschwiegen werden sollen. Es heisst aber, dass durch ein Gegenüberstellen der unzweifelhaft ebenfalls vorhandenen sinnvollen Effekte ein differenziertes Bild entsteht, und dass es auch den anderen Gruppenmitgliedern ermöglicht wird, dieses differenzierte Bild zu haben oder zurückzugewinnen. In diesem Sinne: Make Meetings great again!

Nochmal zum Thema Cost of Delay, also zu den Verzögerungskosten, die auftreten, wenn ein Produkt oder Feature zu langsam fertig wird. Diese Kosten werden gemessen in (ungefähren) Geldbeträgen, die verpassten oder verzögerten Gewinnen entsprechen. Auf den ersten Blick erscheint das Zwangsläufig und nicht weiter erwähnenswert, bei näherer Betrachtung ist darin aber eine eigentlich offensichtliche Implikationen enthalten, die aber manchmal vergessen wird.

Um Verspätungskosten finanziell messen oder schätzen zu können, ist etwas ganz Grundlegendes nötig: ein Business Case des Produkts oder Features nämlich, für das diese Kosten ermittelt werden sollen. Das ist in vielen Fällen auch gut möglich, etwa bei neuen Autos oder Computerspielen, bei neuen Funktionen komplexer und abstrakter Produkten wie z.B. Betriebssystemen oder Online-Portalen ist es dagegen deutlich schwieriger und ggf. sogar unmöglich.

Noch am Einfachsten ist es in Fällen, in denen diese Funktionen kostenpflichtig gekauft oder abonniert werden können. In derartigen Konstellationen lassen sich nach Fertigstellung die Gewinne rückwirkend auf die "verpassten" Monate übertragen, oder alternativ kann bereits während der Planung von einem voraussichtlichen Gewinn ausgegangen werden, dessen drohendes Verpassen ggf. kurzfristige Mehraufwände rechtfertigen kann.

Schwieriger wird es, wenn neu erstellte Features nicht separat monetarisierbar sind. Ein Umweg den man hier gehen kann, ist der über die Marktforschung: wenn eine Neuerung ein Differenzierungsmerkmal ist (oder ein Differenzierungsmerkmal eines Wettbewerbers egalisiert) kann man annehmen, dass Umsätze (und damit Gewinne) ganz oder teilweise auf sie zurückzuführen sind, was sich dann annäherungsweise in Geld quantifizieren lässt.

Praktisch unmöglich wird die Ermittlung von Cost of Delay, wenn die jeweilige Funktionalität weder separat vermarktet wird, noch von Kunden als Differenzierungsmerkmal wahrgenommen wird (oder überhaupt separat wahrgenommen wird). Ein internes Diagnose-Programm wäre ein Beispiel dafür. Natürlich ist es aus Produktsicht sinnvoll und mehrwertstiftend, es ist aber nichts, das man einem Kunden in Rechnung stellen oder ihm gegenüber vermarkten könnte.

Für derartige Funktionen ist eine separate Ermittlung von Verspätungskosten schlicht nicht machbar, was eigentlich auch kein Problem ist - schliesslich müssen sie nicht zwanghaft für jedes Feature gemessen werden. Entweder fallen sie ganz aus derartigen Betrachtungen heraus, oder sie entsprechen der kompletten Verspätungskostensumme des Gesamtprodukts - dann nämlich, wenn dieses ohne die einzelne Funktion nicht verkauft werden kann oder darf.

Der Vollständigkeit halber: Wird in überregulierten Umgebungen versucht, eine kategorische Anwendung dort zu erzwingen, wo das eigentlich nicht geht, ist meistens Cargo Cult die Folge. Dann kann es z.B. sein, dass für Funktionen ohne Business Case einer "nach Bauchgefühl" ermittelt wird, z.B. mit Planning Poker. Diesen Wert kann man dann in die Dokumentation schreiben um den Vorganben gerecht zu werden, es ist aber nicht mehr als Business-Theater, das man auch sein lassen kann.

 Eines der folgenschwersten Missverständnisse der Softwareentwicklung ist, dass die Rolle des Architekten eine rein technische ist. Ich glaube, dass es sich um eine zutiefst soziale Rolle handelt, eine bei der man sowohl in der Lage sein muss, komplexe Inhalte an Andere zu vermitteln, als auch zu extrahieren, was Andere meinen, wenn sie bestimmte Schlagworte benutzen. Kevlin Henney gelingt hier beides gleichzeitig.

Was er ausserdem dankenswerterweise herausstreicht ist, dass diese Rolle Geduld und Nachsicht erfordert. Sein André Gide-Zitat bringt es auf den Punkt: "Alles wurde bereits gesagt, aber da niemand zuhört müssen wir es ständig wiederholen." Ein Architekt der dazu nicht bereit ist, wird es schwer haben seinen Job gut auszuüben. Im übrigen eine bemerkenswerte Parallele zu allen Methodiker-Berufen.

Ein kurzer Ausflug auf die Meta-Ebene. Sowohl die Entwicklung von Software als auch die Fertigung von Hardware-Produkten finden im Überschneidungsbereich von zwei Systemen statt: einem sozialen System, bestehend aus den beteiligten Menschen und den zwischen ihnen stattfindenden Interaktionen und einem technischen System, bestehend aus verschiedenen miteinander verbundenen Geräten und IT-Programmen. Beide zusammen bilden dann so genannte Soziotechnische Systeme.

Das soziale (Teil-)System bilden im engeren Sinn alle an der Produkterzeugung beteiligten Menschen, egal ob sie planen, konzipieren, programmieren, montieren, testen, dokumentieren, absichern oder sonstige Tätigkeiten durchführen. Im weiteren Sinn können noch weitere Gruppen dazugehören, etwa Anwender, Auftraggeber oder Regulierer. In beiden Fällen bestehen diese Systeme aber nicht nur aus den beteiligten Menschen, sondern auch aus den sie verbindenden Interaktionen (z.B. der Kommunikation).

Das technische (Teil-)System hat ebenfall zwei Dimensionen: zunächst umfasst es alle Werkzeuge, die von den Angehörigen der sozialen Systeme benutzt werden; im Fall der Software-Programmierung etwa Computer und Build Pipelines, im Fall der Hardware-Fertigung können es Fliessbänder und Stanz-Maschinen sein. Als zweite Dimension kommen Elemente dazu, die die beteiligten Menschen steuern und anleiten, z.B. Ticket-Tools oder akkustische Signale, die auf durchzuführende Tätigkeiten hinweisen.

Aufbauend darauf kann man diskutieren, ob in letzter Konsequenz nicht alle Arbeit in soziotechnischen Systemen stattfindet (selbst in der Manufaktur gibt es Werkzeuge und selbst einen Vollautomaten muss irgendjemand anschalten), es gibt aber Vorgehensweisen, die zwingend soziotechnisch sind - die, bei denen es um hohe Reaktions- oder Liefer-Geschwindigkeit geht (Agile und Lean), wären ohne Automatisierung einfacher Arbeiten und menschliche Eingriffe bei Technikversagen schlicht zu langsam.

Und um auch das noch stärker herauszustreichen: hohe Reaktions- oder Liefer-Geschwindigkeit kann in vielen Fällen bedeuten, dass die Abläufe im Wortsinn rasend schnell werden, etwa dann, wenn in einer Lean-optimierten Fabrik pro Minute hunderte von Nägeln oder Bleistiften erzeugt werden oder neue Software in Sekunden auf tausende Geräte geladen wird. Es kann aber auch bedeuten, dass die Anfertigung einzelner Prototypen "nur noch" Wochen dauert, statt Jahre (siehe hier).

Zu guter Letzt: wenn man sich darauf einlässt, dass nach Agile, Lean oder verwandten Ansätzen arbeitende Organisationen soziotechnische Systeme sind, erledigen sich auch auch schnell die Diskussionen, ob sie aufgrund des technischen Fortschritts nicht obsolet werden. Agiles Arbeiten kann genauso wenig durch Künstliche Intelligenz abgelöst werden wie Lean durch 3D-Druck, denn das sind lediglich technische (Teil-)Systeme. Was dagegen möglich ist, ist diese in Agile und Lean zu integrieren.

Bild: Pexels / Ekam Juneja - Lizenz

Jim Highsmith: The Agile Manifesto at 25

Jeff Gothelf: Technical systems will continue to succumb to culture

Braden Kelley: Three Myths That Kill Change and Transformation

Liam Kane: When Work Ages - Block It or Remove It from WIP?

Lorin Hochstein: Poor Deming never stood a chance