Donnerstag, 29. Februar 2024

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.

Montag, 26. Februar 2024

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.1


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ächlich2), 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 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.



1Alleine 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
2Klassische 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

Donnerstag, 22. Februar 2024

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.

Montag, 19. Februar 2024

Ein Bild sagt mehr als 1000 Worte (XXXX)

 

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

Freitag, 16. Februar 2024

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.

Dienstag, 13. Februar 2024

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.

Donnerstag, 8. Februar 2024

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.

Montag, 5. Februar 2024

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.

Mittwoch, 31. Januar 2024

Kommentierte Links (CX)

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.

Philip Plickert: Hunderte Menschenleben durch einen Computerfehler ruiniert

Vor einigen Jahren hatte ich ab und zu auch Meldungen in die Kommentierten Links aufgenommen, in denen es um dramatische Folgen von Software-Fehlern ging, z.B. um Flugzeugabstürze oder um die versehentliche Entlassung von Verbrechern aus Gefängnissen. Diese Nachricht hier ist so krass, dass ich diese Kategorie wieder aufleben lasse: 700 Leiter von britischen Postfilialen wurden aufgrund fehlerhafter Software zu Unrecht wegen Unterschlagung verurteilt, einige davon zu Gefängnisstrafen. Berufliche Existenzen wurden zerstört, Reputationen ruiniert, Ehen gingen in die Brüche. Irrsinnig.

Bent Freiwald: Wir haben unsere Arbeitsweise radikal verändert

Eine Fallstudie zu selbstorganisiertem Arbeiten, die anders ist als die meisten von denen man sonst so hört, alleine weil der Kontext ein anderer ist als der übliche (IT-Abteilungen, Krankenpfleger, etc). Die Gruppe um die es hier geht ist die Redaktion des Online-Magazins Kraureporter, in dem alle leitenden Positionen abgeschafft wurden. Stattdessen arbeiten in einem entfernt auf Scrum basierten Arbeitsmodus drei Teams an der Recherche und dem Verfassen von Texten, übergreifende Entscheidungen werden in einem strukturierten Beteiligungsverfahren getroffen. Spannend zu lesen, von solchen Experimenten würde ich gerne mehr hören.

Stephanie Ockerman: Stop Being So "Helpful"

Völlig zu Recht beschreibt Stephanie Ockermann ihre Beobachtung als eines der schmutzigen Geheimnisse vieler Agile Coaches: wenn sie das Gefühl haben, ihren Teams helfen zu können, indem sie ihnen bestimmte Herausforderungen abnehmen, dann tun sie das - und untergraben damit die Selbstorganisation und Problemlösungskompetenz ihrer Coachees. Dieses Verhalten ist gut gemeint und menschlich, trotzdem ist es eines das man sich abgewöhnen sollte, sobald man es an sich selbst entdeckt. Der Text enthält auch eine kleine Anleitung dazu, wie man es entdecken kann und wie man sich selbst zu mehr Zurückhaltung bringt.

Jeff Gothelf: What people say vs what they do

Apropos Beobachtungen allzu menschlichen Verhaltens. Auch Jeff Gothelf hat eine solche gemacht, und zwar die, dass das was Menschen sich vornehmen und das was sie dann tun sehr weit auseinanderliegen können, allerdings nicht weil sie unaufrichtig sind, sondern weil die Rahmenbedingungen sich so unerwartet entwickeln können, dass ein anderes Verhalten als das ursprünglich geplante plötzlich viel naheliegender ist. Ein Fall den er besonders hervorhebt, ist die in Kundeninterviews erfragte Bereitschaft neue Funktionen zu nutzen. Die sollte anders validiert werden als durch eine blosse Absichtserklärung, wenn sie eine Aussagekraft haben soll.

Geoff Watts: Agility is certainly not dead

Eines der grossen Themen dieses Winters ist das (mal wieder) von einigen Menschen marktschreierisch vorgetragene Ende der agilen Bewegung. Geoff Watts versucht zu ergründen was hinter diesen Aussagen steckt und trägt einige Gründe zusammen: mit Missverständnissen verknüpfte falsche Hoffnungen, die Versuche die agilen Frameworks an Stellen einzusetzen an denen sie gar keinen Sinn machen und die über das Ziel hinausgeschossene Kommerzialisierung. Gleichzeitig streicht er heraus, dass die Gründe wegen denen die agilen Vorgensweisen nötig geworden sind unverändert weiter existieren, und agiles Arbeiten (unter welchem Namen auch immer) weiter nötig machen. Passend dazu: ein Artikel von Barry Overeem, in dem er beschreibt, wie man sich aus den "Agile is Dead"-Debatten befreien kann.

Montag, 29. Januar 2024

Warum so viele Manager?

