Kommentierte Links (CXI)

Grafik: Pixabay / Geralt - Lizenz

Das Internet ist voll von Menschen, die interessante, tiefgründige oder aus anderen Gründen lesenswerte Artikel schreiben. Viele dieser Texte landen bei mir, wo sie als „Food for Thought“ dazu beitragen, dass auch mir die Themen nicht ausgehen. Wie am Ende jedes Monats gibt es auch diesesmal wieder eine kommentierte Übersicht über die erwähnenswertesten.

Jenny Fernandez, Kathryn Landis, Julie Lee: Why Collaboration Is Critical in Uncertain Times

Obwohl es in diesem Artikel mehrerer Autoren des Harvard Business Review um das Thema der Zusammenarbeit geht, ist der Betrachtungswinkel weniger ein soziologischer oder systemtheoretischer und mehr ein psychologischer. Basierend auf mehreren wissenschaftlichen Studien beschreiben sie das Phänomen, dass Führungskräfte und Mitarbeiter in Krisensituationen dazu neigen, stärker miteinander zu konkurrieren, weniger Informationen zu teilen und mehr einsame Entscheidungen zu treffen. Da diese (auf unbewussten Mechanismen beruhenden) Muster aber zu tendenziell schlechteren Ergebnissen führen, ist es sinnvoll ihnen durch bewusst herbeigeführte, die Zusammenarbeit stärkende Massnahmen zu begegnen. Auch diese Massnahmen stellt der Artikel vor.

Prateek Singh: The Non-Issue of Team Size aka The Incomplete Understanding of Complete Graphs

Die Grafik mit der bei gleichmässig steigender Teamgrösse exponentiell steigenden Zahl an Kommunikations-Verbindungen (siehe hier) dürfte eine der am häufigsten gezeigten sein, wenn es darum geht zu begründen, warum agile Teams eher klein sein sollten. Prateek Singh stellt allerdings die Aussagekraft dieser Darstellung in Frage, da er die Idee eines (grossen) Teams in dem jeder mit jedem kommuniziert in der Realität für kaum vorfindbar hält. Für realistischer hält er die Herausbildung von Kommunikations-Knoten (Hubs), durch die der Kommunikationsaufwand sich deutlich reduzieren lässt. In einem solchen Setting stellt die Grafik nur noch die möglichen Kommunikations-Verbindungen her, nicht mehr die nötigen. Damit hat er natürlich recht, ein Team möglichst klein zu halten ist aber aus vielen Gründen trotzdem erstrebenswert, so lange es nicht auf Kosten der Crossfunktionalität geht.

Jason Knight: 5 Different Types of Debt That Can Hinder Your Product Organisation

Über Technische Schulden und Organisatorische Schulden habe ich bereits selbst etwas geschrieben (hier und hier), Jason Night fügt diesem Konzept noch drei weitere Dimensionen hinzu: die Produkt-Schulden, die Visions-Schulden und die Einnahmequellen-Schulden. Allen ist gemeinsam, dass es sich um ursprünglich aus guten Gründen (bzw. aus der Not heraus) getroffene Entscheidungen handelt, die aber in einer langfristigen Betrachtung Inkonsistenz, Ineffizienz oder Ineffektivität zur Folge haben, die mit z.T. grossem Aufwand korrigiert werden müssen (dieser Aufwand ist das "Zurückzahlen" der Schulden, daher die Analogie). Grundsätzlich gilt: diese verschiedenen Arten von Schulden sind nicht per se schlecht, sie müssen aber bewusst aufgenommen und planmässig abgebaut werden.

Tim Ottinger: Definition-by-Dysfunction

Wer Twitter und Linkedin nach Meinungen zu den agilen Frameworks (oder zur Agilität im Allgemeinen) durchsucht, wird einen bestimmten Typ erstaunlich häufig finden: kategorische und z.T. hochemotionale Ablehnungen, die aber auf Aspekten beruhen, die in keinem einzigen Framework enthalten sind (Sprints mit unrealistisch hoher Arbeitsmenge, Unterlassen von Planung und Dokumentation, alberne Spiele in Retrospektiven, etc.). Tim Ottinger gibt diesem Phänomen einen Namen: Definition by Dysfunction (sinngemäss übersetzt: eine Vorstellung die auf einem dysfunktionalen Kennenlern-Kontext beruht). Dafür, dass die Erkenntnis, einer Definition by Dysfunction aufgesessen zu sein, erhellend sein kann, ist er selbst ein gutes Beispiel - ursprünglich ein Gegner von Scrum, findet er den Ansatz mittlerweile (seit er ihn in Original kennt) gut.

