On Lean and Agility

verschiedenen Kundeneinsätzen.

Selbst wenn man denken sollte, nach über 15 Jahren in der Beratung hatte man so langsam alles gesehen - manchmal wird man doch überrascht. So war es bei mir vor kurzem während eines Termins mit einer anderen Beratung, die in einigen ihrer Kundeneinsätze eine ganz erstaunliche Erfolgs-Messgrösse hat: den Krankenstand. Und es handelt sich nicht etwa um eine Gesundheitsberatung, sondern um eine, die sich auf Kulturwandel-Programme spezialisiert hat.

Bei genauerem Nachdenken ist es aber (leider) nur folgerichtig, dass jemand auf die Idee kommt, körperliche Gesundheit und Unternehmenskultur zu verbinden, denn tatsächlich können bestimmte Arten der Unternehmenskultur so belastend sein, dass man von ihnen krank wird. Über die Jahre habe ich selber genug Beispiele dafür erleben dürfen (zum Glück nicht in der eigenen Firma, sondern auf  verschiedenen Kundeneinsätzen).

Die offensichtlichste Fall dürfte das sein, was man im Englischen die Hustle-Kultur nennt. In ihr werden Überstunden, Wochenendarbeit und Erreichbarkeit in den Ferien als etwas Positives gesehen und von den Mitarbeitern erwartet, nicht nur vom Management sondern auch von ihren jeweiligen Kollegen. Dass das das Risiko körperlicher Erschöpfung mit sich bringt ist offensichtlich, bis zum irgendwann folgenden Zusammenbruch.

Ähnlich gelagert ist die Helden-Kultur. In ihr Herrscht die Annahme vor, dass bestimmte Aufgaben nur von bestimmten Menschen erledigt werden können, in der Regel vom jeweils grössten Spezialisten des jeweiligen Sachgebiets. Weil die dann das Gefühl vermittelt bekommen (oder selbst haben) unersetzbar zu sein, opfern sie sich und ihre Freizeit wieder und wieder auf, auch hier bis zum irgendwann eintretenden Zusammenbruch.