Bild: Gottscho-Schleisner / Library of Congress - Public Domain

Eine der Nachrichten, die in letzter Zeit für Aufmerksamkeit gesorgt haben, ist der bevorstehende Stellenabbau bei Bayer. Nicht nur wegen der verlorenen Arbeitsplätze, sondern auch wegen einer in diesem Zusammenhang veröffentlichten Zahl: 17.000 von 100.000 Mitarbeitern arbeiten dort im Management, also fast jeder fünfte. Mehrfach habe ich die Frage gehört, wie das denn sein kann, die Zahl wirkt auf den ersten Eindruck unglaublich hoch. Versuchen wir es mit einer Erklärung.


Da ich die internen Strukturen bei Bayer nicht kenne, starten wir mit Vergleichswerten, die ich in verschiedenen anderen Firmen erlebt habe. Auf der untersten Ebene gehen wir dabei von Teams, Gruppen oder Referaten von ca. 10 Mitarbeitern aus, einer häufig anzutreffende Grösse. Unterstellen wir, dass jede dieser Einheiten einen eigenen Team-, Gruppen oder Referatsleiter hat, kommen wir damit auf ein Manager/Mitarbeiter-Verhältnis von 1 zu 10.


Auf der nächsthöheren Ebene gehen wir davon aus, dass jeweils fünf der untersten Einheiten eine Abteilung bilden, jeweils fünf Abteilungen einen Bereich, und so weiter, bis hinauf zu den Ressorts und Landesgesellschaften. Jede dieser Einheiten hat einen Leiter, und nicht nur das, ab einer bestimmten Grösse kommen Stellvertreter und Stabsstellen dazu. Alle diese Positionen zählen wir auch zum Management, und gehen dadurch grob von einem Manager/Mitarbeiter-Verhältnis von 1 zu 9 aus.


Dieses Verhältnis dürfte vor allem dort anzutreffen sein, wo es um gleichbleibende Regeltätigkeiten geht, z.B. in der Fertigung oder einem Callcenter. In der Wissens- oder Innovationsarbeit ist es aber meistens komplizierter, dort wird normalerweise in Projekten gearbeitet. Diese Projekte bilden dabei eine eigene, zu den Teams, Abteilungen, etc. parallele Organisation, die sich die Mitarbeiter von den gerade genannten Einheiten leiht, zu deren Koordination aber eigene Manager hat.


Gehen wir auch hier zuerst von der Grösse von 10 Mitarbeitern aus, die zu einem gemeinsamen Teilprojekt gehören.1 Und nehmen wir an, dass fünf Teilprojekte ein Projekt bilden und fünf Projekte ein Programm. Wenn wir jetzt noch davon ausgehen, dass wiederum jede dieser Einheiten einen Teilprojekt-, Projekt- oder Programmleiter hat (und die Linienmanager einbeziehen), kommen wir in den projektartig arbeitenden Teilen der Organisation auf ein Manager/Mitarbeiter-Verhältnis von 1 zu 5 oder 1 zu 4.


Auch hier kommen aber nochmal zusätzliche Management-Positionen dazu, zum einen erneut die Stellvertreter und Stabsstellen, ausserdem aber noch die Project Management Offices (PMO), in denen sich bemerkenswerte Mengen von Menschen mit Planungen, Schätzungen, Anträgen, Genehmigungen oder Kommunikation beschäftigen können. Dazu kommen funktionale Stellen wie z.B. Qualitäts-Manager, Rollout-Manager, Compliance-Manager, etc.


Am Ende kann durch diese doppelte Management-Hierarchie in Linien- und Projektorganisation in den projektartig arbeitenden Teilen der Firma sogar ein Manager/Mitarbeiter-Verhältnis von 1 zu 3 möglich sein (!). Verrechnen wir das mit den weniger Management-lastigen Regeltätigkeits-Einheiten, ist im Gesamtdurchschnitt ein Verhältnis möglich, dass etwa dem entspricht, von dem bei Bayer berichtet wurde, etwa 1 zu 5. Diese Zahl kann also stimmen.2


Spätestens jetzt stellt sich die Frage, was all diese Manager eigentlich machen. Wenn wir die zahlenmässig kleine Gruppe der strategisch lenkenden Topmanager ausklammern, lautet die Antwort, dass sie vor allem kommunizieren und koordinieren. Kommuniziert werden Ziele (incl. deren Herunterbrechung) und Ergebnisse (incl. deren Zusammenfassung), koordiniert werden Abhängigkeiten, v.a. fachlicher und technischer Natur, aber auch die zu anderen planenden, freigebenden oder budgetierenden Einheiten.


