Kommentierte Links (CXV)

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.

Maarten Dalmijn: Scrum Alternatives: SCREAM!

Die Mitte der 2010 Jahre ist im Rückblick die große Zeit der Scrum-Verschlimmbesserungen gewesen Ich selbst habe mich seinerzeit über einige dieser (inzwischen zu Recht in Vergessenheit geratenen) Konstrukte aufgeregt, namentlich über Reliable Scrum, Ultimate Scrum, Secure Scrum und Autoscrum. Maarten Dalmijn hat jetzt irgendwo einen weiteres derartiges Framework ausgegraben, dem ohne erkennbare Ironie der Name SCREAM! gegeben wurde, und das im Gegensatz zu den anderen noch irgendwo im Einsatz ist - mit sehr überschaubaren Ergebnissen. Es ist ein kurioses Phänomen: nahezu alle Versuche, ein "verbessertes Scrum" zu erfinden, enden im Gegenteil.

Pawel Huryn: How to Fix the Double Diamond of Design Thinking?

Ich habe eigentlich schon länger vor, irgendetwas zum Thema Design Thinking zu schreiben, zu dem ich ein sehr gespaltenes Verhältnis habe. Einerseitz ist der Ansatz von der Grundidee gut, andererseits endet seine Umsetzung regelmässig mit einem Wasserfall im Wasserfall, genauer gesagt mit einem Sequenzmodell innerhalb der Anforderungsphase. Pawel Huryn ist mir mit seinem Artikel jetzt zuvorgekommen, und das auch noch mit einem lobenswerten Spin. Statt sich einfach nur über das zu beschweren, was problematisch ist, macht er Vorschläge dazu, wie es besser ginge: durch mehr Feedback-Schleifen, Continuous Delivery und zusätzliche Erkenntnisquellen. Das sind gute Ideen.

Danny Faught: Beyond Scrum

Eine häufige Entwicklung (und eine, die ich auch absolut ok finde) ist die, dass Teams, die eine Zeit lang nach Scrum gearbeitet haben, irgendwann anfangen dessen Regeln an ihre Bedürfnisse anzupassen. Danny Faught berichtet in seinem Erlebnisbericht seiner letzten Einsätze von einigen Veränderungen, die auch ich immer wieder erlebt habe: aus den fest getakteten, auf ein einziges Ziel focussierten Sprints wird ein Flow-orientierter Durchlauf, aus dem Versuch Aufwände zu schätzen werden Durchsatz-Zahlen, dazu kommen andere Elemente aus Kanban und XP. Das was die Fälle aus diesem Bericht von vielen anderen unterscheidet ist ihre Ehrlichkeit - es wird auch nicht so getan, als würde das Ergebnis noch Scrum sein. Es ist irgendetwas anderes geworden.

Elaine Lin Hering: How to Get Your Team to Actually Speak Up

Ein weiterer Schritt heraus aus der Scrum Bubble, diesesmal einer, in dem es um eine der absoluten Grundlagen und Vorbedingungen für agiles Arbeiten geht: darum, dass die Mitarbeiter bereit sind, offen, ehrlich und proaktiv zu kommunizieren. Die Ausführungen von Elaine Lin Hering zu diesem Thema haben viel mit psychologischer Sicherheit zu tun, aber auch mit ehrlichkeit, Berechenbarkeit, Einbeziehung und Unterstützung. Das ganze mit einer Management-Perspektive im Hinterkopf, also darauf bezogen, was ein Manager machen kann, um die erwähnten Effekte herbeizuführen.

Kent Beck: Minimum Viable Product revisited

Das es sehr unterschiedliche Verständnisse der Natur eines Minimum Viable Product (MVP) gibt, hatte ich irgendwann bereits aufgeschrieben. Auch Kent Beck, einer der Erfinder des Extreme Programming, hat seine Definition, die sehr der aus dem Lean Startup ähnelt. Ein MVP ist in seiner Sicht das Ergebnis der kleinstmöglichem Umsetzungsarbeit (→ Minimum), mit der man einen belastbaren Lerneffekt (→ Viable) zu dem Kundenanliegen an dem man arbeitet (→ Product) gewinnen kann. Mit anderen Worten: kein MVP to earn", sondern ein "MVP to learn". Auch aus meiner Sicht die spannendere und oft zielführendere Variante.

Runaway Effect

Bild: Pixabay / Peter Kaul - Lizenz

Es ist ein Phänomen, das man immer wieder beobachten kann: in irgendeiner Softwareentwicklungs-Organisation tritt eine Verschlechterung der Arbeits-Effektivität und -Effizienz auf, erst nur ein bisschen, dann ein bisschen mehr, dann deutlich mehr, dann viel mehr. Verbesserungsmassnahmen werden ergriffen, aber im besten Fall verlangsamen sie die Entwicklung nur, im schlimmsten Fall bleiben sie wirkungslos. Es wird immer schlimmer. Für dieses Phänomen gibt es einen Namen: den Runaway-Effekt.

