Freitag, 14. Juni 2024

Newton’s Flaming Laser Sword (Alder's Razor)

Marketing ist alles, das trifft auch auf Leitsätze oder Leitprinzipien zu. Das vielleicht beste Beispiel dafür trägt den schönen Namen Newton’s Flaming Laser Sword (Isaac Newtons brennendes Laser-Schwert), verfasst 2004 vom australischen Mathematik-Professor Mike Alder in einem Artikel in der Zeitschrift Philosophy Now. Dieses Leitprinzip hat aber nicht nur einen bemerkenswerten Namen, es ist auch eines, das inhaltlich sinnvoll ist.


Der Hintergrund der Entstehung dieses Prinzips, war, dass Alder in Diskussionen zunehmend davon genervt war, dass Hypothesen erstellt oder Meinungen geäussert wurden, die so formuliert waren, dass sie nicht beweisbar oder widerlegbar waren. Konkret nannte er das Beispiel eines Philosophie-Professors seiner Univerität, der behauptete, künstliche Intelligenz könnte es nicht geben, da alles was künstlich wäre, keine Intelligenz sein könnte.1


Sein als Erwiederung darauf gedachter Artikel ist zum einen ein seitenlanger Rant gegen dieses seiner Meinung nach unwissenschaftliche Vorgehen, zum anderen aber auch ein Verweis auf eine lange Reihe von Forschern und Wissenschaftlern, die gezeigt haben wie es besser geht, und die ihre Annahmen und Thesen überprüfbar und damit wiederlegbar gemacht haben. Besonders berief er sich dabei auf den englischen Physiker, Astronom und Mathematiker Isaac Newton.


Newton made his philosophical method quite clear. If Newton made a statement, it was always going to be something which could be tested, either directly or by examining its logical consequences and testing them. If there was no way of deciding on the truth of a proposition except by interminable argument and then only to the satisfaction of the arguer, then he wasn’t going to devote any time to it.
Mike Alder: Newton’s Flaming Laser Sword, Philosophy Now, May/June 2004


Übersetzt: wenn Behauptungen oder Annahmen gemacht werden, dann sollten es nur solche sein, die entweder durch eine Überprüfung oder durch logische Schlussfolgerungen bestätigbar oder widerlegbar sind. Wenn beides nicht möglich ist, und eine Diskussion über den Wahrheitsgehalt nur dadurch zu gewinnen ist, dass eine der Diskussionsparteien irgenwann erschöpft aufgibt, dann sollte man gar nicht erst anfangen, derartige Diskussionen zu führen.


Um den Bekanntheitsgrad dieses Denkansatzes zu fördern und um aufzuzeigen, dass er im Vergleich zum verwandten Konzept von Occam's Razor ein wesentlich schärferes Instrument darstellte, suchte Alder zuletzt noch nach einem eingängigen Namen für seine Schöpfung. Newton’s Flaming Laser Sword sollte genau das sein. Und zumindest in akademischen Kreisen und unter den Lesern des Magazins erreichte er damit auch schnell sein Ziel.


All good principles should have sexy names, so I shall call this one Newton’s Laser Sword on the grounds that it is much sharper and more dangerous than Occam’s Razor. In its weakest form it says that we should not dispute propositions unless they can be shown by precise logic and/or mathematics to have observable consequences. In its strongest form it demands a list of observable consequences and a formal demonstration that they are indeed consequences of the proposition claimed.
Mike Alder: Newton’s Flaming Laser Sword, Philosophy Now, May/June 2004


Kommen wir zur Übertragung in die Praxis, mit besonderer Berücksichtigung eines spezifischen Kontext: des Change Management. Auch hier gibt es immer wieder axiomatische Aussagen, etwa die, dass Angestellte die nicht kontrolliert werden aufhören würden zu arbeiten, oder die, dass durch die Gewährung von Selbstorganisation automatisch alles besser werden würde. Die Diskussionen darüber, ob das stimmt, sind häufig zutiefst philosophisch.


Newton’s Flaming Laser Sword kann derartige Debatten schnell beenden. Wann immer derartige Vermutungen oder Annahmen aufgestellt werden kann man fragen, ob es empirische Belege für sie gibt, bzw. ob es Möglichkeiten gibt, sie durch Empirie zu validieren. Wenn die Antwort auf beides Nein ist, kann ein Weiterführen der Diskussion zu keinem wirklichen Erkenntnisgewinn führen. Ist die Antwort dagegen Ja, kann die Unterhaltung auf die Zeit nach der Validierung vertagt werden.2


Vor allem in sehr debattenlastigen Umgebungen kann es sehr hilfreich sein, sich auf die Nutzung von Newton’s Flaming Laser Sword zu einigen. Sowohl die Länge als auch die empfundene Sinnlosigkeit vieler Diskussionen geht dann deutlich zurück. Und für alle, denen der Name nicht seriös genug erscheint, gibt es eine alternative Bezeichnung: Alder's Razor, benannt nach Mike Alder selbst. Das klingt neutraler, ist aber inhaltlich identisch.



1Ganz nebenbei: dass Alder in diesem Artikel auch davon berichtet, bereits 2004 eine "halluzinierende" künstliche Intelligenz gehabt zu haben, zeigt auf, wie lange es dieses Phänomen bereits gibt
2Was natürlich die Bereitschaft voraussetzt, diese Validierungen zeitnah vorzunehmen

Dienstag, 11. Juni 2024

Agile Success Stories: Ein Kanban-Board mit 19 Spalten

Es ist mal wieder Zeit für eine Agile Success Story. 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, das kann man viel zu oft bei Agile Coaches, Scrum Mastern und ähnlichen Rollen erleben. Um nicht selbst in dieses Muster verfallen, möchte ich dagegenhalten, indem ich selbst erlebte "agile Erfolgsgeschichten" veröffentliche, heute eine zum Thema Kanban.


Eigentlich hatte ich den Auftrag gar nicht annehmen wollen. Insgesamt sieben verschiedene Abteilungen eines Kunden wollten "ihre Zusammenarbeit agiler machen", davon drei Fachabteilungen, zwei aus der IT, eine aus Operations und eine aus dem Einkauf. Das klang als Herausforderung durchaus spannend, das Problem war aber das Budget - für eine Woche in Vollzeit würde es reichen, danach nur noch für vier Tage pro Monat während des restlichen Jahres. Im Grunde viel zu wenig.


Am Ende liess ich mich darauf ein, wenn auch mit einer klaren Einschränkung: in dieser knappen Zeit würde zu Beginn kaum mehr möglich sein als die Ermittlung und Visualisierung des Value Streams, und in späteren wöchentlichen Terminen ein Inspect & Adapt in kleinen Schritten. Die urspünglich vom Kunden gewünschte Einführung eines agilen Skalierungsframeworks wäre mit diesem geringen Aufwand illusorisch gewesen. Das wurde angenommen, also legten wir los.


Bereits das Value Stream Mapping war dann anspruchsvoll genug. Es handelte sich um eine geschäftskritische Anwendung, die auf Wunsch interner und externer Stakeholder ständig weiterentwickelt wurde. Neue Features wurden jeweils von einer der drei Fachabteilungen beauftragt und entweder von einer der beiden internen IT-Abteilungen oder durch externe Dienstleister (koordiniert durch den Einkauf) entwickelt.


Das, was dieses Vorgehen schwierig machte, waren Unübersichtlichkeit und Intransparenz. Es gab so viele Feature Requests (die natürlich alle dringend waren), dass niemand einen Gesamtüberblick darüber hatte, welche internen oder externen Entwickler gearde im Auftrag welcher Fachabteilung etwas umsetzten. Das Ergebnis waren redundante Arbeiten, die Entwicklung inkompatibler Features, ständige Nacharbeiten, zu hohe Arbeitsbelastung und ständig gerissene Deadlines.


Nach einer Woche intensiven Nachforschens gab es dann ein erstes Ergebnis: abhängig von den beiden Variablen bestehendes/neues Budget und interne/externe Entwicklung liessen sich drei Varianten des Value Streams identifizieren, eine mit 10 Stationen, eine mit 15 und eine mit 19 (!). Da das bei weitem zu viel war um auf einem Bildschirm überblickbar zu sein, fand die Visualisierung in Form eines physischen Kanban-Boards statt - Drei Zeilen mit jeweils 10, 15 und 19 Spalten.1


Bis zu unserem ersten Einzeltermin hatten die verschiedenen Einheiten sich dann die Aufgabe mitgenommen, alle grösseren Arbeitspakete an denen sie gerade sassen auf dieses Board zu bringen. Als ich nach einer Woche zurückkam war ich erstmal erschlagen - mehr als 60 verschiedene Zettel hingen über das ganze Board verstreut, jeder einzelne davon als Symbolisierung eines Gesamtaufwandes von mindestens einer Personenwoche. Kein Wunder, dass bisher die Übersicht gefehlt hatte.


Eigentlich hatte ich als nächstes vor diesem Board ein Daily etablieren wollen, was aber in einem lauten Proteststurm unterging ("Nicht noch mehr Meetings", wurde gefordert). Worauf sich alle einlassen konnten war aber ein wöchentlicher Termin, in dem Vertreter der sieben Abteilungen alles was in den letzten Tagen stattgefunden hatte auf dem Board aktualisierten, egal ob es neue Requests, Entwicklungsfortschritte, Budget-Zusagen oder sonst etwas waren.


Was in diesen Terminen auffällig war, war, dass nahezu jede Aktualisierung eine mittelgrosse Diskussion auslöste. Deren Inhalte reichten von Überraschung und Interesse über Zustimmung und Feedback bis hin zu Protest und Sinnfragen. Nahezu jeder der teilnahm hatte irgendetwas zu irgendeinem Thema beizutragen, so dass es regelmässig mehr als zwei Stunden dauerte, bis auf dem Board alles auf den aktuellen Stand gebracht war.2


Das wirklich Bemerkenswerte an diesen "Kanban Weeklies" war aber nicht ihre Länge. Anders als man es hätte erwarten können gab es kaum Beschwerden darüber, dass in sie so viel Zeit investiert werden musste oder dass in ihnen so viele Themen diskutiert wurden. Stattdessen wurde regelmässig hervorgehoben, wieviel grösser durch sie Transparenz, Übersichtlichkeit und als Folge dessen auch Planbarkeit und Reaktionsfähigkeit geworden wären.


Gleich mehrfach konnten neue Feature Requests einzelner Fachabteilungen bereits im Anbahnungsstatus gestoppt werden, weil eine der anderen darauf hinwies, etwas Vergleichbares bereits beauftragt zu haben. Die Entwicklungsabteilungen konnten besser absehen, wann grössere Arbeitspakete bei ihnen einschlagen würden und sich entsprechend Zeit einplanen. Die Operations-Abteilung konnte sich auf Lastspitzen durch neue Features besser einstellen. Etc, etc, etc.


Selbst wenn es WIP-Limits, Service-Klassen, Durchlauf-Metriken und viele andere Ideen die ich hatte aufgrund des beschränkten Zeitbudgets nicht mehr in dieses Kanban-System geschafft haben, wurden das Board uns seine Benutzung von allen Beteiligten als eine spürbare Verbesserung gesehen, durch die die meisten der oben genannten Probleme (redundante Arbeit, Intransparenz, ständige Nacharbeiten, etc.) spürbar zurückgegangen waren.


Auch ich habe aus diesem Einsatz eine Lehre mitgenommen: auch eine punktuelle Begleitung kann unter Umständen völlig ausreichend sein. Es braucht nicht immer einen Scrum Master, Kanban Coach oder sonstigen Methodiker, der in Vollzeit ein Team begleitet, manchmal kann es genügen, den Arbeitsfluss zu visualisieren, alle Beteiligten dazu zu bewegen ihn sich regelmässig gemeinsam anzusehen und darauf zu vertrauen, dass sich daraus die richtigen Dinge ergeben werden.


Und eine zweite Erkenntnis (die ich aber bereits vorher hatte) gebe ich noch dazu. Ab einer bestimmten Grösse sollten Kanban-Boards in physischer Form aufgebaut werden, eines wie das hier beschriebene könnte man auf keinem Bildschirm auch nur annäherungsweise übersichtlich darstellen. Um eines meiner Lieblingszitate zu bringen: "When you put a problem in a computer, the box hides the answer. The problem must be visible!"



1Also deutlich mehr als auf dem Symbolbild auf dieser Seite
2Ich meine mich sogar an einen Termin erinnern zu können, der mehr als vier Stunden dauerte

Freitag, 7. Juni 2024

Scrum goes Pop Music (IV)

Kaum schaut man zwei Jahre nicht hin, schon veröffentlicht jemand neue Musik. Chad Beier ist seinem Hobby treu geblieben und hat weitere, auf das Thema der agilen Produktentwicklung umgetextete, Coverversionen bekannter Pop- und Rockhits aufgenommen (siehe hier, hier, hier und hier). Wunderbar geeignet für die Party nach dem nächsten erfolgreichen Release.




Dienstag, 4. Juni 2024

Der Harmont-Effekt

Bevor wir heute in die Business-Welt eintauchen, gibt es einen kleinen Ausflug in die Weltliteratur: wir werfen einen kurzen Blick in den Science Fiction-Roman Picknick am Wegesrand, von den legendären Brüdern Arkadi und Boris Strugazki. Er spielt in der fiktiven amerikanischen Stadt Harmont, in der Jahre zuvor Ausserirdische mit einer unbekannten Mission gelandet sind, nach deren Abschluss sie den Planeten Erde wieder verlassen haben.


Inhaltlich dreht sich der Roman um den Umgang der Menschen mit verschiedenen rätselhaften Objekten, die die Ausserirdischen zurückgelassen haben. Sie sind hoch entwickelt und hübsch anzusehen, der Versuch sie zu benutzen ist aufgrund des fehlenden Wissens um ihre Funktionsweise aber hochriskant und endet für die Menschen oft mit Verletzungen oder Unfällen. Und damit genug von der Literatur und zurück ins Business.


Auch in grossen Unternehmen und Behörden gibt es das Phänomen, dass von ausserhalb kommende Besucher rätselhafte Hinterlassenschaften zurückgelassen haben, von denen keiner genau weiss wie sie funktionieren und deren Benutzung für jeden der es versucht riskant ist. In Anlehnung an Picknick am Wegesrand, bzw. an dessen fiktiven Hadlungsort, beschreibe ich die Entstehung dieser Hinterlassenschaften gerne als den Harmont-Effekt.


Was das für von ausserhalb kommende Besucher sind? Verschiedene, aber die vermutlich wichtigste Gruppe unter ihnen dürften ganz klar die Strategieberatungen sein, die einfliegen, auf Topmanagement-Ebene ihre Ideen verkaufen, und wieder abfliegen ohne sich an der Umsetzung zu beteiligen (oder genau zu wissen wie das ginge). Klassische Strategieberatungs-Hinterlassenschaften sind SpotiSafe und OKRs, die irgendwie auf bestehende Strukturen gekippt werden und dort alles verbürokratisieren.


Die zweite Gruppe sind die Vertreter grosser Standardsoftware-Hersteller, deren Versprechen darin besteht, dass ihr Produkt zwar nicht alle, zumindest aber viele Probleme lösen könnte. Sobald diese Systeme dann angewandt werden sollen, beginnen aber die Schmerzen der inkompatiblen Formate und Workflows, verbunden mit fehlendem Wissen über Konfigurierbarkeit und Erweiterungen. Klassische Hinterlassenschaften dieser Art sind Systeme von SAP, Atlassian, Salesforce und ähnlichen Anbietern.


Eine dritte Gruppe sind Thought Leader und Management-Gurus, auf die der sie beauftragende Manager durch einen Konferenzvortrag oder eines ihrer Bücher aufmerksam geworden ist. Meistens sind ihre Lösungen durch Vereinfachung und Generalisierung anschlussfähig, scheitern in der Regel aber am Wissen, wo sie im Einzelfall Sinn machen und wo nicht. Klassische Thought Leader-Hinterlassenschaften sind Open Space-Formate für Meetings oder unbenutzte Flight Level-Boards.


Als letzte, aber seltenere Gruppe könnte man Manager nennen, die in anderen Unternehmen oder Unternehmensteilen beruflich sozialisiert wurden, und die jetzt versuchen, die dort erlerntern Strukturen und Prozesse auf ihre neue Umgebung zu übertragen. Oft endet das darin, dass nur noch Probleme für diese Lösungen gesucht werden, statt umgekehrt. Klassische Hinterlassenschaften dieser Art sind die "Playbooks" von Google, Amazon oder Spotify.


Die gemeinsame Ursache für diese verschiedenen Ausprägungen des Harmont-Effekts ist, dass in keinem dieser Fälle eine in die Breite gehende Vermittlung von Systemverständnis, Kontextwissen und Prozessdesign-Techniken stattgefunden hat. Stattdessen ist es jeweils eine kleine, oft nur kurzzeitig präsente Gruppe, die Hau Ruck-artig Neuerungen einführt und bereits wieder verschwunden ist, wenn sich aus der Anwendung Fragen und Probleme ergeben.


Ein besseres Vorgehen wäre es, von Beginn an so in die eigenen Mitarbeiter zu investieren, dass diese zu Problemanalyse und Lösungsentwicklung selbst in der Lage sind. Das kann auch gerne mit externer Unterstützung passieren, diese sollte aber nicht mit dem Ziel erfolgen, dass fertige Lösungen von Aussen mitgebracht werden, sondern dass sie intern bedarfsgerecht entwickelt werden können. Derartige Ergebnisse würden dann auch nicht mehr wie rätselhafte ausserirdische Hinterlassenschaften wirken.

Freitag, 31. Mai 2024

Kommentierte Links (CXIV)

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.

Christiaan Verwijs: Why Science Is Essential To Professionalize Our Community

Es ist einer der grossen Schwachpunkte der agilen Community: es gibt sehr viele starke Meinungen über das für und wieder der verschiedenen Frameworks und Praktiken, nur in den seltensten Fällen sind sie aber durch belastbare und reproduzierbare Empirie validiert. Christiaan Verwijs erklärt warum das problematisch ist, zeigt auf welche Möglichkeiten es gibt, die eigenen Ansichten mit Fakten zu untermauern und weist auf ein grundlegendes Problem hin: anders als in anderen Berufen gibt es bei Product Ownern, Scrum Mastern, Agile Coaches keine nichtkomerziellen Organisationen, die für die Einführung und Beibahaltung derartiger Arbeitsweisen sorgen könnten.

Benjamin Huser-Berta: Limit Work in Progress without Work In Progress Limits (Teil I, Teil II)

Kanban ist vermutlich das am häufigsten missverstandene agile Framework (die Debatte ob es agil oder lean ist sparen wir uns an dieser Stelle). Die meisten Menschen verwechseln es mit dem blossen Kanban-Board, und selbst die, die verstehen, dass mehr dahinter steckt, kennen darüber hinaus häufig nur die Praktik der Limitierung paralleler Arbeit. Benjamin Huser-Berta zeigt eine weitere auf, die Messung und Regulierung des Total Work Item Age (TWIA), also des durchschnittlichen Alters der im System befindlichen Arbeitspakete. Beim Durchlesen dürfte auch klar werden, warum TWIA eher unbekannt ist - damit zu arbeiten erfordert Aufwand und Disziplin.

Hauke Friederichs: Mit billiger Hightech gegen die Russen

Die Verteidigung der Ukraine gegen den russischen Angriffskrieg hat an vielen Stellen den verdrängten Fakt wieder erkennbar gemacht, dass das agile Arbeiten Wurzeln und Parallelen in der Kriegsführung hat (siehe hier, hier und hier). Hauke Friedrichs hebt am Beispiel von für die Ukraine arbeitenden deutschen Rüstungsfirmen eine weitere hervor: bei der Entwicklung von neuen Waffen- und Abwehrsystemen sind einfache, flexible Praktiken dringend nötig, wenn sie zeitnah zum Einsatz kommen sollen. Schnelle, unbürokratische Entwicklung, enger Austausch mit den Anwendern, modularer Aufbau und kontinuierliche Weiterentwicklung. Die Parallelen zur agilen Produktentwicklung sind unübersehbar.

Michael Küsters: The Scrum Master as a Trash Collector

Ein interessanter Ansatz zum Reframing der Rolle des Scrum Masters. Statt seine Rolle durch die Einführung dessen zu definieren, was Scrum einer Organisation zusätzlich hinzufügt (Rollen, Regeln, Praktiken, Meetings, etc) stellt Michael Küstern bei seiner Betrachtung in den Mittelpunkt, was der Scrum Master abschaffen sollte: Bürokratie, Redundanzen, Ineffizienz, Stress und weitere verbreitete Zeit- und Geldfresser. Mein erster Gedanke - würde sich diese Sichtweise im Management verbreiten, würde das automatisch zu einer ganz anderen Legitimation vieler Massnahmen führen.

Maarten Dalmijn: Scrum's Built-in 'Get Out of Jail Free Card' Against Criticism

Was Maarten Dalmijn hier macht, ist die Enttarnung vieler Verteidungen von schlecht funktionierendem Scrum als No true Scotsman-Fehlschlüsse. Sie alle drehen sich darum, dass angeblich nicht die Methode selbst im jeweiligen Zusammenhang unpassend war, sondern dass sie lediglich falsch oder halbherzig umgesetzt wurde. Hätte man es "richtig" gemacht, wäre alles ganz anders gekommen. Das ist natürlich bequem, geht aber an der Realität vorbei. Scrum ist nicht überall die ideale Lösung, manchmal gibt es andere Ansätze die besser passen.

Dienstag, 28. Mai 2024

Nein, das ist nicht die Unternehmenskultur

Unter Unternehmensberatern gibt es einen alten Witz: wenn man etwas über die Kultur eines Unternehmens wissen will, dann sollte man sich zuerst ihre offizielle Beschreibung zeigen lassen - denn dann weiss man zumindest wie sie nicht ist. Das ist sicher zynisch, das ist aber auch in den meisten Fällen wahr, denn die offiziellen Unternehmenskulturen stimmen nur selten mit denen, die tatsächlichen im Alltag gelebt werden, überein.


Bevor wir auf die Gründe dafür eingehen, ein kurzer Hinweis: es ist in diesem Zusammenhang egal auf welchem Weg die offizielle Unternehmenskultur entstanden ist, wie sinnvoll oder menschenfreundlich sie erscheint, wie sehr sich die Belegschaft mit ihr identifiziert oder wie stark und häufig sie betont oder verlangt wird. Es gibt strukturelle Gründe die praktisch immer dafür sorgen, dass offizielle und gelebte Kultur sich unterscheiden. Hier sind sie:


Kultur ist ausdifferenziert und nicht in wenigen Schlagwörtern beschreibbar

Die meisten offiziellen Beschreibungen von Unternehmenskulturen bestehen nur aus wenigen Werten, Prinzipien oder Umgangsregeln. Selbst wenn diese zutreffen sollten, würden sie aber nur einen Teil der jeweiligen Kultur beschreiben, zu der ausserdem noch Glaubenssätze, Verhaltens- und Deutungsmuster, mündliche Überlieferungen (wisst Ihr noch, damals in Projekt Omega ...), sprachliche Besonderheiten, Traditionen und viele weitere Dinge gehören, die insgesamt ganze Bücher füllen würden.


Kultur ist nicht nur positiv

Was praktisch alle offiziellen Kulturbeschreibungen gemeinsam haben ist, dass sie ausschliesslich positive Aspekte beschreiben: Verlässlichkeit, Solidarität, freundlicher Umgang, Leistungsbereitschaft, etc. In der Realität gehören zu praktisch jeder Kultur aber auch negative Aspekte, die häufig sogar mit den positiven zusammenhängen: Sorgfalt führt z.B. oft zu Perfektionismus, Experimentierfreude zu Unvorsichtigkeit, und so weiter. Ohne diese Aspekte sind Kulturbeschreibungen unvollständig.


Kultur ist nicht überall im Unternehmen gleich

Schon in kleinen Unternehmen existieren verschiedene (Teil-)kulturen, die sich zum Teil deutlich unterscheiden: Innendienst und Aussendienst, Entwicklung und Marketing oder Management-Ebene und Umsetzungs-Ebene weichen mitunter so stark voneinender ab, dass von einer gemeinsamen Kultur kaum noch die Rede sein kann. Und in Grossorganisationen kann jedes Ressort oder sogar jede Abteilung eine eigene Kultur haben, die mit der offiziellen nur in Teilen übereinstimmt.


Kultur ist nicht stabil

Mit anderen Worten: selbst wenn die offizielle Unternehmenskultur einmal mit der tatsächlich gelebten übereinstimmen sollte, wäre das nur eine Momentaufnahme. Kommende und gehende Kollegen, steigender Wettbewerbsdruck mit darauf folgenden Verteilungskämpfen um knapper werdende Ressourcen, technische Entwicklungen, gesellschaftliche Trends und vieles mehr tragen ununterbrochen dazu bei, dass Kultur sich verändert - weg von der offiziellen Beschreibung.


Kultur ist subjektiv

Zuletzt: egal was Teil einer offiziellen Unternehmenskultur ist, verschiedene Menschen werden diese Begriffe unterschiedlich verstehen. Gerade die häufig verwandten Schlagworte wie Respekt, Verantwortung, Offenheit, Gemeinsamkeit und Ähnliche sind so generisch, dass sich unterschiedliche Deutungen nicht verhindern lassen. Die Folge ist, dass zwar alle die Kultur mit den gleichen Worten beschreiben, das dahinterliegende Verständnis aber weit auseinandergehen kann.


Es würden sich vermutlich noch weitere Gründe dafür finden lassen, dass die offizielle und die tatsächlich gelebte Unternehmenskultur sich praktisch immer unterscheiden, aber auch aufgrund der hier bereits genannten dürfte klar sein: es ist so. Das macht die offiziellen Kulturbeschreibungen zwar nicht schlecht, es sorgt aber dafür, dass sie (wenn überhaupt) nur Teilaspekte oder Vergangenheitsformen beschreiben, und nicht das was im Alltag anzutreffen ist.


Man muss die schönen Kulturprogramme und -darstellungen auch deshalb nicht abschaffen, man kann sie durchaus beibehalten, wenn auch mit einer wichtigen Ergänzung: allen sollte bewusst sein, dass es sich bei ihnen nicht um eine aktuelle Zustandsbeschreibung handelt, sondern um ein ambitioniertes Zielbild, auf das man zwar hinarbeiten kann, das man aber nicht in Gänze oder dauerhaft erreichen kann. Wenn alle sich auf dieses ständige gemeinsame Hinarbeiten einigen, dann hat eine offizielle Unternehmenskultur einen Sinn. Sonst nicht.

Donnerstag, 23. Mai 2024

Deine Muda: Overthinking

Bild: Pexels / Thirdman - Lizenz

Zehnter Teil der Deine Muda-Serie. Neben den sieben klassischen Mudas (無駄), also den nicht gewinnbringenden (und aus diesem Grund zu vermeidenden) Tätigkeiten des Toyota Production System, können auch weitere Mudas identifiziert werden. Welche das sind kann je nach Unternehmen und je nach Kontext unterschiedlich sein, weshalb diese hier nicht den Anspruch erheben kann, kanonisch zu sein. Ressourcenverbrauchend und nicht gewinnbringend ist sie trotzdem: das Overthinking.


Zuerst ein Übersetzungsversuch. Für den Begriff Overthinking gibt es keine exkte Entsprechung in der deutschen Sprache, eine sinngemässe Übersetzung wäre "länger über etwas nachdenken als sinnvoll ist" oder "unverhältnismässig lange über etwas grübeln". In beiden Übersetzungs-Varianten ist die Muda-Natur bereits offensichtlich enthalten, bei näherer Betrachtung lassen sich aber ausserdem noch verschiedene Problem-Dimensionen erkennen.


Zum einen kostet ein unnötig langes Nachdenken die Beteiligten (Arbeits-)Zeit und damit ihr Unternehmen auch Geld. Das führt entweder dazu, dass sie nicht mehr für andere Tätigkeiten verfügbar sind (dazu gleich mehr) oder es hat zur Folge, dass zur Kompensation dieser Ausfälle weitere Menschen eingestellt werden müssen. Der zweite Fall wird nochmal schwerwiegender dadurch, dass diese Einstellungen (plus Koordination, Bezahlung etc.) weitere Verwaltungsaufwände erzeugen.


Zum anderen kann es zum Phänomen der Verzögerungskosten (Cost of Delay) kommen. Wird die durch das Overthinking entstehende Mehrarbeit nicht durch zusätzliches Personal kompensiert, schieben sich andere Tätigkeiten zwangsläufig nach hinten, wodurch sich Einnahmen verzögern (und dadurch kleiner ausfallen) können, Geschäfts-Chancen verschwinden können oder zusätzliche Zinsen auf alte oder neue Kredite anfallen können, die zur Kompensation ausfallender Einnahmen nötig werden.


Angesichts dieser Nachteile stellt sich die Frage, warum das Overthinking in vielen (vor allem grossen) Organisationen so weit verbreitet ist. Die Antwort kann natürlich je nach Einzelfall eine andere sein, häufige Gründe sind meiner Erfahrung nach aber Perfektionismus, Machbarkeits- und Steuerbarkeits-Illusionen, Risiko-Aversion (häufig verbunden mit knappen Budgets, deren Verwendung man unter Kontrolle halten will) und fehlende Systemsicht.


Um die nicht gewinnbringende, aber ressourcenverbrauchende Muda des Overthinking in den Griff zu bekommen, ist es daher erfolgsversprechend, zu untersuchen ob eine diese zugrundeliegenden Ursachen gegeben ist, um diese zu thematisieren und möglichst zu beseitigen. Selbst dann wenn das nicht gelingt, kann aber alleine die Erkenntnis der problematischen Effekte ausreichend sein, um ein Zurückfahren der Grübel-Aufwände auf ein sinnvolles Mass zu verursachen.

Montag, 20. Mai 2024

Agile vs Lean

Eine Frage, die unter Methodikern und Theoretikern gerne und ausgiebig diskutiert wird, die man als Berater aber auch immer wieder beim Kunden gestellt bekommt, ist die nach dem Unterschied zwischen Agil und Lean. Ist das nicht irgendwie ähnlich oder sogar identisch? Dreht sich nicht beides darum, das eigene Vorgehen durch ständige Verbesserung so zu optimieren, dass man effektiver, effizienter und reaktionsfähiger wird?


Bevor ich eine Antwort darauf versuche, ein Disclaimer: weder Agil noch Lean sind abschliessend definiert. Es gibt zwar das Manifest für agile Softwareentwicklung als zentrales Dokument, das aber nur sehr abstrakte Richtlinien vorgibt, und auf der Lean-Seite das ebenfalls nur Richtlininien vorgebene Toyota Production System. Darüber hinaus gibt es auf beiden Seiten nur noch optionale Praktiken und Sekundärliteratur. Aus all dem sind aber Definitionen ableitbar.


Der offensichtlichste Unterschied dürfte der Einsatzbereich sein. Agil wird fast ausschliesslich in der Produktentwicklung gearbeitet,1 also dort, wo sich die Herausforderungen aus (noch) unklarer Anwender-Akzeptanz, technischer Machbarkeit, etc. ergeben. Lean ist im Gegensatz dazu vor allem in der seriellen Fertigung verbreitet,2 die Herausforderungen hier sind Betrieb und Stabilisierung extrem grosser und fehleranfälliger Fertigungsstrassen, Lieferketten, o.ä.


Beiden Arten von Herausforderung wird versucht mit ähnlichen Mitteln beizukommen, die auf der agilen Seite unter dem Schlagwort Inspect & Adapt zusammengefasst werden und auf der Lean-Seite unter den Begriffen Kontinuierliche Verbesserung (KVP) oder Kaizen. Beides dreht sich um ständige Optimierungen. Was aber grundsätzlich unterschiedlich ist, ist das im Mittelpunkt dieser Bemühungen stehende Objekt: im Fall von Agil ist es das Produkt, im Fall von Lean ist es der Prozess.


Im Fall von agilem Arbeiten sieht das konkret so aus, dass in den Inspect & Adapt-Terminen entweder neue oder geplante Funktionen mit Anwender-Vertretern oder Stakeholdern begutachtet werden (z.B. im Sprint Review) oder dass in ihnen überlegt wird, was getan werden kann um diese gemeinsame Begutachtung in kurzen Zyklen zu ermöglichen oder beizubehalten (z.B. in der Retrospektive). Es können natürlich auch andere Aspekte zur Sprache kommen, die sind aber im Vergleich sekundär.


Umgekehrt geht es in den KVP- und Kaizen-Events in erster Linie darum, den Erstellungsprozess eines Produkts (oder Teilprodukts) schneller, ressourcenschonender, weniger störungsanfällig oder vorhersagbarer (in Bezug auf Durchlaufzeiten oder Wartungsintervalle) zu gestalten.3 Auch hier ist es möglich, dass Impulse für die Produktentwicklung entstehen, die werden dann aber nicht selbst realisiert sondern in die vorgelagerten (agil arbeitenden) Produktentwicklungsprozess weitergeleitet.


Wie immer gibt es natürlich auch hier Grauzonen und Uneindeutigkeiten. Wenn es z.B. im Rahmen einer auf die Fertigungsprozesse bezogenen Kostensparmassnahme dazu kommt, dass ein anderer Werkstoff verwendet wird als bisher, dann kann das auch zu einer Veränderung des Produkts führen (das dann z.B. leichter ist). Und einen "historisch gewachsenen" Begriff wie Lean Startup hätte man im Rückblick besser "Agile Startup" genannt, um Missverständnisse zu vermeiden.


Im Grossen und Ganzen ist die Gleichung Agil = kontinuierliche Produkt-Optimierung und Lean = kontinuierliche Prozess-Optimierung aber gut geeignet um zu erkennen mit was man es gerade zu tun hat. Aufbauend darauf kann es dann auch leichter werden, Handlungsfelder, Zuständigkeiten und Handlungsoptionen zu definieren, aufzuteilen oder zusammenzulegen. Auch das sollte übrigens Teil einer kontinuierlichen Optimierung sein.



1Der Begriff "Produkt" ist hier weit gefasst und enthält neben physischen Produkten auch digitale Produkte, Dienstleistungsprodukte, etc.
2Und in Umfeldern mit stark standardisierten Tätigkeiten, z.B. Systemgastronomie oder Callcenter
3Anders als man denken könnte ist das nichts womit man irgendwann fertig ist, sondern eher einen ständiges Austarieren

Donnerstag, 16. Mai 2024

Ein Bild sagt mehr als 1000 Worte (XLII)

Bild: Comic Agile - CC BY-NC 4.0

Wer agiles Arbeiten nur mit digitalen Tools kennt, wird angesichts dieses Comics vielleicht etwas ratlos sein. Alle die es mit Post Its an Wänden kennen wissen, dass er witzig ist und dass es wahr ist.

Montag, 13. Mai 2024

Das agile Mindset (II)

Bild: Pexels / Yan Krukau - Lizenz

Ein Hoch auf die Wissenschaft! Diesesmal in Person von Karen Eilers, die an der Universität Kassel eine Wirtschaftsinformatik-Dissertation mit dem klangvollen Titel The Agile Mindset – Why it Matters, What it is, and How to Measure it verfasst hat. Was sie in diesem Rahmen an Erkenntnissen gewinnen konnte und wie sie diese zusammengetragen hat, hat sie in einem ausführlichen Gespräch in dem Podcast Agile World News erzählt.



An dem hier beschriebenen Ansatz gibt es einiges, das ich bemerkenswert finde, bereits angefangen damit, dass versucht wird dem Begriff "Mindset" seine Unschärfe zu nehmen. Es wird anerkannt, dass er sehr offen interpretiert werden kann und sehr unklar zu anderen Begriffen wie "Einstellung", "Haltung" und "Mentalität" abgegrenzt ist. Die hier gewählte Definition mag vielleicht nicht jeder teilen, aber zumindest gibt es hier eine. Eine sachliche Diskussion wird dadurch überhaupt erst möglich.


Ebenfalls erwähnenswert finde ich, dass das agile Mindset (Vorhandensein, Ausprägungen, etc.) in diesem Ansatz nicht mehr etwas ist, dass von aussen durch Zuschreibung oder "Diagnose" entsteht (was dort wo man es versucht fast zwangsläufig zu übergriffigem Verhalten führt). Stattdessen wird davon ausgegangen, dass es bei allen agil arbeitenden Menschen irgendwie vorhanden ist und nur noch durch Empirie identifiziert werden muss (vereinfacht gesagt: was oft genannt wird gehört dazu).


Die vier Themengebiete, die in der Dissertation am häufigsten identifiziert wurden und die in ihr daher als typisch oder konstituierend für ein agiles Mindset gelten, sind Lern-Orientierung, kollaboratives Arbeiten, Co-Creation mit den Kunden und Selbstorganisation. Das klingt passend zu dem Arbeitsmodus, den man meistens unter der Bezeichnung "agil" vorfindet, ist aber auch darüber hinaus spannend: letztendlich handelt es sich um eine Selbstbeschreibung (und damit Selbstwahrnehmung) der agilen Community.


Lern-Orientierung

Wenig erstaunlich. Lernorientierung ist u.a. das, was man in agilen Teams auch als Growth Mindset bezeichnen würde, also die Anerkennung der Tatsache nicht alles zu wissen, die Bereitschaft sich neues Wissen anzueignen, z.B. in Reviews, Retrospektiven, etc.


Kollaboratives Arbeiten

Ebenfalls erwartbar, da in den meisten agilen Teams Teil der täglichen Arbeit: gemeinsame Meetings, gemeinsame Arbeit an Anforderungen und ähnliche Praktiken beseitigen Kopfmonopole und Flaschenhälse und machen so den Arbeitsfluss schneller und resilienter.


Co-Creation mit den Kunden

Spannend, da hier etwas (aus meiner Sicht richtigerweise) als wesentlich beschrieben wird, was in der Realität oft nur eingeschränkt stattfinden kann. Hier könnte weitergeforscht werden, ob das Wunsch oder Wirklichkeit ist (vor allem in grossen Organisationen werden oft Kunde und Auftraggeber verwechselt).


Selbstorganisation

Ebenfalls ein wichtiges und richtiges Thema, bei dem ein tieferes Erforschen interessant wäre. Obwohl sich tatsächlich praktisch alle agil arbeitenden Teams als selbstorganisiert bezeichnen dürften, sind das Verständnis dieses Begrifft und die Ausgestaltung in der Realität extrem vielfältig.


Über diese ersten Einordnungsversuche hinaus ist für mich noch etwas weiteres auffällig: die vier identifizierten Kernbereiche sind sehr stark auf den Ebenen der Einzelpersonen und der sozialen Beziehungen in Umsetzungsteams angesiedelt. Die Aspekte der technischen Agilität aus DevOps, XP, etc. und der wirtschaftsnahen Business-Agilität kommen nicht vor, was ein Hinweis darauf sein könnte, dass vor allem Scrum Master (o.Ä.) und nur wenige Entwickler und Manager befragt wurden.


Die Arbeit bietet also einiges an Erkenntnissen, aber auch einiges an weiteren Forschungspotentialen und Denkanstössen. Es ist zu hoffen, dass diese Themen in Kassel und anderswo weitergeführt werden, so dass sich die Diskussion um das agile Mindset weg von starken Meinungen und hin zu gesicherten Ergebnissen bewegen kann. Denn auch das ist etwas, was für mich zu einem agilen Mindset gehören sollte: der Drang, empiriebasiert zu arbeiten.

Donnerstag, 9. Mai 2024

Compliance & Regulatory Standards are NOT Incompatible with Modern Development

Das was Charity Majors in diesem Vortrag als "moderne Softwareentwicklung" bezeichnet, ist das was ich als Agilität bezeichnen würde: kleine Incremente schnell auf Produktion bringen um schnelles Feedback zu bekommen und schnell darauf reagieren zu können. Und genau wie ich scheint sie regelmässig mit der Aussage konfrontiert zu werden, dass das in regulierten Branchen nicht möglich wäre. Um so dankbarer kann man ihr dafür sein, dass sie klarstellt, dass das sehr wohl geht.



Für alle, die keine Geduld haben, sich die ganzen 40 Minuten ihres Videos anzusehen, habe ich eine Empfehlung: ab Minute 14:27 klickt sie sich in einem Schnelldurchlauf von 30 Sekunden durch 13 Folien, auf denen dargestellt wird, wie 13 verschiedene Firmen ihre Entwicklungsprozesse gleichzeitig modern und compliant gehalten haben (es emfiehlt sich, das Video auf jeder Folie kurz zu stoppen). Man sieht daran, dass es geht - man muss es nur wollen und machen.

Montag, 6. Mai 2024

Die Evolution der OKRs

Sobald ein agiles Framework ein gewisses Alter überschritten hat, entstehen in der Regel nach und nach verschiedene Varianten, die anfangs noch aufeinander aufbauen, später aber parallel zueinander existieren. Das ist bei Scrum und bei Kanban so gewesen, und es ist auch bei Objectives und Key Results (OKR) so. Da die neueren OKR-Varianten sich z.T. zu erstaunlich schwerfälligen Prozessframeworks entwickelt haben, lohnt ein Blick zurück - denn eigentlich ist es ursprünglich anders gedacht gewesen.


Wie immer bei derartigen Übersichten ist auch diese hier subjektiv, sie umfasst aber meiner Meinung nach die wichtigsten Spielarten und Entwicklungsstufen, bzw. die wichtigsten Vordenker. In der Realität dürften darüber hinaus noch zahlreiche Abwandlungen und Mischtypen anzutreffen sein, diese Liste hier dürfte aber die relevanten umfassen (wenn ich etwas übersehen haben sollte, freue ich mich über einen Hinweis, der hier abgegeben werden kann). Aber zur Sache, hier sind die Evolutionsstufen:


MBOSC (Management by Objectives and Self-Control)

Eine Früh- oder Vor-Version der heutigen OKRs, beschrieben in den 50er Jahren von Peter Drucker in seinem Buch The Practice of Management. Mit dezentraler Planung, Trennung von abstrakten Zielen und konkreten Ergebnissen und mit Zyklen von weniger als einem Jahr waren die Grundzüge der heutigen Praktiken bereits enthalten. Unter dem Namen Management by Objectives (MBO) wurde Druckers Ansatz leider später zu einem jährlichen Kontroll- und Budgetierungsinstrument verfremdet (siehe hier).


Ursprüngliche OKRs (Intel MBOs)

Die Ursprungsversion, entwickelt in den 70er Jahren von Intel-CEO Andy Grove und beschrieben in seinem Buch High Output Management. Grove definierte neben den abstrakten Zielen (Objectives), den konkreten Ergebnissen (Key Results) und den kurzen Zyklen (maximal ein Jahr) kaum Vorgaben zur Umsetzung, entwickelte aber schon die Idee "kaskadierender Objectives", die auf den unteren Hierarchie-Ebenen in Teilziele heruntergebrochen werden, und von denen jede eigene Key Results hat.


"Die" OKRs (Google OKRs)

Die Variante, die berühmt geworden ist. Der ehemalige Intel-Mitarbeiter John Doerr führte die OKRs bei Google ein, wo sie um weitere Teile ergänzt wurden, u.a. um die Begrenzung des Zyklus auf ein Quartal, um die Differenzierung in "committed" und "aspirational OKRs", die Einführung gemeinsamer OKRs für mehrere Teams und um eine nachträgliche Bewertung in Ampelfarben. Das von vielen anderen Firmen kopierte Google OKR Playbook findet sich abgedruckt in Doerrs Buch Measure What Matters.1


Silicon Valley OKRs

Die verschiedenen Unternehmen des Silicon Valley, die als erste den OKR-Ansatz von Google übernommenen haben, haben ihn mit der Zeit ebenfalls weiterentwickelt. Die bekanntesten Praktiken findet man zusammengefasst in Cristina Wodkes Buch Radical Focus, zu ihnen gehört u.a. die Beschränkung auf nur ein einziges, nach Möglichkeit firmenweites Objective pro Zyklus,2 die dezentrale Erarbeitung der Key Results durch die Teams und die Einführung regelmässiger OKR-Meetings.


Scrumifizierte OKRs

Wer auf die Idee gekommen ist, die OKR-Meetings analog zu denen aus Scrum zu organisieren, lässt sich vermutlich nicht mehr feststellen, aber er hat einen Trend gesetzt. OKR-Plannings, OKR-Dailies/Weeklies, OKR-Reviews und OKR-Retrospektiven sind mittlerweile weit verbreitet, und für die Organisation und Moderation dieser Termine gibt es einen an den Scrum Master oder Agile Coach angelehnten OKR Master oder OKR Coach.3


Agile Industrial Complex OKRs

Dass angessichts dieser Geschichte einer immer stärkeren Formalisierung auch das Kommerzialisierungs-Potential gestiegen ist, dürfte wenig überraschen. Der agil-industrielle Komplex hat seit ca 2020 auch die OKR-Idee mit weiteren Regeln, Rollen, Formulierungs-Templates, prozessunterstützender Software und Ähnlichem überflutet, die dann in den Trainings und Zertifizierungsprüfungen auftauchen können. Genau wie im Fall von Scrum und Kanban übrigens mit teuren aber meistens überschaubaren Ergebnissen.


Gerade vor dem Hintergrund dieser letzten "Evolutionsstufe" ist es nicht verwunderlich, dass OKRs vor allem in grossen Organisationen eher als Management-Mode wahrgenommen werden und weniger als etwas Sinnvolles. In derartigen Fällen können die hier verlinkten Grundlagen-Bücher gegebenenfalls Klarheit bringen. Aus ihnen lässt sich erkennen, was der eigentliche Kern der Idee ist, und bei was es sich um Overhead handelt, der auch weggelassen werden kann.



1Das Playbook ist übrigens nicht mehr ganz aktuell, Google hat seinen OKR-Ansatz seitdem weiterentwickelt
2Daher auch der Name des Buchs
3Möglicherweise ist der Hintergrund der, dass Scrum ursprünglich keinen mittelfristigen Planungshorizont hatte, und Scrum Teams sich diese mit Hilfe von OKRs gesetzt haben. Das wäre dann seit dem 2020 in Scrum aufgenommenen Produktziel eigentlich obsolet.

Freitag, 3. Mai 2024

Larman's Law (III)

Bild: Pixabay / kirill_makes_pics - Lizenz

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 Dritte von ihnen gehen. Es lautet:


[...] any change initiative will be derided as “purist”, “theoretical”, “revolutionary”, "religion", and “needing pragmatic customization for local concerns” - which deflects from addressing weaknesses and manager/specialist status quo.


Diese Gesetzmässigkeit, die als Ergänzung zu Larmanns erstem Gesetz gedacht ist (demzufolge Organisationen unbewusst darauf optimiert sind, Management- und Spezialistenpositionen zu schützen), ist tatsächlich eine, die in vielen, vor allem grossen, Firmen zu beobachten ist. Im Hinblick auf Veränderungsvorhaben jeglicher Art ist sie problematisch, wie im Fall des ersten Gesetzes findet man bei näherer Betrachtung aber auch nachvollziehbare Aspekte.


Ein Grossteil aller Veränderungsvorhaben krankt daran, dass versucht wird, Dinge die in einem völlig anderen Kontext entwickelt wurden, Eins zu Eins auf die eigene Organisation zu übertragen. Im schlimmsten Fall kann das zu Stilblüten führen wie der, dass ein italienischer Konzern versucht, das Organisationsmodell eines schwedischen Startups unverändert auf sich zu übertragen. In solchen Fällen wäre weniger Dogmatismus und mehr Anpassung gut.


Problematisch wird dieses an sich sinnvolle Vorgehen aber, wenn der andere Kontext und die dadurch nötigen Anpassungen instrumentalisiert werden, um die geplanten Neuerungen so weit wie möglich zu unterlaufen, und zwar auch dann wenn sie umsetzbar und sinnvoll wären. Aussagen wie "Wir können nicht 'Agile by the Book' machen, wir sind in einer gesetzlich regulierten Branche" sind Klassiker unter den als Realismus getarnten Ausreden, die in solchen Situationen immer wieder vorgebracht werden.


Das was den Umgang mit derartigen Unterlaufungsversuchen schwierig macht, ist ihre scheinbare Rationalität. Nicht nur erscheinen sie auf den ersten, flüchtigen Blick vernünftig, ihre scheinbare Praxisnähe ermöglicht es demjenigen der sie vorbringt im Umkehrschluss, die von ihm abgelehnten Ansätze als realitätsfern, ideologisch oder ähnliches zu diskreditieren. Genau diese Verhaltensweisen werden in Larmanns zweitem Gesetz beschrieben.


Der beste Umgang mit derartigen Situationen ist es, sich gar nicht erst auf die Diskussion einzulassen, ob ein neuer Ansatz dogmatisch ist oder nicht. Zielführender und erfolgsversprechender ist es, in Erinnerung zu rufen, welche aktuellen Missstände durch ihn beseitigt werden sollen, und dass eine Debatte über angeblichen Dogmatismus nur dazu führen würde, dieses Problem, bzw. dessen Lösung aus den Augen zu verlieren. So wird eine Rückkehr zur Sachlichkeit ermöglicht.

Dienstag, 30. April 2024

Kommentierte Links (CXIII)

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.

Jeff Gothelf: Why is it so hard to admit there’s uncertainty in our work?

Meine Theorie ist, dass ein grosser Teil der oft fehlenden Akzeptanz agilen Arbeitens darin begründet ist, dass die Menschen es sich nicht eingestehen wollen, in einer nur eingeschränkt planbaren Arbeitsumgebung tätig zu sein. Jeff Gothelf geht an dieser Stelle tiefer ins Detail und versucht zu ergründen, warum das schwerfallen kann. Verkürz gesagt: weil (das Eingeständnis von) Ungewissheit unangenehm ist und weil man einmal geäusserte Annahmen und Zusagen ungerne zurücknimmt. Warum man einen guten Grund hat, diese inneren Widerstände zu überwinden, begründet er gleich mit - wer von Anfang an von Ungewissheit ausgeht, wird sein Vorhaben resilienter organisieren, wodurch es nicht so schnell aus der Bahn geworfen werden kann.

Charles Lambdin: What Does 'Iterate' Mean?

Es ist ein Vergehen, dessen sich jeder berufliche Spezialist früher oder später schuldig macht - man benutzt bestimmte Fachbegriffe irgendwann ganz automatisch, ohne darüber nachzudenken wie sie eigentlich ursprünglich gemeint waren. Einer dieser Begriffe, der im Rahmen von agilem Arbeiten immer wieder genutzt wird, ist das Iterieren. Charles Lambdin hat sich die Mühe gemacht und ist dem Ursprung dieses Wortes nachgegangen, mit der überraschenden Erkenntnis, dass er bereits von den Verfassern des Manifests für agile Softwareentwicklung uneinheitlich benutzt worden ist. Vielleicht ist das auch einer der Gründe dafür, dass sich der alternative Begriff des Sprints durchgesetzt hat.

Michael Mankins, Patrick Litre: Transformations That Work

Ein Longread, aber einer, der die investierte Zeit lohnt. Michael Mankins und Patrick Litre haben zu dem Thema der Unternehmenstransformationen (agil, digital, etc) geforscht und kommen zu erstaunlichen Zahlen: die Hälfte der von ihnen befragten Unternehmen hat in den letzten fünf Jahren mehrere derartige Veränderungsprogramme durchlaufen, von denen führten aber nur zwölf Prozent wirkliche Veränderungen herbei. Interessant ist, was diese kleine Erfolgsgruppe gemeinsam hat - die Transformationsvorhaben waren keine zeitlich begrenzten Projekte sondern wurden langfristig und als Teil der täglichen Arbeit beschlossen und umgesetzt, sie waren nicht mit Sparprogrammen verbunden, die Organisation wurde nicht durch zu viele gleichzeitige Veränderungen gestresst, und es wurden ambitionierte Ziele gesetzt, den unteren Ebenen aber Freiheiten in der Ausgestaltung gelassen.

Maarten Dalmijn: Why OKRs Often Slowly Wither Away

Was Maarten Dalmijn hier über OKRs schreibt, trifft auch auf jede andere Form von agilem Arbeiten zu: damit es funktionieren kann sind bestimmte Rahmenbedingungen nötig. Sind diese noch nicht vorhanden, wird die neue Vorgehensweise nicht die gewünschten Ergebnisse bringen, sondern nach und nach wieder absterben. In diesem Problem liegt aber auch bereits die Lösung: wenn man die notwendigen Vorbedingungen einmal verstanden hat, kann man sich fragen, was man tun kann um sie herbeizuführen. Daran zu arbeiten sorgt dann oft für mehr Agilität als die Einführung von OKRs (oder Scrum, oder sonstwas) selbst.

Biplab Subedi: 5 Product Discovery Pitfalls Leading to Scrum Failures

Als letztes mal wieder eine kleine Liste. Biplab Subedi hat fünf häufige Product Discovery-Fehler zusammengetragen, wegen denen eine Scrum-Einführung schiefgehen kann. Hier sind sie:
1. Inadequate Time for the Problem Space
2. Discovery Solely for Estimation
3. Discovery Without Past Evidence
4. Discovery for a Quarter or More
5. Separation of Responsibilities in Discovery and Delivery
Mehr Details gibt es drüben bei ihm. Ich würde nur noch ergänzen, dass er sich Fälle bezieht, in denen Product Discovery tatsächlich nötig ist. Es gibt auch Fälle, in denen das nicht so ist.

Donnerstag, 25. April 2024

Agile Success Stories: das Warnsignal

Bild: Pexels / Andrea Piacquadio - 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.


Die heutige kleine Geschichte habe ich in einem grossen Industriekonzern erlebt, der in mehreren Grossprojekten seine Anlagensteuerung und -überwachung digitalisierte und modernisierte. Diese Projekte waren zu Beginn alle nach Wasserfall durchgeführt worden, das in dem ich zeitweise war, war eines der ersten in denen agil gearbeitet wurde - unter misstrauischer Beobachtung übrigens, da es das verbreitete Vorurteil gab, dieser Arbeitsmodus wäre unzuverlässig und unsicher.


Wie man sich denken kann hakte es an einigen Stellen, unter anderem waren viele Stakeholder lange nicht bereit an den Sprint Reviews teilzunehmen, solange noch nicht alle Anforderungen vollständig umgesetzt waren.1 Erst eine Management-Intervention konnte das ändern, und so liessen sich ein Vierteljahr vor dem Go Live eines neuen Überwachungssystems endlich einige der zukünftigen Anwender vom Entwicklungsteam den bisher fertiggestellen Umfang vorführen.


Einer dieser zukünftigen Anwender war deren Teamleiter, ein Ingenieur namens Xin Mi.2 Mit strengem Blick verfolgte er die Vorführung, stellte mehrfach Nachfragen und machte sich jedesmal kopfschüttelnd Notizen, wenn er über ein Feature hörte, dass es erst in einem der kommenden Sprints umgesetzt werden würde. Irgendwann wurde er dann plötzlich hektisch und aufgeregt. Laut auf deutsch, englisch und chinesisch schimpfend stürmte er aus dem Raum, immer wieder "das geht so nicht" rufend.


Sein Problem: die Überwachungs-Ergebnisse des neuen Systems wurden in Echtzeit auf einem Bildschirm angezeigt. Was niemand dem Entwicklungsteam gesagt hatte war aber, dass der nur einer von über 20 auf einer ganzen Bildschirm-Wand sein würde. Was Xin Mi zurecht anmerkte - der davor sitzende so genannte Operator könnte eine auf nur diesem einem Bildschirm angezeigte Störungsmeldung leicht übersehen, und auch der Warnton war so leise, dass er in einem solchen Raum überhört werden könnte.


Etwas irritiert von dem Ausmass des Dramas überlegte das Team sich im folgenden Planning eine Lösung: der Warnton wurde lauter und durchdringender und um den Bildschirm wurde bei Störungen ein rot blinkender Rahmen angezeigt, um den Blick dorthin zu lenken. Die Umsetzung passte auch irgendwie noch in den nächsten Sprint hinein. Der immer noch aufgebrachte Xin Mi war zwar nicht bereit, während des Sprints darüber zu reden, zum nächsten Sprint Review kündigte er sich aber an.


Diesesmal tauchte er in Begleitung mehrerer Manager auf und verhielt sich wieder überraschend. Direkt zu Beginn verlangte er die Agenda umzustellen und mit der Störungsmeldung zu beginnen. Leicht irritiert gab das Entwicklungsteam diesem Wunsch nach und führte die Ergänzungen des letzten Sprints vor. Xin Mi, der gerade angesetzt hatte, den mitgebrachten Managern zu erklären, wie schlimm alles wäre, war völlig perplex. Dass sein Problem plötzlich gelöst war, war für ihn unbegreiflich.


Sein verdattertes Schweigen wurde von den Entwicklern falsch interpretiert und für Unzufriedenheit gehalten, also machten sie ein weiteres Angebot: Wenn Warnton oder Signalfarbe nicht passen würden könnte man auch das im nächsten Sprint noch ändern, jetzt, da die Funktionen da wären, wäre das kein Problem mehr. Für Xin Mi war das zu viel. Mit Tränen in den Augen stand er auf, bedankte sich überschwänglich und entschuldigte sich für sein bisher ablehnendes Verhalten.


Zum Hintergrund: in den bisherigen Wasserfallprojekten waren auch kleinste Änderungen der Anforderungen nur mit erheblichen bürokratischen Aufwänden machbar gewesen. Da neue Funktionen in den alten Anwendungen nur zweimal pro Jahr released wurden, waren diese Releases aufwändig und fehleranfällig, was dazu geführt hatte, dass zusätzliche Änderungen möglichst abzulehnen waren. Für jemanden der aus einer solchen Welt kommt, sind Auslieferungen alle zwei Wochen unvorstellbar.


Obwohl (oder vielleicht gerade weil) die hier beschriebene Anpassung nicht besonders gross war, war ihre schnelle und unkomplizierte Umsetzung für Xin Mi ein Erweckungserlebnis. Er wurde zum begeisterten Teilnehmer der Sprint Reviews und zum grössten Fürsprecher des agilen Arbeitens in seiner Abteilung und zog sogar zeitweise in das Büro des Entwicklungsteams, um so einen noch engeren und intensiveren Austausch haben zu können. Ein Stakeholder wie man ihn sich wünscht.


Geschichten wie seine (von denen ich einige erlebt habe) kann man sich immer wieder vor Augen führen, wenn andere Dinge nicht funktionieren wie gehofft. Sie sind nicht so imposant wie ein grosses Kulturwandel- oder Skalierungsprogramm, in Summe aber für die Akzeptanz und den Erfolg agiler Produktentwicklung viel, viel wichtiger. Und dieser eine Moment, in dem aus Wut Unglaube und aus Unglaube Begeisterung und Dankbarkeit wurde, ist einer, der im Gedächtnis hängen bleibt.



1Was natürlich den Zweck dieses Termins konterkarierte
2In Wirklichkeit hiess er anders, Xin Mi ist für diese kleine Geschichte sein Pseudonym

Montag, 22. April 2024

Aufklärung

Bild: Wikimedia Commons / Emil Doerstling - Public Domain

Man soll ja die Feste feiern wie sie fallen, daher an dieser Stelle herzliche Glückwünsche an Immanuel Kant zum 300. Geburtstag. Wie jeder andere Europäer und Amerikaner sind wir bewusst oder unbewusst von seinem Wirken geprägt, z.B. in unserer Arbeit in der agilen Produktentwicklung durch seine Erkenntnistheorie. Um den Rahmen nicht zu sprengen möchte ich mich aber heute auf etwas Kleineres beschränken: mein Kant-Lieblingszitat, gefunden in seinem Artikel Was ist Aufklärung?:


Wenn denn nun gefragt wird: leben wir jetzt in einem aufgeklärten Zeitalter? so ist die Antwort: Nein, aber wohl in einem Zeitalterder Aufklärung.
Immanuel Kant: Was ist Aufklärung?, S.9


Was Kant damit meint ist, dass die Benennung der Zeit, in der er lebte, als Aufklärung keineswegs bedeutete, dass objektives, rationales Denken sich allgemein durchgesetzt hatte und Unwissen und Falschannahmen der Vergangenheit angehörten. Stattdessen war es für ihn lediglich so, dass den Menschen die Möglichkeit eröffnet wurde, sich Objektivität und Rationalität zu erarbeiten. Dieser dauerhafte Erarbeitungs-Prozess war für ihn Aufklärung.


Wer möchte kann hierin Parallelen zu der Arbeit der heutigen (agilen) Unternehmensberater, Agile Coaches und Scrum Master erkennen. Auch am Anfang unserer Arbeit steht in der Regel ein Unwissen über Systeme, Befindlichkeiten und Dynamiken, auch wir versuchen durch Datengetriebenheit und Empirie Licht in dieses Dunkel zu bringen,1 und auch uns ist (hoffentlich) bewusst, dass diese Aufgabe kaum durch uns final abschliessbar ist.


Diese Erkenntnis kollidiert natürlich immer wieder mit dem verständlichen Wunsch unserer beruflichen Umgebung, irgendwann mit den Veränderungen fertig zu sein, um "wieder in Ruhe arbeiten zu können". Zu vermitteln, dass das praktisch nicht möglich ist, und dass die Entdeckung und Untersuchung immer neuer Probleme und die Validierung immer neuer Lösungen von Dauer sein müssen, ist einer der anspruchsvollsten Teile unseres Berufs.


Ob die Berufung auf Kant bei der Vermittlung dieser Erkenntnis von Nutzen ist, sei dahingestellt, je nach Kontext wird die Antwort eine andere sein. Für jeden, der sich mit Geistes- oder Philosophiegeschichte beschäftigt hat, mag es aber ein schöner Gedanke sein, dass wir in gewisser Weise das weiterführen, was Kant und seine Zeitgenossen begonnen haben. Und dass seine Gedanken in uns weiterleben ist sicher auch ein passendes Geburtstagsgeschenk für ihn.



1Licht in das Dunkel bringen ist auch die ursprüngliche Bedeutung des Wortes "Aufklärung"

Donnerstag, 18. April 2024

Coding Will Never Be The Same Again

Wenn die Rede darauf kommt, wie sehr der Einsatz von KI die Softwareentwicklung beschleunigen und verbessern kann, stösst die Vorstellungskraft vieler Menschen an ihre Grenzen. Ryan Salva ist so freundlich und führt live auf der Konferenzbühne der YOW-Konferenz 2023 anhand des GitHub Copilot vor, wie man sich das vorstellen kann. Beeindruckend.



Die spannenden Fragen, die diese Vorführung aufwirft: wenn über Retrieval Augmented Generation Code von anderen Entwicklern bezogen oder dieser auf Basis von Reinforced Learning from Human Feedback automatisiert modifiziert wird, wie kann verhindert werden, dass das Model versehentlich durch schlechten Code kontaminiert wird? Wie sicher sind die hier nur kurz zu sehenden Absicherungen gegen Bugs, Urheberrechtsverletzungen und anstössige Inhalte wirklich? Und wie kann verhindert werden, dass die Einfachheit der Codegenerierung dazu führt, dass im Überschwang der Gefühle so viel erzeugt wird, dass die Codebase unnötig aufgebläht wird? Die Antworten darauf werden wesentlich beeinflussen, ob mit KI wirklich bessere, schnellere Ergebnisse möglich werden, oder ob die Aufwände einfach nur an andere Stellen verlagert werden. Hoffen wir auf das erste.

Montag, 15. April 2024

KI und Agilität (Probleme und Potentiale)

"Die Zukunft hat bereits begonnen, alles ist jetzt anders und unsere Art zu arbeiten wird sich fundamental ändern." Ungefähr das können wir uns regelmässig anhören, seit 2022 die KI-Anwendungen auf den Massenmarkt gekommen sind.1 Auch für die agile Produktentwicklung wurden und werden derartige Vorhersagen gemacht, und nachdem mittlerweile einige Zeit verstrichen ist, können wir ein erstes Zwischenfazit ziehen: was ist an neuen Möglichkeiten dazugekommen und wie sinnvoll sind die?


Meine (sehr subjektive) Übersicht ist in sechs Kategorien gegliedert: Gefährlicher Blödsinn, Quellenfreie Blaupausen und Banalitäten, Kleine Produktivitäts-Hacks, Grosse Macht und grosse Verantwortung, Riesiges Potential, aber nur schwer umsetzbar und Jenseits der Vorstellungskraft. Man sieht, es ist von allem etwas dabei, ungefähr angeordnet entlang einer Skala zwischen Unsinn und Grossartig. An der können wir uns bei der Betrachtung entlanghangeln.


Gefährlicher Blödsinn

Fangen wir mit dem grössten Quatsch an, dem Scrum Master-Chatbot, der Meetings moderieren oder bei der Formulierung von User Stories helfen kann. Diese Programme sind nicht nur deshalb problematisch, weil sie nicht in der Lage sind, Kontext, Emotionen und nonverbale Signale zu erkennen, sie setzen auf vollständig falschen Prämissen auf, nämlich auf denen, dass der Scrum Master alle Meetings moderiert oder dass alle Anforderungen User Stories sein müssen. Sie richten mehr Schaden als Nutzen an.


Quellenfreie Blaupausen und Banalitäten

"Wie strukturiert man ein Refinement Meeting?" oder "Wie ist ein Kanban-Board aufgebaut?" Derartige Fragen kann man sich von einem Chatbot beantworten lassen. Das ist auch schön und gut, allerdings bewegen sich derartige Fragen auf dem grundlegendsten Einsteiger-Level, wo sie mit dem Risiko verbunden sind, unreflektiert als (im Zweifel unpassende) Blaupause verwandt zu werden. Dazu kommt noch ein weiterer Punkt: ohne Quellenangabe ist nicht klar, wie seriös die ursprüngliche Quelle ist.


Kleine Produktivitäts-Hacks

Ab hier fängt es an, sinnvoll zu werden. Ein KI-Chatbot kann ein Meeting aufzeichnen und zusammenfassen, er kann erste Entwürfe für Präsentationen erstellen und Visualisierungen anfertigen. Unabhängig davon, dass das nur wenig mit Agilität im eigentlichen Sinn zu tun hat, kann es natürlich Zeit sparen. Zumnindest im Moment aber nur im geringen Ausmass, da die Ergebnisse noch so schlecht sind, dass man sie manuell überarbeiten muss.


Grosse Macht und grosse Verantwortung

Auf diesem Punkt ruhen zur Zeit die grössten Hoffnungen: einer KI wird eine Anforderung gegeben und sie erzeugt in Sekunden den Quellcode, alternativ kann sie menschengeschriebenen Code reviewen oder bereinigen. Das kann den Inspect & Adapt-Prozess bemerkenswert beschleunigen, zu beachten ist aber, dass eine KI nur so gut sein kann wie der Durchschnitt ihres Trainingsmaterials. Es besteht daher das Risiko, dass sie unzeitgemässe oder unsichere Software erzeugt.2 Das sollte sorgfältig überprüft werden.


Riesiges Potential, aber nur schwer umsetzbar

Stellen wir uns eine KI vor, der man Aussagen, Fragen und Feedback von tausenden Mitarbeitern schicken kann und die daraus die wesentlichen Züge der Unternehmenskultur extrahiert. Oder eine andere, die aus internen Entwicklungsmetriken bisher unentdeckte Zusammenhänge ablesen kann. Das könnte dabei helfen, Change- und Optimierungsprogramme um ein Vielfaches wirksamer zu machen. Das Problem: kaum ein Unternehmen hat die dafür nötigen Daten in ausreichender Qualität vorliegen.3


Jenseits der Vorstellungskraft

Man muss sich eines bewusst machen: die technische Entwicklung hat gerade erst angefangen. Genau wie bei den ersten Smartphones noch nicht absehbar war, dass sie einmal als Fahrkarte oder Fernbedienung benutzt werden könnten, wird sich bei den KI-Anwendungen ebenfalls noch Einiges ergeben, was jetzt noch nicht absehbar ist. Aber das bedeutet natürlich auch, dass es hier noch nicht besprochen und bewertet werden kann. Das dauert noch.


Zusammengefasst kann man sagen, dass zwar grosse Potentiale erkennbar sind, die wirkliche Revolution der (agilen) Arbeitswelt aber noch ausgeblieben ist. Zum Teil liegt das daran, dass der Einsatz von KI zum Teil in nicht zielführenden Zusammenhängen stattfindet, zum anderen daran, dass die für einen wirklich disruptiven Einsatz notwendigen Voraussetzungen oder Sicherheitsvorkehrungen noch fehlen. Aber das soll nicht heissen, dass es auch so bleiben muss.


Ein häufiges Muster bei technologischen Innovationen ist, dass die kurzfristigen Effekte überschätzt, die langfristigen aber unterschätzt werden. Sollte das auch hier der Fall sein, wird sich das erst in einigen Jahren bemerkbar machen. Bis dahin sollte man zwar technologie-offen bleiben, die Erwartungen an umwälzende Veränderungen aber auf ein realistisches Mass herunterfahren.



1Da der Begriff unscharf ist: gemeint sind hier vor allem Large Language Models.
2Aus diesem Grund sind derartige Anwendungen in vielen Unternehmen zur Zeit intern noch nicht zugelassen.
3Nein, wirklich nicht. Die Daten in Tracking-Tools wie Jira oder Polarion sind in der Regel unvollständig und nur in den seltensten Fällen aktuell gehalten, und die Fragen in Feedback-Tools sind fast immer durch vorgegebene Kategorien, Längenbegrenzungen oder vorgegebene Antwortoptionen suggestiv gestaltet.

Donnerstag, 11. April 2024

Ausbalancierte Product Ownership

Bild: Pexels / Ivan Rebic - Lizenz

Eine der vermutlich ältesten Debatten im Umfeld von Scrum und anderen agilen Ansätzen dreht sich um die Frage, wie gross der Entscheidungsspielraum eines Product Owners (oder vergleichbarer Projektmanagement-Rollen) ist. Darf er wirklich alles entscheiden, bis hin zur möglichen Einstellung seines Produkts, oder ist er lediglich dafür zuständig die Wünsche seiner Stakeholder zu sammeln und zu einem in sich stimmigen Ganzen zusammenzufügen?


Die Antwort ist natürlich auch hier "kommt darauf an", allerdings mit einer gewissen Ausdifferenzierung. Statt einem dieser beiden Extremtypen zu entsprechen, befinden sich die meisten Product Owner irgendwo auf einer dazwischenliegenden Skala, und auch das nicht stationär sondern je nach Kontext mal hier und mal dort. Das ist auch bereits mehrfach beschrieben worden, vielleicht am eingängigsten vom Produktmanagement-Experten Roman Pichler.


In seinem Text Be a Balanced Product Leader, Not a Feature Broker or Product Dictator gibt er den beiden Extremtypen Namen, nämlich genau die im Titel genannten: der Feature Broker hat kaum Gestaltungswilllen oder Gestaltungskompetenz und beschränkt sich darauf, zwischen den Stakeholdern so lange zu vermitteln, bis eine gemeinsame Priorisierung aller Anforderungen entstanden ist. Der Product Dictator hat Gestaltungswilllen und Gestaltungskompetenz und entscheidet alles komplett alleine.


Warum die Extreme schädlich sind, dürfte offensichtlich sein. Das "Produkt" eines Feature Brokers wird schnell zu einem inkonsistenten Sammelsurium von Kompromisslösungen werden, das eines Product Dictators wird zwar in sich stimmig sein, im Zweifel aber vor allem ihm selbst gefallen und nicht notwendigerweise auch den Kunden oder Anwendern. Der "Ausbalancierte Product Owner" befindet sich in der Mittel und hat Züge von beiden, hält sie aber im vernünftigen Rahmen.


Was Pichler ergänzend anmerkt ist, dass jeder Product Owner sich des Risikos bewusst sein sollte, sich unbewusst zu sehr in eine der beiden Richtungen zu bewegen. Vor allem wenn das in kleinen, für sich genommen unscheinbaren Schritten geschieht, kann man das irrige Gefühl haben, sich nicht aus der Mitte wegbewegt zu haben, während die Umgebung einen mittlerweile als einen der beiden Extremtypen wahrnimmt (und unter den damit verbundenen Dysfunktionen leidet).


Es ist daher ratsam, von Zeit zu Zeit zu überprüfen, wo auf der Skala zwischen Feature Broker und Product Dictator man sich befindet. Ob man das durch Selbstreflektion, Überprüfung festgelegter Kriterien oder Feedback von anderen macht kann von Fall zu Fall unterschiedlich sein, wichtig ist aber, dass es überhaupt stattfindet. Nur so kann man sicherstellen, in einer ausbalancierten Rollenausprägung zu bleiben (oder in sie zurückzukehren).

Montag, 8. April 2024

Macht der Scrum Master sich selbst überflüssig?

Bild: Pexels / Zen Chung - Lizenz

Zu den Mythen, die sich mit der Zeit um das Scrum-Framework gebildet haben, gehört der, dass der Scrum Master sich mit der Zeit selber überflüssig macht und irgendwann nicht mehr benötigt wird. Auf den ersten Blick erscheint das auch wie eine naheliegende Idee, bei näherer Betrachtung hat sie aber durchaus problematische Aspekte. Es lohnt sich, näher zu betrachten wo diese Aussage herkommt, wie sie gemeint ist und was für Folgen sie haben kann.


Um mit dem Einfachsten zu beginnen: in keinem der offiziellen Scrum-Dokumente befindet sich eine auch nur entfernt ähnliche Aussage. Weder in der aktuellen Version des Scrum Guide, noch in einer der älteren Versionen, noch in einem der Konferenz-Papers mit denen Ken Schwaber und Jeff Sutherland ihren Ansatz am Anfang bekannt gemacht haben ist die Rede davon, dass der Scrum Master irgendwann nicht mehr gebraucht werden könnte (wer nachlesen will - hier sind alle dieser Dokumente verlinkt).


Der Urheber ist also irgendjemand, der nicht an der Entwicklung von Scrum beteiligt war, überspitzt könnte man sagen: ein Mensch mit einer starken Privat-Meinung. Wer genau das gewesen ist, lässt sich wahrscheinlich nicht mehr rekonstruieren, man kann aber zumindest sagen, wer diese Idee vermutlich bekannt gemacht und popularisiert hat - Geoff Watts, ein bekannter englischer Scrum Master, in seinem 2013 erschienen Buch Scrum Mastery: From Good To Great Servant-Leadership.


My second piece of advice is to go into the role of ScrumMaster with the intention of making the role of ScrumMaster for this team unnecessary. Create such a high-performing, self-organising team, with such a good relationship with the product owner, with such a keen understanding of the Scrum framework (and the principles behind the framework) that they don’t need any facilitation (of either process or people) and have no impediments left to remove. In other words, be so great that they don’t need you anymore. I’m not saying this will definitely happen, but the more you aim for it, the more quickly your team will develop and the better your team will perform.
Geoff Watts: Scrum Mastery (2.Auflage), S.27


Wie man aus diesem Abschnitt herauslesen kann, beschreibt Watts ein Idealbild, dessen Erreichung eher unwahrscheinlich ist. Das tatsächliche Ziel ist dabei weniger die Selbstabschaffung sondern die konstante Arbeit daran, das Scrum Team selbstorganisiert zu machen und ihm diese Selbstorganisation zu erhalten. Indirekt wird gleichzeitig vor dem häufigen Antipattern gewarnt, bestimmte Tätigkeiten in der Scrum Master-Rolle zu monopolisieren (was andere negative Folgen mit sich bringen würde).


Dass das Idealbild eines Scrum Teams ohne Scrum Master nur schwer zu erreichen ist, hat übrigens handfeste Gründe: Vieles von dem, was in dieser Rolle gemacht wird, erfordert ein Heraustreten aus den Alltagsabläufen und eine Konzentration auf langfristige Ziele. Da gerade in Scrum mit seinen kurzen Sprints aber ein permanenter kurzfristiger Lieferdruck herrscht, wäre eine Verdrängung der Langfrist- durch die Kurzfrist-Ziele hochwahrscheinlich, wenn sie von den selben Personen verantwortet werden (kurzfristige Verpflichtungen fühlen sich immer dringender an als langfristige).


Gleichzeitig ist es eine wichtige Eigenschaft des Scrum Masters, überparteilich zu sein, um bei Konflikten (z.B. zwischen den Entwicklern oder zwischen Product Owner und Stakeholdern) vermitteln zu können.1 Ohne ihn fällt diese Vermittlerrolle weg, und wird aufgrund des fehlenden Kontextwissens nur eingeschränkt durch einen externen Moderator oder Mediator ersetzt werden können. Schlimmstenfalls kommt es nur zu Schein-Konsensen, oder solchen die nicht lange halten.


Trotz dieser Faktoren wäre das Setzen des Scrum Master-Selbstabschaffungs-Ziels zunächst unproblematisch, da es aufgrund seiner Langfristigkeit kaum ins Gewicht fällt, wenn es auf absehbare Zeit nicht erreicht wird. Zu einem Problem wird es aber, wenn dieses Ziel in die Einsatz- und Budgetplanungen integriert wird. Und vor allem grosse Firmen versuchen genau das immer wieder, was verschiedene problematische Folgen mit sich bringt.


Zum einen werden in vielen Fällen keine internen Scrum Master-Positionen geschaffen, da man die ja "nur vorübergehend braucht". Das schwächt diese Rolle, es sorgt für eine hohe Fluktuation (aus Sorge vor Scheinselbstständigkeit sind externe Besetzungen meistens befristet) und macht sie zu einem primären Ziel von Sparprogrammen, da der Abbau von externem Personal einer der einfachsten und schnellsten Wege ist, um Kosten (scheinbar) zu senken.


Zum anderen führt auch bei internen Scrum Mastern die Idee, dass diese irgendwann überflüssig werden, zu "Optimierungsversuchen". Eine immer wieder anzutreffende Variante ist die Deckelung der Zeit, in der ein Team Anspruch auf diese Rolle hat (z.B. auf ein Jahr), eine andere besteht daraus, dass sie ab dem Überschreiten bestimmter Zeiträume nur noch in Teilzeit zur Verfügung steht, um in der restlichen Zeit ein weiteres Team übernehmen zu können (und irgendwann zwei weitere, und drei, etc.).


Beide Varianten führen dazu, dass sowohl die Teams als auch die Scrum Master unter einen permanenten Rechtfertigungsdruck gesetzt werden und immer wieder erklären müssen, warum sie das Selbstorganisations-Ziel noch immer nicht erreicht haben. Das zieht kontinuierlich Zeit und Energie von den wichtigen Aufgaben ab (und was passiert, wenn das Ziel, ohne Scrum Master klarzukommen, mit einem Gehaltsbestandteil verbunden wird - man kann es sich denken. Nichts Gutes jedenfalls).


Zusammengefasst: das Ziel, dass der Scrum Master sich selbst überflüssig macht, ist kein offizieller Teil von Scrum, und es ist nie ein Teil davon gewesen. Dort wo es propagiert wird, wird es als ein kaum zu erreichender Idealzustand verstanden, das eigentliche Ziel ist ein ganz anderes. Und dort wo es missverstanden wird oder den falschen Menschen in die Hände fällt, kann es Fehler im Systemdesign, Ressourcenverschwendung und ständigen Stress zur Folge haben.


Das alles ist wirklich schade, da die Grundidee eigentlich gut und erstrebenswert klingt. Aufgrund der damit verbundenen Risiken sollte man es sich allerdings mehrfach überlegen, bevor man sie in der eigenen Firma äussert. Im Zweifel startet man dadurch eine Dynamik, die sich nur schwer wieder einfangen lässt und ohne Notwendigkeit Konflikte verursacht.



1Gemeint ist Überparteilichkeit in Konflikten, die nicht seinen aus der Rolle ableitbaren Auftrag betreffen. Ist der betroffen, ist die Situation nochmal eine andere.