Wichtig für das Verständnis ist dabei, dass es in der Regel ein Systemdesign gibt, dass diese Tätigkeiten tatsächlich zu Vollzeitjobs macht. Häufige Faktoren sind z.B. hohe Spezialisierungen und knappe Budgets, wodurch Mitarbeiter nur in Teilzeit in die Projekte entsandt werden können, was zu permanenten Ziel-, Termin- und Loyalitätskonflikten führt, deren Auflösung und deren zu kommunizierende Konsequenzen bei Linien- und Projektmanagern erhebliche Daueraufwände verursachen.


Daraus ergibt sich auch, was zu tun ist, wenn man das Verhältnis von Managern zu Mitarbeitern verringern will. Zum einen müssen die unteren Einheiten crossfunktionaler und durch breitere Skillprofile in Vollzeit besetzbar werden, so dass die Zahl der zu koordinierenden Abhängigkeiten abnimmt,3 zum anderen müssen diese Einheiten mehr Entscheidungskompetenzen bekommen, wodurch es nicht mehr nötig ist, ihnen ihre Aufgaben aus übergreifenden Zielen abzuleiten (das können sie dann selbst).


In einem solchen Setting kommt eine Organisation auch mit deutlich weniger Managern aus, wobei allerdings zu beachten ist, dass eine Delegation von Verantwortung nach unten ohne Begleitung und Befähigung schnell in Überforderung enden kann (die so genannte Autonomiefalle). Um diese zu vermeiden müssen die verbleibenden Manager verstärkt die Rolle von Beratern und Coaches annehmen, um so die neuen, crossfunktional-autonomen Teams in Richtung Selbstmanagement zu entwickeln.


Genau das ist laut dem oben verlinkten Artikel auch das Zielbild der organisatorischen Veränderungen bei Bayer. Wir können gespannt sein ob das erfolgreich sein wird oder nicht, vielleicht wird es ja in einigen Monaten oder Jahren neue Berichte in den Medien geben, aus denen sich das Ausmass der Erfolge ablesen lassen wird.



1Bzw. FTEs, also Entsprechungen einer Vollzeitstelle, die ggf. auf mehrere Teilzeitstellen aufgeteilt werden können
2Natürlich gibt es auch viele Unternehmen in denen die Zahlen andere sind, aus meiner Erfahrung sind die von Bayer aber zumindest keine totalen Ausreisser
3Ein gewisser Umfang von Abhängigkeiten ist zwar unvermeidbar, wird der klein gehalten, können die Teams diese aber auch selbst managen

Donnerstag, 25. Januar 2024

MBO und OKR

Zu den grossen "agilen Trends" der letzten Jahre gehören die Objectives and Key Results (OKRs), eine Methode um persönliche oder übergreifende Ziele, von der man sich einen einfacheren oder besseren Weg zur Agilität erhofft. Die damit erzielten Ergebnisse schwanken allerdings stark, von deutlichen Verbesserungen bis deutlichen Verschlechterungen ist alles dabei. Meine steile These dazu: man kann absehen was davon der Fall sein wird, und dafür muss man nur betrachten wie vorher mit einem anderen Ansatz umgegangen worden ist - dem Management by Objectives (MBO).


Bevor wir darauf eingehen eine kurze Begriffsbestimmung. OKRs wurden von Andrew Grove bei Intel entwickelt und von seinem damaligen Mitarbeiter John Doerr später bei Google eingeführt und dadurch popularisiert. Sie teilen Ziele in qualitative Objectives und quantitative Key Results auf, von denen die ersten abstrakt-übergreifend und die zweiten davon abgeleitet und konkret überprüfbar sind. In der Umsetzung werden Objectives quartalsweise gesetzt und durch Key Results nach und nach erreicht.


Dass dieser Ansatz flexibler (und agiler?) als die sonst üblichen starren Jahresziele ist, liegt auf der Hand, und tatsächlich ist er als bewusste Weiterentwicklung, bzw. Ablösung eines Vorgehensmodells entwickelt worden, mit dem diese in den meisten Fällen umgesetzt werden, eben dem MBO. Grove und Doerr weisen in ihren Büchern High Output Management (Grove, 1983) und Measure what Matters (Doerr, 2017) explizit auf diese Art der Entstehung hin.


[Before the introduction of OKRs], goals were centrally planned and sluggishly trickled down the hierarchy. At others, they became stagnant for lack of frequent updating; or trapped and obscured in silos; or reduced to key performance indicators (KPIs), numbers without soul or context. Most deadly of all, MBOs were commonly tied to salaries and bonuses.
Andy Grove: High Output Management, S.25


Besonders der letzte Punkt ist dabei erwähnenswert, da er den durch ihre Langfristigkeit immer realitätsferner werdenden MBOs eine destruktive Dynamik hinzufügt: die Koppelung der Zielerreichung an Gehaltsbestandteile. Es ist eine menschliche, bzw. betriebswirtschaftliche Reaktion - um den vollen Bonus ausgezahlt zu bekommen, werden alle Ziele konsequent umgesetzt, und zwar auch dann wenn sie mittlerweile als unsinnig erkannt wurden. Geld sticht Sinn.