Jason Zinoman: How Taylor Tomlinson Nailed Her Closing Joke

Auch ausserhalb der "agilen Blase" gibt es die Idee kontinuierlicher incrementeller Überprüfung und Verbesserung. Dieses Beispiel hier ist besonders anschaulich: Jason Zinomann, ein Journalist der New York Times, hat die Komikerin Taylor Tomlinson in den neun Monaten vor einem großen, für das Fernsehen aufgezeichneten Auftritt begleitet und dabei dokumentiert, wie einzelne Elemente ihres finalen Auftritts immer wieder in kleineren Auftritten erprobt, basierend auf dem Feedback des Publikums optimiert und danach erneut erprobt wurden. Ohne den Begriff zu nennen (und vermutlich ohne sich dessen bewusst zu sein) ist das die Anwendung agiler Praktiken bei der Entwicklung eines Bühnenprogramms.

Warum gerade viele Scrum Master und Agile Coaches ihren Job verlieren

Bild: Pexels / Antoni Shkraba - Lizenz

In vielen Unternehmen ist gerade ein scheinbar paradoxes Nebeneinander von zwei Phänomenen zu beobachten. Zum einen ist  mittlerweile allgemein anerkannt, dass Firmen agil (d.H. in kurzen Abständen Liefer- und Reaktionsfähig) sein müssen, um Umbrüchen wie Wirtschaftskrisen, Covid19 oder dem Aufstieg von KI-Anwendungen begegnen zu können. Zum anderen trennen sich gerade viele Firmen von ihren Scrum Mastern, Agile Coaches und sonstigen "agilen Methodikern". Wie passt das zusammen?

Spricht man mit Managern in diesen Unternehmen, ist die meistens von ihnen kommende Erklärung eine, die für besagte Methodiker nicht besonders angenehm ist: ja, Agilität ist wichtig und wird (wenn auch z.T. unter anderen Namen) weiter angestrebt. Dass trotzdem gleichzeitig Scrum Master- und Agile Coach-Stellen abgebaut werden liegt daran, dass aus Unternehmenssicht nicht erkennbar ist, dass diese in nennenswertem Ausmass zu diesem Ziel (agil zu werden oder zu bleiben) beitragen.

Diese Bewertung ist heftig und muss darum eingeordnet werden. Zum einen gibt es natürlich auch viele Firmen, in denen nicht so gedacht wird und in denen die agilen Methodiker weiterhin eine hohe Wertschätzung erfahren. Des Weiteren beruhen derartig negative Beurteilungen mitunter auf Unwissen oder hidden Agendas. Die schiere Menge der Fälle legt aber nahe, dass auch solche dabei sind, in denen diese negative Aussenwahrnehmung gerechtfertigt ist.¹

Wenn wir unterstellen, dass diese Rollen grundsätzlich Sinn machen (ein Argument dafür findet sich hier), stellt sich jetzt die Frage, was in so vielen Firmen falsch läuft. Was sind die Gründe dafür, dass Scrum Master und Agile Coaches dort nicht dazu beitragen, die Produktentwicklung agiler zu machen? Die Gründe dürften vielfältig sein, nachdem ich in zahlreichen Unternehmen bestimmte Muster immer wieder erlebt habe, wage ich aber die Hypothese, dass die folgenden Ursachen eine zentrale Rolle spielen:

Fehlende Methoden-Expertise

Eine der irritierendsten Beobachtungen zu Beginn: viele Methodiker haben nur ein erstaunlich dünnes Methodenwissen. Häufig beschränkt es sich auf Scrum (und selbst das manchmal nur oberflächlich²), Kanban wird auf ein Task-Board mit WIP-Limits reduziert, von SAFe sind nur die inneren Mechaniken der Release Trains bekannt, etc. Das engt nicht nur den eigenen Werkzeugkasten ein, es führt auch zum Verlust des Status als Experte für Agilität und Organisationsentwicklung.

