Donnerstag, 20. Juni 2024

Two Pizza Teams

Bild: Unsplash / Faizan Saeed - Lizenz

Wenn versucht wird, eine Framework-neutrale Beschreibung für ein agiles Team zu finden (oder zumindest für eines, das theoretisch zu agilem Arbeiten in der Lage wäre), dann fällt vor allem im englischen Sprachraum immer wieder ein Begriff: der des "Two Pizza Teams". Das hört sich zunächst eher kurios an, tatsächlich steckt aber eine sehr handfeste Bedeutung dahinter, die, sobald man sie verstanden hat, sehr naheliegend ist - die aber auch mehr enthält als man denken könnte.


Erfunden wurde die Idee der Two Pizza Teams bei Amazon, und zwar in deren Software-Entwicklungsteams in den Vereinigten Staaten. Diese Information ist wichtig, weil das Klischee, dass dort alles etwas grösser ist, auch auf die Pizza zutrifft - von der berühmten New York Pizza schaft man z.B. nur zwei oder drei "Slices". Von zwei derartigen Pizzen bekommt man daher ca. 10 Menschen satt, und da das auch die Durchschnittsgrösse der Teams bei Amazon war, bürgerte der Begriff sich ein.


Die Idee hinter dieser geringen Grösse war, die Kommunikations- und Koordinationsaufwände innerhalb der Teams gering zu halten und ihnen dadurch Meetings und Bürokratie zu ersparen und sie zu einfachem Informationsaustausch und zu schnellen Entscheidungen zu befähigen. Wie schnell derartige Aufwände ohne diese Begrenzung ausser Kontrolle geraten können, zeigt die legendäre Visualisierung der exponentiell steigenden Zahl der Kommunikationskanäle bei nur linearer Steigerung der Teamgrösse:



Ebenfalls wichtig zu wissen ist, dass diese Teams zwar nach ihrer Grösse benannt wurden, bei Amazon aber noch weitere Kriterien erfüllen müssen: es muss sich bei ihnen um Einheiten handeln, die nur auf ein einziges (Teil-)Produkt oder einen einzigen Service fokussiert sind, und die nur daran arbeiten. Das schliesst die Bildung technischer Spezialistenteams ausdrücklich aus, da auch das wieder zu Kommunikations- und Koordinationsaufwänden führen würde, und zwar zwischen diesen Teams.


Die damit verbundene Gefahr ist allerdings, dass Two Pizza Teams sich verzetteln können, wenn sie versuchen alle Arbeiten selbst zu erledigen, für die in anderen Firmen verschiedene Spezialistenteams zuständig wären. Um das zu verhindern, gibt es technische Standards, die von den Teams eingehalten werden müssen: zum einen eine an der Fachlichkeit orientierte Architektur mit klaren Schnittstellen, zum anderen cloudbasierte und "as a Service" abrufbare Infrastrukturen und Plattform-Dienstleistungen.


Wenn all das gegeben ist, kommt der letzte Aspekt ins Spiel: bei Amazon müssen Teams so genannte "Single Threaded Leader" (STLs) haben, also Führungskräfte, die nicht mehrere Ziele gleichzeitig verfolgen dürfen (selbst dann nicht, wenn sie für jedes jeweils ein Team haben), sondern die nur für die Erreichung eines einzigen, im Idealfall fachlichen, Ziels verantwortlich sind. Auf diese Weise kann es gar nicht erst dazu kommen, dass Zielkonflikte an die Teams weitergegeben werden.


Two Pizza Teams haben also ihren Ursprung in der typischen Bestellung ihres gemeinsamen Mittagessens, gehen in ihrer Natur aber weit über eine blosse Grössenvorgabe hinaus. In gewisser Weise sind die einzuhaltenden organisatorischen, fachlichen und technischen Vorgaben sogar so umfangreich, dass man von einem eigenen agilen Framework sprechen kann, das sich anstelle von Scrum, XP oder den Skalierungsframeworks einsetzen lässt. Zumindest wenn sie so umgesetzt werden wie bei Amazon.


Im umgangsspachlichen Gebrauch kann mit diesem Begriff manchmal aber auch die blosse Teamgrösse von ca. 10 Personen gemeint sein. Wie so oft gilt nämlich auch hier: es kommt bei Fachwörtern ganz darauf an, wer sie benutzt, wieviel Vorwissen er hat, wie frei er es interpretiert und in welchem Kontext er das tut. Anders wäre es vermutlich auch langweilig.

Montag, 17. Juni 2024

Why Everybody Hates Agile

Ich glaube zwar nicht, dass "alle" agiles Arbeiten hassen, aber Jesper Boeg hat einen Punkt, wenn er sagt, dass es Fehlentwicklungen gibt, die viele Menschen von dem abstossen, was heute unter dem Label "Agile" vermarktet wird. Und seine Aufzählung dieser Fehlentwicklungen und ihrer Folgen dürfte fast jedem der agil arbeitet an der einen oder anderen Stelle bekannt vorkommen.



Dankenswerterweise belässt er es nicht dabei, sich ausführlich zu beschweren, sondern er hat einen Vorschlag für ein besseres Vorgehen: kundenorientiert und prinzipiengetrieben arbeiten. Jetzt gilt es nur noch, das umzusetzen, ohne dass wieder jemand ein dogmatisches Framework daraus macht.

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üster 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.