Die Gründe für diese Benennung sind offensichtlich. Zum Einen erinnert die zunehmende Beschleunigung der Verschlechterung an einen Läufer oder Motor, der nach dem Start immer mehr Geschwindigkeit aufnimmt, zum Anderen an den Versuch, eine schnellere Person einzufangen. Aufgrund ihrer höheren Geschwindigkeit wird sie immer in der Lage sein, sich durch Weglaufen dem Zugriff zu entziehen. Übertragen: wenn das Problem an einer Stelle gelöst ist, ist es längst woanders aufgetaucht.

Der Grund für diese Entwicklung ist fast immer der gleiche: irgendwann wurde bewusst oder unbewusst entschieden, technische Schulden aufzunehmen, also nichtfunktionale (und für den Nicht-Techniker unsichtbare) Qualitätsaspekte wie Testabdeckung, Clean Code und stringente Architektur wegzulassen, um dadurch mehr Zeit für die Featureentwicklung zu haben. Das Tückische daran - in der unmittelbar anschliessenden Zeit halten sich die Folgen scheinbar in Grenzen.

Im Einzelnen sehen diese Folgen so aus, dass an einigen Stellen etwas mehr manueller Aufwand entsteht (z.B. beim Testen), und dass Code und/oder Architektur nicht sofort verständlich sind, so dass man sich bei einer Weiterentwicklung zuerst "Hineindenken" muss. Im Hintergrund geht der Runaway-Effekt aber bereits los: bei den manuellen Tätigkeiten kommt es zu Flüchtigkeitsfehlern und neuer Code "erbt" seine Architektur und (Un)Verständlichkeit von dem bereits vorhandenen.

Das addiert sich über die Zeit auf, die manuellen Aufwände (und Fehler) werden immer mehr und die Nachvollziehbarkeit von Code und Architektur wird immer geringer. Beides sorgt ausserdem dafür, dass immer mehr Fehlfunktionen versehentlich ins System gelangen, wo sie mit mühsamer Detektivarbeit gesucht werden müssen, wenn ihre Auswirkungen irgendwann auffallen. In Kombination sind das die Gründe für die ständig grösser werdenden Effektivitäts- und Effizienzverluste.

Schlimmstenfalls kommt es sogar dazu, dass IT-Systeme selbst dann ständig zunehmende Probleme generieren wenn gar nicht an ihnen gearbeitet wird. Unter Lastspitzen zusammenbrechende Systeme können ein Grund dafür sein, aber auch vollaufender Speicherplatz, in den unmöglichsten Situationen auftretende Race Conditions oder Fehler, die nur zu bestimmten Zeitpunkten auftreten können, etwa beim Jahreswechsel oder bei der Sommer- und Winterzeitumstellung.

Ein häufiger Versuch, den Runaway-Effekt in Griff zu bekommen sind so genannte Code- oder Feature-Freezes. Beim ersten wird die Anwendung gar nicht mehr weiterentwickelt (z.B. weil stattdessen ein komplett neues System entwickelt wird), beim zweiten darf nicht mehr an funktionalen Erweiterungen gearbeitet werden, damit alle Arbeitskraft in den Abbau der technischen Schulden gehen kann, die für die Entstehung des Effekts gesorgt haben. Oft anzutreffen ist eine Kombination: Feature Freeze für wichtige oder häufig zu ändernde Teile, vorläufiger Code Freeze für den Rest.

Eine entscheidende Frage bei solchen Reparatur- oder Ablöse-Phasen ist, mit welchem Ziel sie durchgeführt werden. Wenn in ihnen das Ausmass der technischen Schulden unter eine Schwelle gedrückt werden  soll, ab der der Runaway-Effekt auftritt, ist das zumindest etwas, besser wäre ihr weitestmöglicher Abbau. Zum anderen ist entscheidend, ob danach ein erneutes Anstauen technischer Schulden zugelassen wird. Wenn ja, ist es nur eine Frage der Zeit, bis alles von vorne losgeht.

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:

The challenge with adding more engineers to a project. Just moving from 3 developers to 4 doubles the number of lines of communication. pic.twitter.com/sltsBUVq8w

— Rich Rogers (@RichRogersIoT) 1. Oktober 2017

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.

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.

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

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

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.

¹Ganz 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
²Was natürlich die Bereitschaft voraussetzt, diese Validierungen zeitnah vorzunehmen

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

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

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!"

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

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.

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.