Fehlende technische Expertise

Um einem häufigen Einwand direkt zu begegnen - nein, ein Scrum Master oder Agile Coach muss keinen Code schreiben können. Er sollte aber zumindest auf einer abstrakten Ebene verstanden haben, was Continuous Integration, Feature Toggles, Code Coverage und Software Architektur mit Agilität zu tun haben. Ist das nicht der Fall, wird er viele Impediments und Wissenslücken in seiner Umgebung nicht erkennen und damit auch nicht beheben können.

Fehlende fachliche Expertise

Auch hier eine direkte Erwiderung auf einen häufigen Einwand - ja, das ist das Themengebiet des Product Owners. Aber: die Beratung des Product Owners gehört zu den expliziten Aufgaben des Scrum Masters. Und zumindest dort wo Elemente der Fachlichkeit mit dem agilen Vorgehen zu kollidieren drohen (z.B. im Fall von Vorgaben durch gesetzliche Regulierung) müssen diese bekannt und verstanden sein, um ein mit ihnen kompatibles und trotzdem agiles Vorgehensmodell entwickeln zu können.

Fehlende wirtschaftliche Expertise

Dass viele Scrum Master und Agile Coaches dieses Themengebiet nicht als ihres ansehen ist ein schwerwiegendes Missverständnis. Time to Market, Minimum Viable Products, Lead Times, Technische Schulden, (die Vermeidung von) Waste und viele andere Themen sind zutiefst betriebswirtschaftlich und gleichzeitig von zentraler Bedeutung für agile Produktentwicklung. Wer sie nicht kennt wird sich oft schwer damit tun, einem Stakeholder die Sinnhaftigkeit agilen Arbeitens zu erklären.

Fehlendes Systemverständnis

Gemeint ist hier das organisatorische Gesamtsystem. Ausserhalb der eigentlichen Produktentwicklung gibt es verschiedene Prozesse und Einheiten, die starke Einflüsse auf den Grad der möglichen Agilität haben: von Budgeting und Compliance über HR und Betriebsrat bis hin zum Facility Management. Ähnlich wie im Fall der technischen Expertise ist es ohne Systemverständnis an vielen Stellen nicht möglich, Impediments zu erkennen (und damit auch nicht, sie zu lösen).

Um es noch ein weiteres mal zu wiederholen: es gibt viele Firmen in denen sich andere Konstellationen finden lassen, die gerade genannten Qualifikationslücken sind also keineswegs typisch für die agilen Methoden-Berufe. Es gibt aber eine signifikante Menge in dieser Gruppe, die diese Aspekte (bewusst oder unbewusst) wenig beachtet hat, um sich stattdessen mit Themen wie Coaching, Achtsamkeit und kreativer Meeting-Moderation zu beschäftigen. Nicht dass die keine Berechtigung hätten, aus einer unternehmerischen Sicht sind sie aber deutlich weniger wichtig als die zuvor genannten.

Was man für ein vollständiges Bild aber auch sagen muss: aus einer unternehmerischen Sicht ist es ebenfalls sinnvoll und notwendig, die oben genannten Themengebiete in die Ausbildung und Weiterentwicklung der eigenen Scrum Master und Agile Coaches zu integrieren. Dort wo das geschehen ist, dürften diese Jobs wertstiftend (und damit sicher) sein. Dort wo es nicht geschehen ist sollte man sich fragen, ob die aktuellen Entlassungen nicht auch ein Zeugnis einer verfehlten Personalpolitik sind.

¹Alleine im Grossraum Köln/Bonn weiss ich von einer dreistelligen Zahl an Scrum Master-, Agile Coach- und Release Train Engineer-Stellen, die gestrichen oder zu Teilzeit-Tätigkeiten reduziert wurden
²Klassische Missverständnisse sind das Weglassen zentraler Elemente, wie z.B. den Sprint Zielen, bei gleichzeitigem dogmatischem Beharren auf optionalen Elementen wie den Story Points oder der Definition of Ready