Ein dritter und nochmal unschönerer Fall ist die Sklavenhalter-Kultur. In ihr hat ein Unternehmen (bzw. dessen Führung eine derartige Kontrolle über bestimmte Teile des Arbeitsmarktes oder bestimmte Karriereoptionen, dass sie es sich leisten können ihre Angestellten auszubeuten, in die Akkord-Arbeit zu treiben oder Ähnliches mit ihnen zu machen. Auch hier mit der irgendwann eintretenden Folge körperlicher Erschöpfung und daraus folgender Erkrankung.

Subtiler aber nicht weniger schlimm sind toxische Unternehmenskulturen. Getrieben von niederen Motiven (Neid, Vorurteilen, Sadismus, o.Ä.) behandeln sich die Mitarbeiter gegenseitig schlecht, sabotieren sich, verleumden sich oder tun sich ähnlich schlimme Dinge an. Die Folge davon ist weniger die körperliche Abstumpfung sondern eher die Entwicklung psychischer Leiden, die dann irgendwann in Form psychosomatischer Erkrankungen in Physische umschlagen können.

Zuletzt sind auch Kafkaeske Kulturen weiter verbreitet als man denken sollte. In ihnen sorgen Bürokratie und Regelfetischismus dafür, dass immer weniger Arbeitszeit sinnvoll verbracht wird und immer mehr in unnötige Termine, Prozesse und Dokumentationen fliesst. Das Resultat ist die Entfremdung der Menschen von ihrer Arbeit, bis zu dem Punkt an dem sie an permanenter Sinnlosigkeit geistig zerbrechen und Schaden nehmen.

All diese Varianten von Unternehmenskultur treiben auf ihre jeweilige Weise den Krankenstand hoch und in allen Fällen ist es folgerichtig so. dass ein Kulturwandel ihn (mit etwas zeitlichem Versatz) senken kann, wenn es ihm gelingt, die zugrundeliegenden Ursachen zu beheben. Wie das geschehen kann ist dann von Fall zu Fall anders, von der Abschaffung absurd sinnloser Regeln über das Herunterfahren der Arbeitslast bis zur Entlassung sadistischer Manager kann vieles helfen.

Eine externe Kulturwandel-Begleitung kann tatsächlich viel in diese Richtung bewegen, von der Identifikation von Ursachen, die aufgrund interner Betriebsblindheit gar nicht mehr auffallen, über die Analysen systemischer Zusammenhänge bis hin zur Kompetenz in Konfliktmoderation oder Beteiligungsformaten. Vieles davon könnten ich oder meine Kollegen sicher auch anbieten, und ich kann mich sogar auch an sinkende Krankmeldungen erinnern.

Was ich mich aber nur mit Überwindung trauen würde, ist diese zu einem Haupt-Erfolgskriterium meiner Arbeit zu machen, da wirken für mich zu viele Faktoren mit, die ich nur wenig oder gar nicht beeinflussen kann. Diese Zahl im Blick zu halten und über die Zeit zu verfolgen könnte aber eine gute Idee sein, im Rahmen von Kulturwandel-Initiativen ist sie mindestens ein starker Indikator, den man als einen von mehreren Inputs nutzen kann.

Zu den grossen Problemen der Softwareentwicklung gehört ihr hoher Abstraktionsgrad, der einfache Erklärungen und Visualisierungen unglaublich schwer macht. Angesichts dessen ist dieser Vortrag von Aubrey Chipman und Roberto Perez Alcolea etwas Besonderes, da in ihm selbst Fachbegriffe wie Direct/Transitive Dependencies und Artifact Observability sichtbar gemacht und lebhaft erklärt werden.

Was mich übrigens ursprünglich in dieses Video hineingezogen hat, ist der direkt am Beginn eingebrachte Spoiler "This is not an AI talk". Nichts gegen künstliche Intelligenz, die revolutioniert gerade die Softwareentwicklung. Aber in letzter Zeit waren mir die meisten Konferenzen zu Hype-getrieben und zu monothematisch. Es gibt genug andere spannende Themen, so wie dieses hier.

Es ist eine Traumvorstellung vieler Angestellter - ein Berufsleben ganz ohne Regelmeetings, fest definierte Prozesse oder sonstige einengende Strukturen. Eines in dem man "einfach nur arbeiten" kann. Und es gibt sogar Firmen, denen das anscheinend weitgehend gelungen ist, z.B. WhatsApp vor der Übernahme durch Facebook. Wie genau das ausgesehen hat kann man sich jetzt anhören, denn die damalige WhatsApp-Mitarbeiterin Jean Lee berichtet im Pragmatic Engineer Podcast davon.

Der erste, und vermutlich wichtigste, Punkt den man von ihr lernen kann ist, dass WhatsApp damals eine kleine Firma war, und sich bewusst entschieden hat, klein zu bleiben. Zum Zeitpunkt der Übernahme gab es 30 Angestellte, davon 20 in der Softwareentwicklung. Eine derartig überschaubare Gruppe ist natürlich viel einfacher ad hoc und auf Zuruf zu koordinieren. Um so klein bleiben zu können, wurde sogar bewusst auf zusätzliche Features und Marktsegmente verzichtet.

Im Zusammenhang damit stand, dass alle Firmenangehörigen jeden Tag in einem grossen gemeinsamen Büro sassen. In einem derartigen Setting ist jeder sofort erreichbar, man bekommt zwangsläufig mit was die anderen tun, und Informationen können schnell und beiläufig an der Kaffeemaschine oder im Aufzug ausgetauscht werden. Ein zusätzlicher Vorteil ist, dass Information Radiators wie digitale Displays oder Kanban Boards durchgehend für alle sichtbar sind.

Als nicht zu vernachlässigendes Element kommt dazu, dass es kaum funktionale Spezialisierungen gab. Wie Jean Lee berichtet, waren in der damaligen Firma WhatsApp die Manager (einschliesslich des CEO) gleichzeitig an der Softwareentwicklung beteiligt, während die eigentlichen Entwickler Crashkurse in den wirtschaftlichen Aspekten erhielten und auch alle Geschäftszahlen kannten. Es gab also keine organisatorischen Silos, die sich untereinander prozessual koordinieren mussten.

Zuletzt darf man nicht vergessen, dass WhatsApp damals erst wenige Jahre alt war, und ein sehr minimalistisches Produkt hatte (im Wesentlichen eine Messaging App, Features wie Video Calls, Channels, Stories und DesktopApp existierten noch nicht), es gab also vergleichsweise wenige Feature Requests, technische Schulden und Refactoring-Wünsche, die man in einem strukturierten Planungs- und Priorisierungsprozess hätte verhandeln und eskalieren müssen.

Ich habe bereits mit anderen Firmen vergleichbarer Grösse und Struktur arbeiten dürfen, und z.T. auch dort ein vergleichbares Minimum an Prozessen und Strukturen erleben dürfen, was aber in allen Fällen nur gut funktioniert hat, so lange die Produkte und Organisationen von überschaubarer Grösse und Kompliziertheit waren. Sobald Wachstum stattfand, kamen auch die Prozesse (und Vergleichbares passierte laut Jean Lee nach der Übernahme von WhatsApp durch Facebook).

Es bleibt also am ende eine gleichzeitig positive und negative Erkenntnis: Berufsleben ganz ohne Regelmeetings, fest definierte Prozesse oder sonstige einengende Strukturen ist möglich, vermutlich aber nur in sehr kleinen und jungen Unternehmen. Wer Wert darauf legt, wird also alle paar Jahre zu einem neugegründeten Startup wechseln müssen. Wer dagegen einen Job etwas länger behalten möchte, der wird schon bald um Prozesse nicht mehr herumkommen.

Dass viele "agile Methodiker" (Agile Coaches, Scrum Master, RTEs etc.) mit der Zeit eine eher negative Weltsicht entwickeln ist bedauerlich, aber erklärbar. Wer sich ständig mit dem Beseitigen von Impediments und dem Kampf gegen Change Fatigue, Overcompliance und Konzern-Trolle beschäftigen muss, kann leicht zynisch und sarkastisch werden. Um nicht selbst irgendwann so zu enden, möchte ich dagegenhalten, indem ich ab und zu selbst erlebte "agile Erfolgsgeschichten" veröffentliche.

Eine an der ich vor längerer Zeit beteiligt war betraf die Qualitätssicherung in einem grossen IT-Projekt. Die hier tätigen Tester galten in der allgemeinen Wahrnehmung als doppelt problematischer Schwachstelle: am Ende fast jedes Sprints wurden in den Entwicklungsteams die Tests der dort programmierten Features nicht mehr rechtzeitig fertig, und nach dem Sprintende waren die Regressionstests häufig zuerst grün, enthielten aber Wochen später plötzlich doch Fehlermeldungen.

Eine Analyse der Entwicklungsabläufe zeigte schnell zwei Hauptprobleme auf: zum Einen gab es in den Teams wasserfallartige Abläufe, in deren Rahmen die Entwickler lange unter sich arbeiteten, und die Tester erst kurz vor Sprintende erfuhren, was sie zu testen hatten (und das dann unter Zeitdruck tun mussten) zum Anderen hatte sich die übergreifende Regressionstest-Suite mit der Zeit selbst zu einem schwerfälligen Legacy-System entwickelt, dass nur noch aufwändig anzupassen war.

Dementsprechend wurden drei Verbesserungsmassnahmen durchgeführt. Zuerst wurden die Tester früher in die Abläufe ihrer Teams integriert. In den Backlog Refinements wurden sie daran beteiligt, die Akzeptanzkriterien testbar zu verfassen statt abstrakt, ihre Testaufwände wurden stärker in den Aufwandsschätzungen berücksichtigt und beim Planen der Sprints wurden Grösse, Auswahl und Anzahl der Entwicklungs-Aufgaben so vorgenommen, dass am Ende genug Zeit zum Testen blieb.

Als zweite Massnahme erfolgte eine stärkere Einbeziehung der Software-Entwickler in die QA-Abläufe. Wie oben geschrieben hatten die bis dahin das Testen als ein nachgelagertes Thema gesehen, das sie selber nicht mehr betraf. In dem verbesserten Vorgehen wurde dagegen eine Testpyramide angestrebt (siehe hier), in der bestimmte Mengen an (von den Entwicklern erstellten) Unit-, Integrations- und Lasttests zu einem Abnahmekriterium wurden, was das Testen am Sprintende deutlich beschleunigte.

Als Drittes wurde eine Überarbeitung der Regressionstest-Suite vorgenommen, die zu einem eigenen Problem geworden war. Bis dahin war sie einfach nach jedem Sprint um weitere Tests erweitert worden, während die bestehenden nur angepasst wurden, wenn (und nur dort wo) es Änderungen an den getesteten Funktionen gegeben hatte. Aufgrunddessen waren viele Tests redundant, kompliziert und unübersichtlich, was Anpassungen extrem aufwändig machte.

Um das zu verbessern wurde die Testsuite modularisiert und parametrisiert. Das Eine bedeutete, dass bestimmte Validierungen (z.B. des Login) nicht mehr in verschiedenen Tests enthalten waren, sondern nur noch in einem einzigen Modul, das dafür in beliebig viele Tests eingebunden werden konnte. Das Andere bedeutete, dass bestimmte variable Informationen (Browser, Ordnerpfade, etc.) nicht mehr hart im Test standen, sondern an einer zentralen Stelle systemweit geändert werden konnten.

In Summe führten diese verschiedenen Massnahmen dazu, dass die zu Beginn genannten Probleme fast völlig verschwanden. Die Tests (und mit ihnen die neuen Features) wurden in den Sprints fertig, in denen sie auch programmiert wurden, und die Aktualisierung der Regressionstests benötigte nur noch die Arbeit an einzelnen Modulen oder Parametern, statt an zig Stellen, wodurch versehentliche Seitenauswirkungen der neuen Features sofort gefunden werden konnten, statt Wochen später.

Am Ende ist es eine Binsenweisheit: eine Kette ist nur so stark wie ihr schwächstes Glied, und in vielen Softwareentwicklungs-Organisationen ist dieses schwächste Glied die Qualitätssicherung. Auch hier die agilen Praktiken einzuführen, und zwar sowohl technisch als auch prozessual, ist etwas, wovon alle Beteiligten massiv profitieren können.

Bild: Pexels / Ekam Juneja - Lizenz

Mike Fisher: Twitching Before You Sprint

Steve Blank: Your Startup Is Probably Dead On Arrival

Christina Wodtke: Everyone on Your Team Is Right (And That’s the Problem)

Doc Norton: This Has Happened Before. It's Happening Again.

Jannik Reigl: What if Germany isn’t very good at research?

In der englischen Sprache gibt es die schöne Firur des Razors (Rasiermessers) mit dem ein Vorgehen bezeichnet wird, bei dem man überflüssige oder verwirrende Elemente von einer Überlegung "abrasiert" werden. Das was danach übrigbleibt soll klarer und verständlicher sein als der Ausgangszustand. Der Bekannteste ist vermutlich Occam's Razor ("The simplest explanation is usually the best one."), es gibt aber auch weitere, wie zum Beispiel diesen hier.

Cockburn's Razor ist benannt nach Alistair Cockburn, einem der initialen Unterzeichner des Manifests für agile Softwareentwicklung. Wann genau er entstanden ist lässt sich nicht mehr genau zurückverfolgen, es wird aber vermutlich irgendwann nach Mitte der 90er Jahre gewesen sein, da Cockburn erst ab dieser Zeit einen Bekanntheitsgrad hatte, der es möglich machte, seinen Namen für die Popularisierung von Vorgehensmodellen zu benutzen. Er lautet:

Don't add stept to process until you need them
Delete steps from process as soon as you can
Apply this to every file, every process doc, every CSV Column
If it doesn't serve Ring 0 right now, archive it or delete it

Alistair Cockburn, Cockburn's Razor

Diese Faustregel wirkt auf den ersten Blick eingängig, da sie ein einfacher Weg ist, um sowohl soziale als auch technische Prozesse schlank zu halten, sie ist aber in vielen Organisationen nur schwer umzusetzen. Der Hauptgrund dafür ist der vor allem in grösseren Einheiten stark verbreitete Wunsch, möglichst viel Standardisierung, Vergleichbarkeit und Stabilität zu haben, welcher wiederum auf der Hoffnung beruht, dadurch die Transparenz und Steuerungsfähigkeit zu erhalten.

Selbst wenn es gelingen sollte, diese Quelle ständig nachwachsender Bürokratie zu neutralisieren, bleiben aber ggf. noch Probleme in der individuellen Dimension. Vor allem auf den unteren Ebenen einer Organisation gibt es Menschen, die eine kategorische Ablehnung gegen Prozesse und Meetings jeglicher Art entwickelt haben (siehe hier) und sie darum grundsätzlich alle abrasieren wollen - selbst dann, wenn sie einen sinnvollen Zweck haben. Die müssen überzeugt oder überstimmt werden.

Die Umsetzung von Cockburn's Razor erfordert daher nicht nur ein ständiges Überprüfen und Anpassen, sondern in der Realität auch ein kontinuierliches Informieren, informiert Werden, Überzeugen und Aushandeln. Es ist also keine leichte und eindeutige Lösung, trotzdem aber eine die besser für die Verschlankung und Schlankhaltung von Prozessen geeignet ist als die meisten anderen.

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.