Die Rollen sind damit klar verteilt. Alt und neu, überkommen und modern, starr und flexibel, Objectives and Key Results und Management by Objectives. Wie fast immer bei derartig klaren Gegensätzen gilt aber auch hier, dass sie zu einfach sind um wahr zu sein. Betrachtet man das Buch in dem die MBOs erstmals beschrieben wurden, The Practice of Management, geschrieben 1954 vom österreichisch-amerikanischen Ökonomen Peter Drucker, entdeckt man Erstaunliches.


The most effective managers I know [...] have each of their subordinates write a “manager’s letter” twice a year. In this letter to his superior, each manager first defines the objectives of his superior’s job and of his own job as he sees them. He then sets down the performance standards which he believes are being applied to him. Next, he lists the things he must do himself to attain these goals—and the things within his own unit he considers the major obstacles. He lists the things his superior and the company do that help him and the things that hamper him. Finally, he outlines what he proposes to do during the next year to reach his goals.
Peter Drucker: The Practice of Management, S. 343


Mit anderen Worten: das was OKRs ausmacht und es angeblich von den MBOs unterscheidet ist in diesen bereits enthalten. Die dezentrale Planung, die Trennung von Zielen und Ergebnissen, die Möglichkeit zu Anpassungen während des Jahres, all das war von Drucker bereits so angedacht. Und selbst die durch die Knüpfung an Gehaltsbestandteile durchgeführte Steuerung von oben war nicht in seinem Sinn, stattdessen spach er bewusst von Management by Objectives and Self-Control.


Reports and procedures should be the tool of the man who fills them out. They must never themselves become the measure of his performance.
Peter Drucker: The Practice of Management, S. 359


Die Betrachtung des MBO wird damit komplett auf den Kopf gestellt - nicht der Ansatz selbst ist problematisch, sondern seine falsche Umsetzung, nicht er selbst beinhaltet Top Down-Management, fehlende Flexibilität und nicht zielführende Anreizgebung, sondern die Menschen die ihn umsetzen bringen diese Ideen mit und überschreiben damit die in ihrem Ursprung komplett in die andere Richtung orientierten Umsetzungs-Empfehlungen.


Und damit kommen wir zurück zur Eingangs-These: will man voraussagen können wie eine Organisation mit Objectives and Key Results klarkommen wird, muss man eigentlich nur überprüfen wie sie mit Management by Objectives umgeht. Setzt sie dieses wie ursprünglich gedacht ein, werden auch OKRs gut funktionieren, verfremdet sie es bis in ihr Gegenteil wird sie das mit grosser Wahrscheinlichkeit auch mit OKRs tun. Da so ziemlich jede halbwegs grosse Firma bewusst oder unbewusst mit MBO arbeitet, ist das eine erstaunlich effektive Art der Überprüfung.

Montag, 22. Januar 2024

Täglich grüßt das Murmeltier - ungewollte Folgen agilen Managements

Als sich abgezeichnet hat, dass ich die Konferenz Manage Agile 23 verpassen werde, war ich enttäuscht, und zwar vor allem aus einem Grund: ich hatte mich auf die Keynote von Stefan Kühl gefreut, einem Professor der Soziologie und bekannten Beobachter und Kritiker der agilen Bewegung. Aber jetzt ist wieder alles gut, denn Summit (der Konferenzveranstalter) hat das Video veröffentlicht, und wie erwartet ist es sehenswert und unterhaltsam.



Inhalt seiner Ausführungen ist, dass er die Eigenschaften von Management-Moden herausarbeitet und die agile Bewegung auf sie überprüft. Sein Fazit: die Kriterien sind gegeben, Agile ist eine Mode. Und er wagt sogar eine Prognose: in fünf Jahren wird sie vorbei sein. An der Stelle kann man gespannt sein ob er recht behalten wird, nicht zuletzt mit Blick auf die Geschichte: das Ende der Agilität wird seit fast einem Vierteljahrhundert vorhergesagt, ohne das es bisher dazu gekommen ist (und dass ich die Klassifizierung als Management-Mode nicht teile habe ich bereits woanders aufgeschrieben). Trotz allem: sehens- und hörenswert.

Donnerstag, 18. Januar 2024

300 agile Zertifizierungen

Als ich vor einigen Jahren eine Übersicht über die mir bekannten agilen Zertifizierungen erstellt habe, war das im Wesentlichen der Zeitverteib für einige unfassbar langweilige Calls, in denen ich damals sitzen musste. Mit der Zeit hat sie sich dann zu einem Belegstück für den Agil-Industriellen Komplex entwickelt, durch dessen Zusendung ich bis heute andere Menschen schockieren kann. Da ich gelegentlich danach gefragt wurde ist hier ein Update.