Scaled Agile: Hubs

Wir alle kennen den für agile Teams anzustrebenden Idealzustand: crossfunktional, d.h. in der Lage, alle notwendigen Tätigkeiten selbst auszuüben, und selbstorganisiert, d.h. in der Lage, selbst darüber entscheiden zu können, welche dieser Tätigkeiten wann durchgeführt wird. In der Realität gibt es aber immer wieder Sachzwänge wirtschaftlicher oder regulatorischer Art, die diesen Idealzustand einschränken. Das macht Kommunikation und Koordination mit anderen Teams nötig.

Je nachdem wie (un)hierarchisch eine Organisation aufgestellt ist, kann die Gestaltung dieser Kommunikationsströme unterschiedliche Formen annehmen. Der klassische Weg ist dabei der durch das Management. Ein Team-, Abteilungs- oder Projektleiter sammelt die zu besprechenden Themen in seiner Einheit ein, trifft sich mit seinem Gegenpart aus der anderen Einheit, der dort vorher das Gleiche gemacht hat, bespricht alles mit ihm und bringt die Ergebnisse zurück zu seinen Leuten.

Eine solche Lösung ist zwar naheliegend, allerdings aus verschiedenen Gründen problematisch. Entscheidungskompetenz und Umsetzungsexpertise werden entkoppelt, diese Art der Informationsübermittlung dauert relativ lange, durch die verschiedenen Kommunikations-Stationen entsteht das Risiko von Stille Post-Effekten und es kann sich (ggf. unbeabsichtigt) beim Management Herrschaftswissen herausbilden.

Der häufig propagierte "agile Gegenentwurf" ist die Netzwerk-Organisation. Hierarchien kann es zwar auch hier noch geben, die Kommunikationsströme richten sich aber nicht mehr an ihnen aus. Stattdessen kann jeder Einzelne mit jedem Anderen (sowohl Personen als auch Gruppen) Kontakt aufnehmen und anstehende Themen besprechen und Klären. Gegebenenfalls können dabei auch direkte Kommunikationen zwischen unterschiedlichen Hierarchie-Ebenen zustande kommen.

Auch diese Lösung ist aber nicht unproblematisch. Es besteht das Risiko, dass die Kommunikation zerfasert und unübersichtlich wird, mit der Folge, dass entweder Redundanzen entstehen (die im schlimmsten Fall zu verschiedenen, ggf. inkompatiblen Lösungen für das selbe Problem führen), oder dass ein unverhältnismässig hoher Aufwand investiert werden muss, um für jeden nachvollziebar zu machen, wer gerade mit wem über welches Thema spricht.

Ein Versuch, einen Mittelweg zwischen diesen beiden Extremen zu finden, kommt von James Coplien, einem der unbekannteren Pioniere der agilen Software-Entwicklung (unter anderem hat er das Daily Scrum/Daily Standup erfunden). In seinem Ansatz der Scale Free Organisation ergänzt er die Netzwerk-Organisation um Personen, die Informationsknotenpunkte, die so genannten Hubs, bilden, welche die zu kommunizierenden Informationen konsolidieren, bzw. verteilen.

Der Unterschied zu dem Management-zentrierten Ansatz ist, dass es sich bei diesen die Informationen konsolidierenden, bzw. verteilenden Personen nicht um Manager oder sonstige Funktionsträger handelt, sondern lediglich um Menschen, die aufgrund ihrer Kommunikativität, ihrer Versetzungshistorie, ihrer Bereitschaft Wissen zu teilen oder sonstiger Faktoren (z.B. der Mitgliedschaft im Betriebssportverein) überdurchschnittlich viele andere Menschen kennen und bei Bedarf Kontakt zu ihnen herstellen können.

Ebenfalls im Unterschied zum Management-zentrierten Ansatz erfolgt die Herausbildung von Hubs selbstorganisiert, emergent und ggf. temporär. Mit anderen Worten: da kommunikative und/oder gut vernetzte Personen mit höherer Wahrscheinlichkeit angesprochen werden oder an Abstimmungs-Meetings (z.B. einem Scrum of Scrums) teilnehmen werden als andere, verstärkt sich ihr Hub-Status selbst. Fallen Hubs aus (z.B. durch Versetzung) entsteht durch die gleichen Mechanismen ein Ersatz.

