On Lean and Agility

Bild: Unsplash / Tom Hermans - Lizenz

"Das ist doch nur wieder eine Management-Mode, die ist bald wieder vorbei." Praktisch jeder, der an Veränderungsvorhaben in grossen Organisationen beteiligt war, wird diese Aussage schon einmal gehört haben, egal ob es im Einzelfall um Digitalisierung, Lean, Agile, KI oder ein sonstiges Thema geht. Woran zu erkennen ist, ob es sich wirklich um eine Mode handelt, und was der beste Umgang damit ist, bleibt allerdings in den meisten Fällen unklar.

Dankenswerterweise gibt es allerdings neben diesen Bauchgefühl-Aussagen auch wissenschaftliche Auseinandersetzungen mit diesem Thema, unter anderem in Form des empfehlens- und lesenswerten Buchs Managementmoden nutzen (Eine sehr kurze Einführung) von Stefan Kühl, einem Soziologie-Professor der Universität Bielefeld, der schon seit längerem die Funktionsweisen grosser Unternehmen und sonstiger Organisationen untersucht.

Der erste und offensichtlichste Mehrwert dieses Werkes ist, dass in ihm definiert wird, was eine Management-Mode überhaupt ist, nämlich eine aktuell populäre Vorstellung darüber, wie Firmen, Behörden, etc. organisiert werden können, häufig verbunden mit Annahmen, dass sie auch die aktuell bestmögliche Antwort auf die Herausforderungen einer Gegenwart ist, von der vergangene Management-Konzepte noch nichts wissen konnten, und auf die sie daher nicht vorbereitet sind.

Darüber hinaus ordnet Kühl auch ein, warum derartige Moden für viele Manager so anziehend sind, angefangen von der scheinbar universellen Anwendbarkeit über die Lieferung einfacher Antworten auf komplexe Probleme bis hin zu einer mitgelieferten Legitimation durch eine auf den ersten Blick wissenschaftlich scheinende Fundierung und eine häufige Einbettung in idealistische, weit über die Gewinnoptimierung hinausgehende Ziele (Fortschritt, Nachhaltigkeit, Humanismus, etc).

Neben diesen eher theoretischen Erwägungen bietet das Buch aber auch eine konkrete Anwendbarkeit für Praktiker. Wie sein Titel erkennen lässt liefert es auch Ansätze zur Nutzung von Management-Moden in Veränderungsprozessen. So kann man zum Beispiel erkennen, wie sich durch ihren gezielten Einsatz Veränderungsbereitschaft steigern lässt oder wie man ein Vorhaben, dass man schon seit langem plant, in Moden-getriebenen Programmen unterbringen kann.

Passend für die zeitlich stark verplanten Angehörigen grosser Organisationen ist Managementmoden nutzen (Eine sehr kurze Einführung) auch tatsächlich von überschaubarer Länge. Ohne Inhalts- und Lieraturverzeichnis hat es gerade einmal 80 Seiten, lässt sich also relativ schnell durchlesen. Und für alle, die sich des Lesens von Büchern entwöhnt haben, ist Kühls Buch auch Gegenstand der aktuellen Staffel seines Podcasts Der ganz formale Wahnsinn, in dem man sich alles auch anhören kann.

Mit sichtbarer Zufriedenheit stellte sich der Geschäftsführer Wirtsrat vor seine Belegschaft. Viele Themen wollte er anlässlich der Frühjahrstagung seiner Organisation ansprechen, aber eines ganz besonders und zuerst: seine Freude darüber, dass die Sachbearbeiter jetzt endlich die Vorteile des im letzten Jahr angeschafften teuren neuen CRM-System akzeptierten und seine intelligenten Funktionen benutzten. Er hatte keine Ahnung, wie es sich in Wirklichkeit verhielt.

Ich habe den Geschäftsführer Wirtsrat (der in Wirklichkeit anders hiess) vor langer Zeit in einem meiner ersten Jobs kennengelernt. Er war ein eher klassisch sozialisierter und denkender Vorgesetzter, der überzeugt war, dass zu viel Transparenz und Mitsprache Entscheidungen nur verzögern würden. Aus diesem Grund hatte er das besagte CRM-System auch alleine ausgewählt und gekauft, ohne vorher mit denen zu reden, die es später benutzen würden. Er wusste schliesslich, was gut war.

Die Anwender hatten eine ganz andere Meinung. An sich fanden sie das System ähnlich gut wie das alte, nur eine Funktion fanden sie extrem nervtötend: beim Öffnen jeder einzelnen Ebene des zentralen Ordnerbaums erfolgte ein Ladevorgang von mehreren Sekunden, während denen die "intelligenten Funktionen" geladen wurden - Hilfs- und Hinweis-Funktionen, die sich alle etwa auf dem Niveau von Karl Klammer bewegten: gut gemeint, aber schon nach Kurzem sehr nervig.

Der eigentliche schlimme Nervfaktor war aber ein anderer: es waren die Ladevorgänge, die sich bei tieferen Ordnerbäumen auf bis zu einer halben Minute summieren konnten. Ständig hörte man im Büro fluchende Mitarbeiter, die ewig darauf warteten, endlich bei der Zielebene anzukommen. Der Geschäftsführer Wirtsrat hielt allerdings starr an seiner Meinung fest: die intelligenten Funktionen wären eine wertvolle Hilfe und das neue CRM wäre deswegen gut.

Auch ich war schon nach kurzem von den langen Ladezeiten genervt, und besonders an einem Morgen dauerte alles gefühlt doppelt so lange wie sonst. Ohne gross darüber nachzudenken überbrückte ich die Zeit durch schnelles, ununterbrochenes Klicken auf den Apply-Button, als auf einmal etwas Unerwartetes geschah - eine Systemmeldung tauchte auf und zeigte an, dass das System wegen zu vieler Eingaben überlastet war, weswegen die intelligenten Funktionen temporär ausgeschaltet würden.

Auf einmal waren die Ladezeiten weg. Mit ihnen zwar auch die Hilfsfunktionen, aber die waren wie gesagt ohnehin verzichtbar. Nach dem Neustart war zwar alles wieder da, aber nach kurzem Ausprobieren stellte sich heraus, dass man mit erneuten Dauerklicken die Hilfsfunktionen wieder vorübergehend deaktivieren konnte. Schon nach kurzem hatte sich der Trick herumgesprochen, und der Arbeitstag fast aller Kollegen begann mit schnellem Klicken, gefolgt von zufriedenen Seufzern.

Dem Geschäftsführer Wirtsrat hat während meiner Zeit in seiner Organisation niemand gesagt, dass praktisch jeder Mitarbeiter an jedem Morgen als erstes die intelligenten Funktionen deaktivierte, um während des restlichen Tages produktiv arbeiten zu können. Er hielt die plötzlich stark zurückgehenden Beschwerden für ein Zeichen von Akzeptanz, weshalb es diese auch stolz auf der zu Beginn erwähnten Frühjahrstagung vor allen Mitarbeitern erwähnte. Die Mitarbeiter grinsten und schwiegen.

Natürlich war das ein Extremfall, in verschiedenen Abwandlungen findet man derartige Funktionen und Manager aber in vielen, vielen Organisationen. Und für mich ist dieses Erlebnis, bei dem für viel Geld ein neues System angeschafft wurde, das praktisch alle Mitarbeiter so nervte, dass sie es täglich durch destruktives Nutzerverhalten deaktivierten, ein prägendes gewesen. Davon, ein neues System zwangsweise, ohne Einbeziehung der Nutzer einzuführen, habe ich seitdem immer abgeraten.

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?