Wie letztes mal ist es ohne Anspruch auf Vollständigkeit, einige Beobachtungen kann man aber machen. Es sind noch einmal mehr geworden (über 300 statt 240), es sind Anbieter verschwunden und andere sind dazugekommen. Einige Titel befinden sich hart an der Grenze zur Realsatire (z.B. "Scrum Developer Instructor" und "Agile PeopleOps Agility") und einige Zertifizierungsorganisationen haben verwirrend ähnliche Namen (z.B. die Agile Coach Alliance und die Agile Coaches Alliance).

Eine interessante Entwicklung ist, dass einige Zertifizierungen umbenannt wurden. Man kann spekulieren, dass das letzte mit den Gerichtsprozessen zwischen den verschiedenen Anbietern zu tun hat (am bekanntesten dürfte der zwischen Scrum Alliance und Scrum Inc sein), die Teil der Auseinandersetzungen um diesen Millionenmarkt sind. Mal sehen ob es auch bei den ähnlichen Namen der Zertifizierungsorganisationen dazu kommt.

Organisation Zertifizierungen Auflistung
International Consortium for Agile 26
  • Agile Fundamentals
  • Business Agility Foundations
  • Leading with Agility
  • People Development
  • Enterprise Agile Coaching
  • Coaching Agile Transformations
  • Expert in Enterprise Coaching
  • Agile Team Facilitation
  • Agile Coaching
  • Expert in Agile Coaching
  • Agile Product Ownership
  • Product Management
  • Agile Project and Delivery Management
  • Delivery at Scale
  • Agile Programming
  • Agile Software Design
  • Foundations of DevOps
  • Implementing DevOps
  • Agile Testing
  • Agile Test Automation
  • Agility in HR
  • Adaptive Org Design
  • Agility in Finance
  • Lean Portfolio Management
  • Agility in Marketing
  • Systems Coaching
CertiProof 22
  • Scrum Master Professional Certification
  • Scrum Product Owner Professional Certification
  • Scrum Developer Professional Certification
  • Scrum Advanced Professional Certification
  • Agile Leader Professional Certification
  • Agile Coach Professional Certification
  • Business Agility Professional Certification
  • Agile HR Certified Professional
  • User Stories Foundations Certificate
  • Business Model Canvas Professional Certificate
  • Design Thinking Professional Certification
  • Design Sprint Professional Certification
  • Lean Product Discovery Certification
  • DevOps Essentials Professional Certification
  • DevOps Foundation Professional Certification
  • DevOps Advanced Professional Certification
  • DevOps Culture Practitioner Certification
  • DevOps Culture Certified Trainer
  • OKR Master Professional Certification
  • OKR Champion Professional Certification
  • OKR Certified Professional
  • Kanban Essentials Professional Certification
Scrum Alliance 16
  • Certified Scrum Master
  • Advanced Certified Scrum Master
  • Certified Scrum Professional - Scrum Master
  • Certified Scrum Product Owner
  • Advanced Certified Scrum Product Owner
  • Certified Scrum Professional - Product Owner
  • Certified Scrum Developer
  • Advanced Certified Scrum Developer
  • Certified Scrum Professional - Developer
  • Certified Team Coach
  • Certified Enterprise Coach
  • Certified Scrum Trainer
  • Certified Agile Leadership Essentials
  • Certified Agile Leadership for Teams
  • Certified Agile Leadership for Organizational Leaders
  • Agile Coaching Skills - Certified Facilitator
Scrum.org 14
  • Professional Scrum Master I
  • Professional Scrum Master II
  • Professional Scrum Master III
  • Professional Scrum Product Owner I
  • Professional Scrum Product Owner II
  • Professional Scrum Product Owner III
  • Professional Scrum Developer
  • Scaled Professional Scrum
  • Professional Scrum with Kanban
  • Professional Scrum with User Experience
  • Professional Agile Leadership
  • Professional Agile Leadership - Evidence Based Management
  • Professional Facilitation Skills
  • Professional Backlog Management Skills
EXIN 14
  • Agile Scrum Foundation
  • Agile Scrum Master
  • Agile Scrum Product Owner
  • Agile Scrum Product Owner Bridge
  • Agile Coach
  • Agile Business Professional
  • Agile Service Manager
  • Integrator in Agile Service Projects
  • Kanban Foundation
  • DevOps Foundation
  • DevOps Professional
  • DevOps Master
  • DevSecOps Manager
  • Lean IT Leadership