Bedingt durch diese Selbstorganisations- und Kompensationsmechanismen (die Coplien in 200 von ihm untersuchten Unternehmen identifizieren konnte) sind Organisationen, deren Kommunikation über derartige Hubs läuft, mit einer hohen Effektivität, Flexibilität und Resilienz ausgestattet, da in ihnen direkte Verbindungen immer da entstehen wo sie gerade gebraucht werden, ohne dass sie sich durch Regulierung oder Normierung verfestigen.

Ein interessanter Aspekt, auf den Coplien aber nicht eingeht, ist die Frage, ob sich in formal Management-zentrierten Organisationen informelle Strukturen in Form von Hubs herausbilden können. Die Erfahrung spricht dafür, ob es wirklich in nennenswertem Ausmass der Fall ist, wäre aber ein interessantes Forschungsfeld für die Organisationssoziologie.

Ein Bild sagt mehr als 1000 Worte (XXXX)

 

Bild: {turnoff.us} / Daniel Stori - CC BY-NC-ND 4.0

Agile Success Stories: die Wiederauferstehung des abgeschriebenen Teams

Bild: Pexels / Yan Krukau - Lizenz

Leider ist es so, dass viele "agile Methodiker" (Agile Coaches, Scrum Master, etc.) mit der Zeit eine eher negative Weltsicht entwickeln. Das ist auch menschlich verständlich, wer sich ständig mit dem Beseitigen von Impediments und dem Kampf gegen Change Fatigue und Konzern-Trolle beschäftigen muss, kann leicht in Frustration abrutschen. Um nicht selbst in dieses Muster verfallen, möchte ich dagegenhalten, indem ich ab und zu selbst erlebte "agile Erfolgsgeschichten" veröffentliche.

Diese hier begann zuerst wenig verheissungsvoll. Eine der ersten Aussagen am ersten Tag in einem Team, das ich als Agile Coach begleiten sollte, kam vom Product Owner und lautete, dass solange er im Amt wäre nichts neu entwickelt werden und schon gar nichts Neues auf Produktion deployed werden würde. Was auch immer die Entwickler machen würden wäre ihm egal, Hauptsache nichts an der von ihm verantworteten Anwendung. Was für ein Einstieg.

Seine Begründung: die Anwendung sollte schon länger abgelöst werden, in der Nachbarstadt wurde bereits seit zwei Jahren an der Nachfolgelösung gebaut. Er selbst und seine Fachabteilungs-Kollegen würden darum auch nur noch in Teilzeit im Team mitarbeiten, und da jedem Go Live ein von ihnen mit grossem Aufwand manuell durchzuführender fachlicher Test vorausgehen musste, wäre für den einfach keine Zeit vorhanden. Maximal ein Bugfix pro Monat wäre noch irgendwie machbar, mehr nicht.

In diesem scheinbaren Dilemma entdeckten die Entwickler aber auch eine Chance: da sie praktisch nichts mehr entwickeln durften, hatten sie freie Kapazitäten und konnten diese für etwas nutzen, was ihnen der alte, gerade zum Nachfolge-Projekt gewechselte, Product Owner immer zugunsten neuer Features wegpriorisiert hatte: Testabdeckung und Testautomatisierung. Beim nächsten Bugfix sparte die den Fachabteilungs-Kollegen bereits die Hälfte des Testaufwandes ein, beim übernächsten noch mehr.

Anfangs erstaunt und zunehmend begeistert liess der Product Owner nach und nach seine Blockade-Haltung fallen. Angesichts der plötzlich mit geringerem Aufwand machbaren Releases liess er sich nicht nur auf eine Weiterentwicklung der Altanwendung ein, er hatte auch eine Idee was noch zu tun wäre. Das System war noch nicht an die Auswirkungen einiger neuer regulatorischer Vorgaben angepasst, wodurch regelmässige Strafzahlungen fällig wurden. Diese Anpassungen wollte er jetzt nachholen.

