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.