Agile Coaches Alliance 14
  • Accreditation of Progress for Agile Organizations
  • Accreditation of Progress for Scrum Teams
  • Accreditation of Practical knowledge for Scrum Masters
  • Accreditation of Practice for Scrum Masters
  • Accreditation of Excellence for Scrum Masters
  • Accreditation of Practical Knowledge for Product Owners
  • Accreditation of Practice for Product Owners
  • Accreditation of Excellence for Product Owners
  • Accreditation of Practice for Agile Leaders
  • Accreditation of Excellence for Agile Leaders
  • Accreditation of Practice for Agile Developers
  • Accreditation of Excellence for Agile Developers
  • Accreditation of Practice for Agile Advisors
  • Accreditation of Excellence for Agile Advisors
Scaled Agile Framework 13
  • Leading SAFe
  • Implementing SAFe
  • SAFe for Teams
  • SAFe Product Owner/Product Manager
  • SAFe Scrum Master
  • Advanced SAFe Scrum Master
  • SAFe Release Train Engineer
  • SAFe Lean Portfolio Management
  • SAFe Agile Product Management
  • SAFe for DevOps
  • SAFe for Architects
  • SAFe for Government
  • SAFe Agile Software Engineering
DevOps Institute 13
  • DevOps Foundation
  • DevOps Engineering Foundation
  • DevOps Observability Foundation
  • Site Reliability Engineering Foundation
  • Site Reliability Engineering Practitioner
  • DevSecOps Foundation
  • DevSecOps Practitioner
  • DevOps Leader
  • Certified Agile Service Manager
  • Continuous Testing Foundation
  • Continuous Testing Practitioner
  • Value Stream Management Foundation
  • Value Stream Management Practitioner
Kanban University 12
  • Team Kanban Practitioner
  • Kanban Management Professional
  • Enterprise Kanban Management Professional
  • Scrum Kanban Practitioner
  • Kanban Product Professional
  • Kanban Leadership Professional
  • Kanban Coaching Professional
  • Accredited Kanban Consultant
  • Accredited Kanban Trainer
  • Legal Kanban Practitioner
  • Customer Experience Professional
  • Enterprise Services Planning Professional
International DevOps Certification Academy 12
  • Certified DevOps Generalist
  • Certified DevOps Executive
  • Certified DevOps Project Manager
  • Certified DevOps Product Owner
  • Certified DevOps Architect
  • Certified DevOps Developer
  • Certified DevOps Operations Engineer
  • Certified DevOps Quality Assurance Engineer
  • Certified DevOps Information Security Engineer
  • Certified DevOps Release Manager
  • Certified DevOps Trainer
  • Certified DevOps Coach
Scrum Institute 12
  • Scrum Team Member Accredited Certification
  • Scrum Developer Accredited Certification
  • Scrum Master Accredited Certification
  • Scrum Product Owner Accredited Certification
  • Scaled Scrum Expert Accredited Certification
  • Agile Scrum Leadership (Executive) Accredited Certification
  • Scrum Trainer Accredited Certification
  • Agile Coach Accredited Certification
  • Certified Kanban Expert Certification
  • Certified Kanban Project Manager Certification
  • Certified Professional in Design Thinking Certification
  • Certified Professional in OKR Certification
ScrumStudy 10
  • Scrum Fundamentals Certified
  • Scrum Developer Certified
  • Scrum Master Certified
  • Scaled Scrum Master Certified
  • ScrumStudy Agile Master Certified
  • Scrum Product Owner Certified
  • Scaled Scrum Product Owner Certified
  • Expert Scrum Master Certified
  • Scrumstudy Certified Trainer
  • Scrumstudy Certified Agile Coach
Industrie- und Handelskammern1 9
  • Agiler Projektmanager IHK
  • Agiles Projektmanagement IHK
  • Agiler Personalentwickler IHK
  • Agiler Business Coach IHK
  • Agiler Team Coach IHK
  • Agiler Change Manager IHK
  • Agile Führungskraft IHK
  • Fachkraft für agile Führung IHK
  • Agiler Mindsetter IHK
EuropeanScrum 9
  • Certificate in Scrum Foundations
  • Certificate in Scrum Master
  • Certificate in Product Owner
  • Certificate in Agile HR
  • Certificate in Agile Coach
  • Certificate in Kanban
  • Certificate in Design Thinking
  • Certificate in Visual Thinking
  • Certificate in Lean Foundations
Scrum Inc 8
  • Registered Scrum Team Member
  • Registered Scrum@Scale Practitioner
  • Registered Scrum Master
  • Registered Scrum Master@Scale
  • Registered Scrum Product Owner
  • Registered Scrum Product Owner@Scale
  • Registered Agile Leader@Scale
  • Registered Agile Coach