In wenigen Sprints war auch das geschafft, und das gerade rechtzeitig, da sich plötzlich eine neue Möglichkeit für zusätzlichen Umsatz und Gewinn ergeben hatte. Ein anderes Unternehmen hatte eine Vertriebspartnerschaft angeboten, für die lediglich eine neu zu programmierende Schnittstelle und einige Datenbankanpassungen nötig waren. Erneut waren nur wenige Sprints nötig um diese fertigzustellen. Der Product Owner und seine Fachabteilungs-Kollegen waren euphorisch.

Weniger euphorisch war das Nachfolgeprojekt, das übrigens aus einem SAFe-Release Train bestand. Die Vertriebspartnerschaft sollte natürlich auch mit dem neuen System möglich sein, weshalb plötzlich dessen Umfang erweitert und dessen Zeitplan angepasst werden musste. Leicht säuerlich eskalierte der Projektleiter (der erwähnte ehemalige PO) bei der Geschäftsleitung, um ab jetzt zu verhindern, dass neue Weiterentwicklungen der Altanwendung die Erstellung der Nachfolgelösung aufwändiger machten.

Zum Glück befanden sich im Backlog des Altanwendungsteams noch weitere Aufgaben. Ein vergangener Penetrationstest hatte potentielle Sicherheitslücken identifiziert, die jetzt geschlossen werden konnten. Zum nächsten Sprint Review wurden die Beauftragten für IT-Security und Datenschutz eingeladen, die gleichzeitig begeistert und erbost waren. Begeistert wegen der Verbesserungen, erbost weil sie inzwischen erfahren hatten, dass diese Lücken auch in der Nachfolgelösung vorhanden waren.

Die weitere Geschichte kann man sich denken: das Nachfolgeprojekt musste erneut Scope und Zeitplan anpassen, das Altanwendungs-Team hatte Zeit für weitere Refactorings und Prozessautomatisierungen und konnte dadurch immer schneller andere, schon lange gewünschte Features einbauen, die das Nachfolgeprojekt dann ebenfalls einplanen musste. Es entstand eine bemerkenswerte Dynamik: das mittlerweile agile Altanwendung-Team konnte vom Ablöse-Projekt kaum noch eingeholt werden.

Als es irgendwann doch dazu kam, und die alte Anwendung abgeschaltet werden konnte, hatte sich die Wahrnehmung des Teams durch die Organisation völlig geändert. Um es mit den Worten des Product Owners zu sagen: "Nicht nur das alte System, auch die alten Entwickler waren von allen schon abgeschrieben worden. Nach dieser unglaublichen Wiederauferstehung reissen sich jetzt alle darum, sie zu sich in die neuen Teams zu holen. Was für eine Erfolgsgeschichte."

Das wirklich Bemerkenswerte daran: dieser Erfolg beruhte auf keinem Wunder, sondern auf Ideen, die in jeder agil arbeitenden Firma Common Sense sein sollten: ein kleines, crossfunktionales Team, Automatisierung repetitiver Tätigkeiten, enge Zusammenarbeit mit dem Kunden, möglichst schnelles Reagieren auf geänderte Rahmenbedingungen und kontinuierliche Optimierung. Mit anderen Worten: auch andere Teams könnten sich so entwickeln, wenn man ihnen die richtigen Rahmenbedingungen und Freiheiten gibt. Man müsste es nur tun.

Generative AI in a Nutshell

Wenn es um "Agile Erklärvideos" geht ist Henrik Kniberg eine Person auf die immer verwiesen wird. Von ihm sind unter anderem die Videos zum so genannten Spotify Model und das zu Recht legendäre Agile Product Ownership in a Nutshell. Sein neuestes Werk, "Generative AI in a Nutshell" ist daher bereits mit Vorschuss-Lorbeeren begleitet veröffentlicht worden, wie man hier sehen kann zu Recht. Es ist die vermutlich beste Erklärung des aktuellen Standes dieser bemerkenswerten Technologie.