Flight Levels Academy 8
  • Introduction to Flight Levels
  • Flight Level 2 Design
  • Flight Level 3 Design
  • Flight Levels Systems Architecture
  • Flight Levels Change Leadership
  • Flight Levels Coach
  • Flight Levels Data Driven Improvement
  • Flight Levels Dependency Management
Scrum Agile Institute 8
  • Scrum Master Certified
  • Scrum Master Instructor
  • Scrum Product Owner Certified
  • Product Owner Instructor
  • Scrum Developer Certified
  • Scrum Developer Instructor
  • Agile Scaled Certified
  • Agile Scaled Instructor
Agile Academy 8
  • Certified Agile Coach
  • Certified Agile Coach Advanced
  • Certified Agile OKR Coach
  • Certified Agile Facilitator
  • Certified Agile Kanban Coach
  • Certified Agile Leadership Coach
  • Certified Agile Trainer
  • Certified Design Thinking Coach
DevOps Agile Skills Association 7
  • DevOps Fundamentals
  • DevOps Professional Enable and Scale
  • DevOps Professional Specify and Verify
  • DevOps Professional Create and Deliver
  • DevOps Product Owner
  • DevOps Leader
  • DevOps Coach
APM Group International 7
  • Agile Digital Services
  • Agile Programme Management
  • Agile Project Management
  • Agile Agile Business Analysis
  • Agile Project Management for Scrum
  • Agile Change Agent
  • Agile Scrum Certification
ProKanban 6
  • Professional Kanban Level I
  • Professional Kanban Level II
  • Professional Flow Metrics Fundamentials
  • Professional Applied Metrics
  • Professional Flow Metrics for Scrum
  • Scaling with Portfolio Kanban
Large Scale Scrum2 5
  • Certified LeSS Basics
  • Certified LeSS Practitioner
  • Certified LeSS for Executives
  • Certified LeSS Trainer
  • LeSS-Friendly Scrum Trainer
OpenSpace Agility Framework 5
  • Open Space Agility Level 1
  • Open Space Agility Level 2
  • OpenSpace Technology Level 1
  • OpenSpace Technology Level 2
  • Open Space Agility Certified Trainer
Project Management Institute 5
  • PMI Agile Certified Practitioner
  • Disciplined Agile Scrum Master
  • Disciplined Agile Senior Scrum Master
  • Disciplined Agile Value Stream Consultant
  • Disciplined Agile Coach
Lean Change 4
  • Lean Change Foundations
  • Change Agilist
  • Coaching Agile Transitions
  • Enterprise Agile Coaching
Agile Coach Alliance 4
  • Certified Agile Coach
  • Certified Agile HR
  • Certified Agile Trainer
  • Certified Agile Coach Trainer
Agile Marketing Academy 4
  • Certified Agile Marketing Specialist
  • Certified Agile Marketing Practitioner
  • Certified Agile Marketing Coach
  • Certified Agile Marketing Trainer
Agile PeopleOps Framework
4
  • Agile PeopleOps Agility
  • Agile PeopleOps Business Partner
  • Agile PeopleOps Practitioner
  • Agile PeopleOps Coaching
AgilityHealth 4
  • Certified AgilityHealth Facilitator
  • Continuous Improvement Champion
  • Agility OKR Champion
  • Enterprise Business Agility Strategist
International Business and Quality Management Institute 4
  • Certified Kanban Coach
  • Approved Kanban Professional
  • Certified Scrumban Practitioner
  • Certified DevOps Manager
OKR Institute 4
  • OKR Foundation
  • OKR Practitioner
  • OKR Professional
  • OKR Leader
EduScrum 4
  • EduScrum Level 1
  • EduScrum Level 2
  • EduScrum Level 3
  • EduScrum Train the Trainer
TÜV3 4
  • Agiles Projektmanagement
  • Scrum Foundation Zertifikat
  • Scrum Master Zertifikat
  • Product Owner Zertifikat
Axelos 3
  • Prince2 Agile Foundation
  • Prince2 Agile Practitioner
  • AgileShift Certification
Alliance for Qualification 3
  • Design Thinking Foundation
  • Practitioner in Agile Quality
  • Certified Agile Business Analysis
International Association of Project Managers 3
  • Certified Junior Agile Project Manager IAPM
  • Certified Agile Project Manager IAPM
  • Certified Senior Agile Project Manager IAPM
Ineko Institut (Universität Köln) 3
  • Basic Agile Master
  • Experienced Agile Master
  • Systemic Agile Master & Coach
International Software Testing Qualifications Board 2
  • Foundation Level Agile Tester
  • Advanced Level Agile Technical Tester
  • Agile Test Leadership at Scale
International Software Quality Institute 3
  • Certified Agile Essential
  • Certified Agile OKR Master
  • Scrum Master Pro
OKR Consortium 3
  • Certified OKR Practitioner
  • Certified OKR Coach
  • Certified OKR Executive
British Computer Society - The Chartered Institute for IT 2
  • Foundation Certificate in Agile
  • Foundation Certificate in DevOps
International Requirements Engineering Board 2
  • Re@Agile
  • Re@Agile Advanced Level
KPI Institute 2
  • Certified Agile Strategy Execution
  • Certified OKR Professional
IT Service Management Academy 1
  • Certified Agile Service Manager
DEKRA 1
  • Agiles Projektmanagement mit Scrum
1Zertifizierungslehrgänge verschiedener Kammern
2Der LeSS-Friendly Scrum Trainer ist eine Erweiterung des Certified Scrum Trainer der Scrum Alliance
3Zertifizierungslehrgänge verschiedener TÜV-Gesellschaften

Montag, 15. Januar 2024

Dunning, Kruger & KI

Dass die allgemeine Verfügbarkeit von KI-Anwendungen (KI = künstliche Intelligenz) die Arbeitswelt in kurzer Zeit stark verändert hat, ist ein Allgemeinplatz, welche Veränderungen das sind, ist im Einzelfall aber doch immer wieder überraschend. So gehört anscheinend zu ihnen, dass die Nutzung von KI zu einem verstärkten Auftreten des Dunning-Kruger Effektes führen kann, also zu einer unrealistisch guten Selbsteinschätzung, gerade dann wenn eigentlich das Gegenteil der Fall ist.


Nachlesen kann man das aktuell in einer Studie des IT-Sicherheits-Providers Snyk, die auf Interviews mit 500 Entwicklern beruht, schon etwas älter (von 2022) ist eine Meta-Studie der Stanford University, die die Forschungsergebnisse mehrerer amerikanischer und kanadischer Wissenschaftler zusammenfasst. Ohne David Dunning, Justin Kruger oder ihr Paper Unskilled and unaware of it beim Namen zu nennen, beschreiben sie genau das, was den nach ihnen benannten Effekt ausmacht.


Zum Hintergrund: es gibt systemische Gründe, wegen denen der von KI-Tools generierte Code oft schlecht ist. Anders als von Laien angenommen lernen diese Programme nicht selbst, sondern werden von Menschen trainiert, und zwar aus Kostengründen von Billigkräften aus Afrika oder Asien. Bei einfachen Wissensfragen oder Bildgenerierungen funktioniert das auch gut, beim Überprüfen von Quellcode kommen Menschen dieses Gehalts- (und damit Bildungs-)Niveaus aber schnell an Grenzen.


Die Grundlage dieser Trainings ist (vereinfacht gesagt) aller im Internet stehender Code, der natürlich in weiten Teilen schon älter ist. Der auf dieser Basis generierte neue Code ist daher nicht in dem Sinn schlecht, dass er nicht funktioniert (das würde dann doch auffallen), er ist es in dem Sinn, dass er an veralteten Architektur- und Sicherheitsstandards ausgerichtet ist und die so erzeugten Programme aus diesem Grund schwerer verständlich, aufwändiger in der Wartung oder einfacher zu hacken sind.


Statt sich dessen bewusst zu sein, herrschte bei den an den Untersuchungen teilnehmenden Entwicklern aber mehrheitlich die genau gegenteilige Meinung vor: sie waren davon überzeugt, dass der Code, den sie sich von ihrer KI (z.B. von Github Copilot oder Facebook InCoder) hatten generieren lassen, modern, gut lesbar und sicher wäre. Und genau das, die unrealistisch hohe Meinung über die Qualität eher dürftiger eigener  Arbeitsergebnisse, ist der Dunning Kruger Effekt.


Die genauen Gründe, aus denen dieser Effekt in genau diesem Kontext auftritt, sind in den genannten Studien nicht erforscht (und es ist auch fraglich, ob ihre Identifizierung so einfach möglich wäre), einen vermutlich nicht unwichtigen Faktor hat aber Rebecca Parsons, der CTO von Thoughtworks, beschrieben: die Antworten der Chatbots sind immer so formuliert, dass sie den Eindruck zweifelloser Richtigkeit erwecken. Das kann dazu führen, dass diese dann auch vom Anwender angenommen wird.


Die Lehre die man daraus ziehen kann ist, dass gerade KI-generierter Code mit grosser Vorsicht behandelt und möglichst sorgfältig reviewt werden sollte, bevor er irgendwo integriert und deployed wird. Das führt zwar dazu, dass die Menge der Arbeit, die man an eine künstliche Intelligenz delegieren kann gefühlt weniger wird, dafür ist das Ergebnis aber auch besser und sicherer. Und auch das gehört zu Dunning Kruger dazu - wenn man gemerkt hat, dass man betroffen ist, geht der Effekt zurück.