Was man aus diesem Video mitnehmen kann, sind sowohl das Wissen um die Funktionsweise und das Potential der so genannten Large Language Models (LLM), zu denen u.a. Chat GPT und Bard/Gemini gehören, als auch das Wissen um deren Begrenzungen und Risiken. Wie Kniberg selber sagt: richtig eingesetzt können sie zu immensen Effizienz- und Effektivitäts-Gewinnen führen, unbedacht eingesetzt können sie massive Schäden anrichten (siehe hier). Mit KI-Anwendungen umgehen zu können ist daher gerade in Berufen der Wissensarbeit eine entscheidende Qualifikation.

Larman's Law (II)

Mit der Zeit haben sich viele Menschen Gedanken über die ungeschriebenen Gesetze der Organisationsentwicklung gemacht und versucht sie (auf manchmal seriöse, manchmal aber auch eher zynische Art) auf Papier zu bringen. Besonders produktiv war dabei Craig Larman, der Erfinder von LeSS, der insgesamt fünf Gesetze verfasst hat, die er Larman's Laws of Organizational Behavior genannt hat. Heute soll es hier um das Zweite von ihnen gehen. Es lautet:

[...] any change initiative will be reduced to redefining or overloading the new terminology to mean basically the same as status quo

Dieses zweite "Gesetz" baut auf das erste auf, demzufolge große Organisationen implizit darauf optimiert sind, den Ist-Zustand der bestehenden Management-, Spezialisten- und Machtpositionen zu erhalten (mehr dazu hier). Man erkennt, dass beide durch einen eher pessimistischen und polemischen Blick Larmans auf das Veränderungsmanagement geprägt sind. Aber ist diese Sichtweise auch gerechtfertigt, und das vor allem in dieser Absolutheit?

Einen Hinweis darauf wie sie zu verstehen ist findet man in den Erläuterungen, die Larman's Gesetzen angehängt wurden (siehe hier). In ihnen führt er aus, dass Kultur, Verhalten und geistige Haltungen in grossen Organisationen durch das Systemdesign (also die Hierarchien, Prozesse, etc.) geprägt werden. Umgekehrt bedeutet das, dass Kultur, Verhalten und Haltungen ohne gleichzeitige Arbeit am System nicht erfolgreich geändert werden können, sondern immer wieder in alte Muster zurückfallen werden.

Und genau das ist es, was Larmans zweites Gesetz aussagt. Ohne eine Veränderung der beeinflussenden Systemfaktoren wird jedes lediglich auf Kultur oder Mindset ausgerichtete Veränderungsvorhaben nicht nur wirkungslos bleiben, sondern durch eben jene Faktoren so lange (unbewusst) umgeformt werden, bis es ein Ergebnis hervorbringt, das dem Ausgangszustand entspricht. Was bleibt sind die neuen Begriffe, hinter denen aber wieder die alten Inhalte stehen.

Mit diesem Gedanken im Hintergrund kann Larmans zweites Gesetz aber auch eine Anleitung zum erfolgreichen Veränderungsmanagement sein: erkenne, welche Systemfaktoren definierend für die Unternehmenskultur und die individuellen Haltungen der Mitarbeiter sind, und eine Kulturveränderung wird durch eine Arbeit am System möglich - und das wenn man möchte sogar ohne dass irgendwelche neuen Namen für Titel, Prozesse, etc. eingeführt werden.

Natürlich sollte dazu noch erwähnt werden, dass eine derartige Arbeit am System hochkomplex und in ihren Ergebnissen nicht immer vorhersehbar ist, aber das ist eine Geschichte für ein anderes mal.

KVP im Bürgeramt

Zu meinen Lieblingsbeispielen für kontinuierliche Verbesserungsbemühungen zählen Einrichtungen, die man damit nicht sofort assoziieren würde: deutsche Behörden. Optimiert wird auch in ihnen, und da man sie nur in relativ grossen Abständen aufsucht, ist die Chance gross, dass einem jedesmal irgendetwas auffällt, das anders ist als beim letzten mal. In meinem Fall sind es die Bürgerämter meiner Wohnorte (z. Zt der Stadt Bonn), in denen ich etwa einmal pro Jahr erscheinen muss.

Bevor wir zu meinen Beobachtungen kommen, macht zuerst eine kurze Erläuterung zu dem "Verbesserungsgegenstand" Sinn: das was im Bürgerzentrum regelmässig optimiert wird, ist der Durchfluss von Kunden, also Bürgern, die für irgendeinen Verwaltungsakt dort vorstellig werden müssen. Um diesen eine möglichst gute Service-Erfahrung zu geben, und um die Servicekräfte optimal auszulasten, sollten Staus und Wartezeiten so gering wie möglich sein.

In der weit zurückliegenden Anfangszeit der Optimierungen war das noch nicht der Fall. Jeder der mit einem Termin oder als Laufkundschaft zur Stadt kam meldete sich an, setzte sich in einen Warteraum und wartete dort darauf, dass der eigene Name aufgerufen wurde. Wie lang das dauern würde liess sich nicht absehen, Wartezeiten von über einer Stunde waren nicht selten. Diese Unklarheit über die verbleibende Wartezeit war das erste, das durch eine Prozessanpassung behoben wurde.

Irgendwann wurden Wartenummern eingeführt, zu Beginn noch solche in Papierform, die man sich aus einem vor Ort stehenden Automaten ziehen musste. Aufgerufen wurden jetzt nicht mehr die Namen sondern die Nummern, wodurch sich erkennen liess, wie viele andere Personen vor einem selbst bedient werden würden. Liess sich so erkennen, dass es noch dauern würde, konnte man kurz vor die Tür gehen, Geld in die Parkuhr werfen, etwas rauchen oder sonstige kurze Erledigungen machen.

Der nächste Verbesserungsschritt war die Einführung grosser Bildschirme, auf denen die zuletzt aufgerufenen Nummern angezeigt wurden. Für den Fall, dass man verspätet eintraf oder den eigenen Aufruf überhört hatte, konnte man dort sehen, dass man bereits an der Reihe war. Eine darauf aufbauende Verbesserung bestand daraus, dass dort auch die Tischnummer der nächsten freien Servicekraft angezeit wurde, wodurch der bis dahin nötige Gang zum Zentralschalter entfiehl.

Die hinter der Anzeigetafel arbeitende Software wurde später mit einer weiteren verbunden, mit der man Terminbuchungen online vornehmen konnte. Sobald man einen Termin gebucht hatte erhielt man eine Mail. in der nicht nur die Terminbestätigung stand, sondern auch die Wartenummer. Vor Ort musste man dadurch nicht mehr eine Nummer ziehen und warten, sondern konnte direkt überprüfen, ob man bereits aufgerufen wurde.

Die vorerst letzte Optimierung, die mir bei meinem letzten Besuch aufgefallen ist, besteht darin, dass man jetzt vor Ort grosse Touch-Displays hat, auf denen man durch Eingabe seiner online gebuchten Wartenummer mitteilen kann, dass man angekommen ist und aufgerufen werden kann. Verspätungen sind dadurch kein Problem mehr, man rutscht stattdessen weiter nach hinten in die Reihenfolge, aus der zuerst andere Nummern aufgerufen und bedient werden können.

Weitere Prozessverbesserungen dürften in diesem Zeitraum auch ausserhalb des für die Kunden sichtbaren Bereichs stattgefunden haben, alleine im Bereich der Digitalisierung kann man sich so einiges vorstellen. Über die Jahre wird es so zu einem ingesamt beachtlichen Umfang von Veränderungen gekommen sein.

Diese Art der nach und nach stattfindenden Optimierung hat mehrere Vorteile gehabt: grosse, disruptive Veränderungen wurden unnötig, die Folgen der jeweils letzten Umstellung liessen sich aufgrund der kleinen Umfänge besser identifizieren und bewerten, und in Summe ist es so zu einem Prozess gekommen, der nicht nur gut funktioniert, sondern auch einer ist, auf den beim Versuch alles im Voraus zu planen vielleicht niemand gekommen wäre.

Zuletzt hat der KVP (Kontinierliche Verbesserungsprpzess) im Bürgeramt noch einen Vorteil auf der Meta-Ebene: er hat an einem Ort stattgefunden, den jeder Mensch in Deutschland kennt, ins Bürgeramt muss früher oder später jeder. Es ist damit ein Praxisbeispiel das sofort jeder nachvollziehen kann und anhand dessen man Prozessoptimierungen auch für Menschen, die selten damit zu tun haben, nachvollziebar erklären kann.