Donnerstag, 16. Januar 2025
Autonomous teams require great managers
Gitte Klitgaard und Jakob Wolman sagen es in diesem Vortrag völlig zu Recht: die Ablehnung, die den Management-Rollen von weiten Teilen der agilen Community entgegenschlägt, ist nicht gerechtfertigt. Um als Team wirklich selbstorganisiert arbeiten zu können braucht es die richtigen Rahmenbedingungen, die jemand setzen muss, der sich mit Systemdesign auskennt - mit anderen Worten, es braucht einen guten Manager. Nur dann kann die für Selbstorganisation notwendige Ausgewogenheit zwischen Autonomie und Alignment entstehen.
Ganz nebenbei habe ich beim Anhören dieses Vortrags noch etwas dazugelernt: der Begriff der Selbstorganisation wurde 1790 von Immanuel Kant erfunden. Einmal mehr zeigt sich, was wir der Aufklärung alles verdanken.
Montag, 13. Januar 2025
Der Loop Approach
 |
| Bild: Pixabay / Norbert Waldhausen - Lizenz |
Zu den Beschwerden über die agilen Frameworks gehört mitunter, dass keine neuen mehr entwickelt werden würden, sondern sich alles auf wenige bestehende (v.a. Scrum, Kanban und SAFe) konzentriert. Unabhängig davon ob das denn schlimm wäre - es ist auch nicht zutreffend. Noch immer kommt es vor, dass neue Ansätze auftauchen, wie zum Beispiel dieser hier: der Ende der 2010er Jahre entstandene Loop Approach, der (was Seltenheitswert hat) aus Deutschland kommt.
Vieles von dem was den Loop Approach ausmacht, kennt man bereits aus agilen Frameworks: ein Selbstverständnis als Gegenentwurf zu kontrollierenden und direktiven Management-Methoden, ein Focus auf Team-interne Zusammenarbeit, einen Framework-Charakter, der zwar Rahmenbedingungen vorgibt, aber eigene Ausgestaltungen zulässt und einige zugrundeliegende Prinzipien, an denen man sich ausrichten kann um zu verhindern, dass diese Anpassungen versehentlich zu Dysfunktionalität führen.
Der Unterschied zu den anderen Frameworks ist, dass diese Prinzipien, die so genannten "Sieben Tugenden effektiver Organisationen", sequenziell angeordnet sind und in Summe den namensgebenden Loop bilden, also eine Schleife, die von einem Team beliebig oft durchlaufen werden kann, wenn es den eigenen Arbeitsmodus ändern möchte. Dabei ist der Loop nochmal unterteilt in drei "Schritte", die jeweils zwei oder drei Tugenden enthalten. Diese Anordnung sieht in Summe folgendermassen aus:
1. Schritt: Klarheit
1. Tugend: Klare Ausrichtung (Wofür ist das Team da?)2. Tugend: Gut genutzte Potentiale (Welche Fähigkeiten und Kenntnisse haben die Teammitglieder?)
3. Tugend: Verteilte Verantwortlichkeiten (Wie verteilen die sich auf Rollen?)
2. Schritt: Ergebnisse
4. Tugend: Individuelle Effektivität (Wie kann der Einzelne effektiv und selbstorganisiert sein?)5. Tugend: Effektivität als Team (Wie können Teams effektiv und selbstorganisiert sein?)
3. Schritt: Evolution
6. Tugend: Anpassungsfähigkeit (Wie werden Rollen und Regeln geschaffen und verändert?)7. Tugend: Feedback- und Konfliktkompetenz (Wie werden diese entwickelt und erhalten?)
Diese Anordnung mag auf den ersten Blick abstrakt wirken, wird im Loop Approach aber z.T. sehr detailliert ausgestaltet. Es gibt z.B für jedes einzelne Team einen Mindestbestand von fünf festgelegten Rollen mit jeweils festgelegten Aufgabenbereichen und vier Meetings mit vorgegebenem Zweck und schrittweise vorgegebenem Ablauf, dazu können vom Team noch beliebig viele weitere ergänzt werden. Im Einzelnen sind das:
Rollen:
Lead: Zuständig für Strategie und Zielsetzung
Coach: Zuständig für Team- und Einzelpersonen-Entwicklung
Tranzparenz [sic]: Zuständig für Information und Dokumentation
Facilitator: Zuständig für Meeting-Moderation
Loop Ninja: Zuständig für die Vermittlung des Loop Approach
Meetings:
Sync Meeting: Informationsaustausch und AbstimmungGovernance Meeting: Treffen wichtiger Entscheidungen
Clear the Air Meeting: Erkennen und Lösen von Konflikten
People Meeting: Feedback geben und Beziehungen stärken
Ob diese Menge an Rollen und Meetings (zu denen es in jedem Fall noch ins Detail gehende Beschreibungen gibt) viel oder wenig ist dürfte Ansichtssache sein. Im Vergleich zu vielen Konzern-oder Behördenprozessen ist es eher wenig, im Vergleich zu Startups oder Kleinbetrieben eher viel, im Vergleich zu Ansätzen wie Scrum oder SAFe mehr oder weniger vergleichbar. Die entscheidende Frage dürfte sein, wieviel ein Team diesem Mindestbestand noch hinzufügt.
Eine aufgezwungene Regulierung ist das Ganze aber in keinem Fall, dafür sorgt das Freiwilligkeits-Prinzip: jedes einzelne Team eines Unternehmens kann entscheiden, ob es an der Umsetzung des Loop Approach teilnimmt oder nicht, dabei ist die Entstehung von Insellösungen explizit als Option vorgesehen. Möglich wird diese Optionalität dadurch, dass der Loop Approach sich auf die Team-Ebene beschränkt und teamübergreifende Koordinationen bewusst nicht behandelt.
Der letzte Punkt dürfte auch der sein, an dem sich im Einzelfall die Brauchbarkeit des Loop Approach entscheidet. Dort wo es fachlich und technisch (teil-)autonome, crossfunktionale Teams gibt kann der Ansatz sicherlich Selbstorganisation fördern und eine Alternative zu Scrum oder Team-Kanban sein, dort wo es starke Abhängigkeiten zwischen Komponenten- oder Sequenz-Teams gibt, wird der Loop Approach aber schnell an harte Grenzen stossen, da er keine übergreifenden Koordinationsmechanismen enthält.
Und apropos nicht enthalten - es fällt auf, dass dieses Framework sich nicht damit beschäftigt, wie die eigentliche Arbeit effizienter oder effektiver werden soll. Es gibt keinen Value Stream, kein WIP-Limit, keine Lieferzyklen, kein Continuous Delivery, keine Automatisierung von Abläufen, keine Definition of Done. Es handelt sich um einen unspezifischen und ergebnisoffenen Change Management-Ansatz. Das ist auch absolut ok, man sollte es nur bei den eigenen Erwartungshaltungen berücksichtigen.
Was darüber hinaus Geschmackssache sein dürfte ist die (sehr transparent kommunizierte) Einbeziehung von Elementen aus kontroversen Ansätzen wie Holocracy, Gewaltfreier Kommunikation, Positiver Psychologie und Spiral Dynamics, die zwar nicht per se schlecht sind, bei denen es sich allerdings um nicht evidenzbasierte Modelle handelt, deren Wirksamkeit stark umstritten ist (die aber in der agilen Community trotzdem zahlreiche Anhänger haben).
Zuletzt sollte es jedem bewusst sein, dass hinter dem Loop Approach auch handfeste wirtschaftliche Interessen stehen. Genau wie bei einigen anderen agilen Frameworks gibt es auch hier den Verkauf von relativ kurzen, mehrere tausend Euro teuren Trainings, an deren Ende eine Zertifizierung verliehen wird. Wer derartige Praktiken grundsätzlich ablehnt wird mit dem Loop Approach genauso Probleme haben wie beispielsweise mit SAFe.
Für alle die das nicht abschreckt, oder die den Ansatz im Zweifel auch ohne Training und Zertifikat selbst ausprobieren wollen, kann er aber eine mögliche Alternative zu Scrum & Co sein. Und wenn das nächste mal jemand behauptet, dass es keine neuen agilen Frameworks geben würde, kann man aus eigener Erfahrung widersprechen.
Donnerstag, 9. Januar 2025
Gute und schlechte Prozesse
Manchmal sind die Dinge die man im Internet findet so gut, dass man sie nicht weiter verbessern muss. So auch in diesem Fall, der Beschreibung der Eigenschaften guter und schlechter Prozesse durch John Cutler auf Linkedin. Das einzige was ich gemacht habe, war die Übersetzung ind Deutsche, sonst sind sie so geblieben wie von ihm verfasst. Ich bin versucht, diese Liste von jetzt an auf jeden Einsatz mitzunehmen und dort mit allen anderen zu teilen.
Ein guter Prozess
- ermutigt zu Achtsamkeit.
- flexibel für lokale Belange.
- anpassungsfähig, häufig in Frage gestellt/verbessert.
- meistens gewollt, weil es wertvoll ist.
- Grundprinzipien werden verstanden.
- ermutigt zu Gesprächen/Kollaboration.
- mit den Anwendern gemeinsam erstellt/entworfen.
- Wert für alle Beteiligten.
- stärkt das Vertrauen in die Ergebnisse.
- reduziert auf die Kernaufgabe (leichtgewichtig).
- erzielt lokale Konsistenz mit minimalen Auswirkungen auf die Resilienz. Verbessert globale Ergebnisse.
- Verbesserung des Nutzens für die Endkunden.
- Leitfaden/Werkzeug/Navigieren/Erinnern.
- verbessert das Vertrauen/die Sicherheit.
Ein schlechter Prozess
- ermutigt zu Unachtsamkeit.
- unflexibel gegenüber lokalen Belangen.
- in Stein gemeißelt/nicht verhandelbar.
- meistens den Teilnehmern aufgezwungen.
- automatische/erzwungene Befolgung.
- reduziert die Qualität/Quantität von Gesprächen.
- entworfen im Vakuum und aufgezwungen.
- einseitiger Wert.
- losgelöst von den Ergebnissen.
- belastet durch viele Aufgaben/Zuständigkeiten.
- erzielt lokale Konsistenz zum Nachteil der Resilienz und der globalen Ergebnisse.
- abgekoppelt vom Kundenwert.
- Kontrolle/Anleitung.
- Vertrauensersatz, Sicherheitsersatz.
Und für eine bessere Übersicht ist es hier nochmal als Gegenüberstellung:
Montag, 6. Januar 2025
PMI goes Agile (III) - and the Agile Alliance goes PMI
 |
| Screenshot: agilealliance.org |
Wer sich als Mitglied der agilen Bewegung am ersten Januar-Wochenende des Jahres 2025 in die sozialen Medien begeben hat, der wird an einem Thema nicht vorbeigekommen sein: dem Beitritt der Agile Alliance zum Project Management Institute (PMI), verbunden mit den üblichen Schnellschuss-Kommentaren (Agile is dead, PMI wird jetzt agil, etc.). Die kann man bedenkenlos ignorieren, die Frage aber bleibt - was ist da eigentlich passiert? Gehen wir die wichtigsten Punkte durch.
Wer sind Agile Alliance und PMI?
Bei beiden handelt es sich um Berufsverbände, denen sowohl Einzelpersonen als auch andere Organisationen angehören können. Das PMI wurde bereits 1969 gegründet und hat als Ziel die Entwicklung von Best Practices im klassischen Projektmanagement, wozu es auch mehrere Zertifizierungen vergibt. Die Agile Alliance besteht erst seit 2001 und hat das gleiche Ziel, wenn auch mit einem deutlich schärferen Fokus, der naheliegenderweise auf den agilen Methoden und Praktiken liegt.
Wie genau sieht der Beitritt aus?
Einseitig. Die Agile Alliance ändert ihren Namen in "PMI Agile Alliance", Vorstand und Stabsstellen der Agile Alliance welchseln zum Project Management Institute und wie aus den Informationsmails an die Mitglieder der Agile Alliance hervorgeht, werden die bisherigen Initiativen zukünftig "with PMI’s infrastructure and strategic oversight" weitergeführt. Wie auch immer das konkret aussehen wird, ein Zusammenschluss auf Augenhöhe ist es nicht.
Warum führt dieses Zusammengehen in der agilen Community zu vielen heftigen Reaktionen?
Zunächst, weil die Agile Alliance die agile Bewegung massgeblich gestaltet hat. De facto fand ihre Gründung am selben Tag und Ort statt wie die Verfassung des Manifest für agile Softwareentwicklung, dessen Verfasser sich direkt im Anschluss diesen Namen gaben.1 Während der ersten Jahre war die Agile Alliance damit der einzige agile Berufsverband und ihre Konferenz (die einfach Agile + Jahreszahl heisst, z.B. Agile 2025) die einzige agile Konferenz. Sie hat also eine historisch bedingte hohe Symbolik.
Ausserdem weil viele Mitglieder der agilen Bewegung sich als Teil eines bewussten Gegenentwurfs zum traditionellen Projektmanagement verstehen, und gleichzeitig im PMI die Verkörperung all dessen sehen, was sie ablehnen: schwergewichtige Strukturen und Prozesse, zahlreiche Anleitungen und Vorschriften, umfangreiche Dokumentationspflichten, etc. Der Beitritt der Agile Alliance zum PMI fühlt sich für diese Menschen wie ein Verrat, bzw. eine feindliche Übernahme an.
Zuletzt war die Agile Alliance die einzige grössere unter den nach und nach entstehenden agilen Branchenorganisationen, die sich der Kommerzialisierung durch den Verkauf von Zertifizierungen verweigert hat, bzw. darauf bestanden hat, dass diese nicht nur auf Wissensprüfungen sondern vor allem auf Praxiserfahrungen beruhen müssten.2 Vor diesem Hintergrund ist das Zusammengehen mit dem PMI, das ausschliesslich wissensbasierte Zertifizierungen anbietet, nochmal kontroverser.
Warum findet es dann statt?
Vereinfacht gesagt: weil die Agile Alliance pleite ist. Mit der Zeit hat sie einen immer grösseren Kostenapparat entwickelt, der von Hosting-Kosten bis hin zu Reisekostenerstattungen alles Mögliche umfasst. Wie man bei den Mitgründern Mike Cohn und Ron Jeffries nachlesen kann, haben die Mitgliedbeiträge nie gereicht um das zu decken. Das ging nur über die Einnahmen aus der Konferenz, die durch Covid-Pandemie und Wirtschaftskrisen eingebrochen sind.3 Es ist also eine Sanierungsfusion.
Wie schlimm ist das alles?
Je nach Betrachtungsweise sehr bis gar nicht. Dass das PMI jetzt die "agile Ur-Organisation" absorbieren und ggf. in Teilen (z.B. bei den Zertifikaten) in ihr Gegenteil verkehren könnte, ist von einem nostalgischen Blickpunkt aus natürlich eine besorgniserregende Perspektive. Andererseits hat PMI bereits viele agile Inhalte übernommen, nicht nur durch den Kauf der Disciplined Agile-Zertifizierungs-Organisation, sondern auch durch eine Anpassung der eigenen Inhalte. Es gibt also Schnittmengen.
Über die Agile Alliance muss man gleichzeitig auch sagen, dass sie zwar zu den aufrechten Bewahrern der ursprünglichen Praxis- und IT-nahen agilen Prinzipien und Praktiken gehört, es aber nicht geschafft hat, sich ihre ursprüngliche Bedeutung zu bewahren (ironischerweise auch wegen ihrer Kommerzialisierungs-Veigerung, während z.B. die Scrum Alliance durch Zertifizierungen gross und reich wurde). Die heutige Mehrheit der weltweiten Agile Coaches und Scrum Master dürfte noch nichtmal von ihr gehört haben.
Und zur ganzen Wahrheit gehört auch, dass die Agile Alliance der agilen Bewegung schon lange keine neuen relevanten Impulse mehr geben konnte. Gerade in den letzten Jahren hat sich stattdessen eher der Sog der Addition bemerkbar gemacht - auf einmal gab es hier Initiativen, die für den Umweltschutz oder gegen den Rassismus kämpfen wollten. Sehr ehrenhaft, aber für einen IT- und Projektmanagement-Fachverband etwas abwegige Themen. Teile der Kern-Klientel hat das eher abgeschreckt.4
Und jetzt?
Und jetzt warten wir ab was passiert. Der grosse Gewinner der ganzen Geschichte ist das Project Management Institute, das ab jetzt den eigenen (halb-)agilen Anzatz mit einer Tradition legitimieren kann, die sich lückenlos bis zum Manifest für agile Softwareentwicklung zurückverfolgen lässt. Ob man die Agile Alliance irgendwie weiterbestehen lässt, sie ins eigentliche PMI absorbiert oder versucht sie mit dem eigenen Zertifizierungs-Brand Disciplined Agile zu verschmelzen wird sich noch zeigen.
Und für alle, die nicht in einer der beiden Organisationen Mitglied sind, und die kein gesteigertes Interesse an der Geschichte der agilen Bewegung oder des IT-nahen Projektmanagement-Verbandswesens haben, gilt: bitte gehen Sie weiter, hier gibt es nichts Interessantes zu sehen, ausser einem Sturm im Wasserglas.
2solche Zertifizierungen haben sich im agilen Bereich nie etabliert und wären vermutlich auch nie ein Business Case geworden
3Anscheinend hat die Agile Alliance für ihre Konferenz auch langfristige Verträge abgeschlossen, aus denen sie nicht herauskommt
4Auf Linkedin waren nach der Bekanntgabe des Zusammengehens viele Beiträge mit diesem Tenor zu lesen
Dienstag, 31. Dezember 2024
Kommentierte Links (CXXII)
 |
| Grafik: Pixabay / Brian Penny - Lizenz |
Martin Fowler: Continuous Integration
Agile Produktentwicklung kann durch Methoden wie Scrum, Kanban und die Skalierungsframeworks einfacher werden, mindestens genau so wichtig sind aber bestimmte technische Aspekte. Martin Fowler, einer der Verfasser des Manifests für agile Softwareentwicklung, hat sich mit Continuous Integration einen davon herausgesucht und in diesem epischen Essay (über 80.000 Zeichen!) alles was man zu diesem Thema wissen sollte zusammengefasst - bzw. fast alles, aber für alles andere enthält er Buchempfehlungen und weiterführende Links. Für jeden der bei diesem Thema mitreden möchte, eine absolute Empfehlung.Donald 'Mark' Haynes: An Agile focus on minimalism
Das was Mark Haynes hier hervorhebt ist eine zu oft vergessene Wahrheit: wer mit agilem Arbeiten erfolgreich sein will, der muss in der Kunst des Minimalismus geübt sein, da grosser Umfang und komplizierte Zusammenhänge sehr schnell zu Schwerfälligkeit und Langsamkeit führen. Was man bei ihm lernen kann ist, dass dieser Minimalismus nahezu überall anwendbar ist - bei Prozessen, bei Entwicklungspraktiken, in der Software-Architektur und in Anforderungen. Was daraus folgt: bei agilen Transitionen sollte es weniger um das Hinzufügen von Rollen, Regeln, Prozessen und Praktiken gehen und mehr darum, möglichst viele bestehende abzuschaffen.
Christiaan Verwijs: Why Teams Need Composition Autonomy
Das hier ist eine kontroverse, aber interessante Meinung. Christian Verwijs ist davon überzeugt, dass ein wesentlicher Aspekt autonomer Teams sein sollte, dass sie ein Mitspracherecht bei der Frage haben sollten, wer ihnen angehört. Wichtig für das Verständnis seiner Ausführungen ist dabei, dass er die Gewährung dieser Mitsprache-Rechte nicht als Alles oder Nichts-Entscheidung sieht, sondern dazwischen eine Skala definiert, auf der unterschiedliche Teams unterschiedlich eingeordnet werden können (und auf der sie sich auch noch weiter hin- und herbewegen können).Jeff Gothelf: Aligning, Not Cascading, OKRs with an OKR Lineage
Nachdem die Objectives and Key Results von der agilen Bewegung "adoptiert" wurden, stellte sich bei ihnen in kürzester Zeit die gleiche Frage, deren Beantwortung auch von den anderen agilen Frameworks verlangt wurde: wie funktioniert das im grossen Massstab? Jeff Gothelf hat sich den beliebtesten OKR-Skalierungsansatz, die "kaskadierenden OKRs" angeschaut und für nicht gut befunden, hat aber auch eine bessere Alternative im Angebot: die Lineage OKRs (Abstammungs-OKRs). Statt Ziele von oben nach unten durchzureichen, werden sie hier dezentral erstellt, müssen dabei aber einen Bezug zur nächsthöheren Ebene aufweisen können.Melissa Perri: Building a Great Product Management Organization
In Teilen der US-amerikanischen Tech-Szene hat mittlerweile der Begriff "Product" (bzw. Product Management) den Begriff Agile verdrängt oder assimiliert. Dieser Artikel von Melissa Perri (einer der bekanntesten Product Management-Vordenkerinnen) zeigt gut auf, wie dort eine produktorientierte Organisation verstanden wird, was sie beinhalten sollte und woran man Dysfunktionen erkennt. Ein Vergleich zu den üblichen Agile-Talking Poin ist durchaus interessant, da man sowohl Gemeinsamkeiten als auch Unterschiede erkennen kann (z.B. die Thematisierung von Karrierepfaden).Benjamin Ross Hoffmann: Systems of Bullshit Work
Dieser Text ist ein bisschen Meta, da sich Benjamin Ross Hoffmann in ihm auf das Buch Bullshit Jobs bezieht, in dem der Ethnologe David Graeber einen Grossteil der heutigen Jobs als unnötig bezeichnet. Hoffmann differenziert das aus, indem er erklärt, durch welche Faktoren es zum Entstehen dieser Jobs kommt. Wer schon einmal fehlgeschlagene agile Transformationen erlebt hat wird vieles aus denen hier wiederfinden, z.B. im achten Beispiel: Your job might be to perform a ritualized imitation of a service that would be useful if genuine. Es dürfte den einen oder anderen Scrum Master geben, auf den das zutrifft.Maarten Dalmijn: The Era of Copy-Paste Agile Is Over
Maarten Dalmijn hat sich im vergangenen Jahr einen Namen damit gemacht, den aktuellen Zustand der agilen Bewegung, bzw. des agil industriellen Komplex, wortgewaltig zu kritisieren. Auch an dieser Stelle macht er damit weiter, diesesmal mit der Hypothese, dass die gängigen agilen Frameworks den Widerstands- und Beharrungskräften grosser Organisationen nicht gewachsen sind und darum fast zwangsläufig scheitern müssen. Diese Ansicht (und die von ihm vorgeschlagene Alternative) muss man nicht teilen, als provokanter Denkanstoss ist sie aber durchaus wertvoll.Marty Cagan: Transformation as a Project
Eines der grossen Mantras der agilen Bewegung und der Produktorientierungs-Bewegung ist, dass sie weg von der projektbasierten Organisationsform wollen, die in den meisten grossen Organisationen der Standard ist. Und beide leiden unter der tragisch-ironischen Situation, dass sie mit ansehen müssen, dass viele Versuche ihre Ansätze einzuführen dann doch wieder als Projekt durchgeführt werden, mit all den Problemen die damit verbunden sind. Marty Cagan thematisiert diese Dysfunktion ebenfalls, hat aber auch Ideen wie es besser gehen kann: durch kleine Anfänge, schnelle Lernzyklen, asynchrone Fortschritte und kontinuierliche Optimierung. Wie auch sonst?, möchte man fragen.John Cutler: Why Orgs Become Too Tall
Dass John Cutler seinen Ruf als ausgezeichneter "Systems Thinker" nicht von ungefähr hat, wird (spätestens) aus diesem Blogpost klar. Ausgehend von der weit verbreiteten Beschwerde, dass viele Organisationen zu gross und zu bürokratisch sind, analysiert er, welche sich wiederholenden Muster dafür sorgen, dass es immer wieder dazu kommt. Das ist zum einen erhellend, zum anderen aber auch hilfreich, da es aufzeigt, an welchen Stellschrauben gedreht werden kann, um Organisationen wieder zu verschlanken und Bürokratie abzubauen.Nigel Baker: What Has Gone Wrong - And How To Fix It.
Apropos Systems Thinking: in diesem Blogpost von Nigel Baker findet sich einiges davon (und daneben auch Humor und Polemik, was das Ganze sehr lesenswert macht). Das Thema, das er derartig beleuchtet, ist (ähnlich wie weiter oben bei Maarten Dalmijn) der Zustand der agilen Bewegung. Wer dieses recht zähe Thema gerne launisch und unterhaltsam aufbereitet haben möchte, ist an dieser Stelle richtig.Freitag, 27. Dezember 2024
Kommentierte Links (CXXI)
 |
| Grafik: Pixabay / Geralt - Lizenz |
The Burndown: Continuous Improvement – The Kaizen Way
Dass agile Produkt- und Softwareentwicklung ihren Ursprung im Lean Management hat ist unter Methodikern ein Allgemeinplatz, was das im Konkreten bedeutet bleibt aber häufig unklar. The Burndown leistet hier Aufklärungsarbeit und hebt zwei zentrale Aspekte hervor: zum einen ist das Verbesserungsziel die Steigerung der Wertgenerierung, statt wie im klassischen Management der Produktivität, zum anderen erfolgt die Verbesserung kontinuierlich in kleinen Schritten statt in seltenen, aber dafür grossen Schüben. Gut auf den Punkt gebracht.Willem-Jan Ageling: 7 Hacks to Scale Agile Without Overly Complicated Frameworks
Diese Liste von Willem-Jan Agelings sieben "Hacks", mit denen man ohne übermässig komplizierte Frameworks Agilität im grossen Massstab erreichen kann, ist eine interessante Zusammenstellung, und das alleine deshalb weil sie sowohl Praktiken als auch Organisationsprinzipien als auch Haltungen enthält - in den meistens derartigen Zusammenstellungen kommt nur jeweils eine dieser Kategorien vor. Wer sich mit den agilen Skalierungsframeworks auskennt wird hier sowohl Elemente von LeSS und Nexus als auch von SAFe wiedererkennen. In gewisser Weise der Versuch ein "Best of" zu extrahieren.Doc Norton: Frequent releases improve outcomes
In der agilen Community dürfte Doc Norton mit seiner Aussage, dass häufige Releases zu besserer Ergebnisqualität führen, offene Türen einrennen, in klassisch geprägten Unternehmen herrscht allerdings immer noch die gegenteilige Meinung vor. Da diese Ablehnung meistens auf der nachvollziehbaren Sorge beruht, Geschwindigkeit nur auf Kosten der Qualitätssicherung erreichen zu können, geht Norton auch darauf ein, mit einer wichtigen Klarstellung - natürlich muss zuerst an dieser gearbeitet werden, und zwar so, dass auch sie in hoher Frequenz nötig ist. Iccha Sethi: Tying Engineering Metrics to Business Metrics
Dieser Artikel ist wirklich interessant, da er sich eines weit verbreiteten Problems annimmt: sowohl Business als auch IT verfügen über Metriken, mit deren Hilfe sie Fortschritte und Ergebnisse überprüfen, es sind aber in den meisten Fällen keine gemeinsamen, sondern nur solche, die jeweils auf nur einer Seite verwendet werden und die der anderen als wenig nachvollziehbar oder wenig wichtig erscheinen. Dadurch dass sie hier zueinander in Beziehung gesetzt und miteinander verbunden werden, wird es einfacher gemeinsame Ziele zu definieren und auf sie hinzuarbeiten.Charity Majors: “Founder Mode” and the Art of Mythmaking
Eines der grossen Buzzwords des Jahres 2024 ist "Founder Mode" gewesen, ein Management-Ansatz, der durch Brian Chesky, einen der Gründer von AirBnB, erfunden und popularisiert wurde. Er stellt so ziemlich das Gegenteil aller anderen modernen Management-Ansätze dar, da er sowohl ein mittleres Management als auch crossfunktionale, empowerte, autonome Teams ablehnt und stattdessen alles auf eine einzige alleinentscheidende Person (den Founder) ausrichtet. Da es Chesky auf diese Art gelungen ist, sein Unternehmen aus der Krise zu führen, ist dieses Vorgehen zumindest eines mit dem man sich beschäftigen sollte, um darüber mitreden zu können. Charity Majors hat das dankenswerterweise gemacht, indem sie das Interview, in dem Chesky seinen Founder Mode vorstellt, ausführlich analysiert hat. Das Kurz-Fazit: Chesky hat die Schieflage seines Unternehmens nicht nur behoben, er hat sie vorher auch selber verursacht. Sein Management-Ansatz ist daher mit Vorsicht zu betrachten, selbst wenn er auch sinnvolle Elemente enthält.Montag, 23. Dezember 2024
The 12 Days of Scrum
Dass es auf Youtube eine ganze Reihe von Liedern über agiles Arbeiten gibt ist schon bemerkenswert genug, aber dass es darüber hinaus auch noch "agile Weihnachtslieder" gibt, fasziniert mich immer wieder. Hier ist das nächste, eine Coverversion des englischen Klassikers The twelve Days of Christmas:Und für alle die jetzt in der entsprechenden Stimmung sind - hier sind fünf weitere, die ich in den vergangenen Jahren bereits geteilt habe:
- Agile Night Xmas
- An Agile Little Christmas
- Agile Christmas Eve in Lockdown
- Agile Xmas Song
- Do they know this Agile Thing?
Für die Playlist nach dem einen Eggnogg zu viel.
Freitag, 20. Dezember 2024
Agile Success Stories: The Power of limited WIP
Leider ist es unverkennbar, dass viele Mitglieder der agilen Bewegung mit der Zeit eine eher negative Grundeinstellung 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, veröffentliche ich
ab und zu selbst erlebte "agile Erfolgsgeschichten". So wie diese hier.
Es war in einem meiner letzten Einsätze als klassischer Projektleiter. Ein grosser Mittelständler hatte vor, seine Website einem Relaunch zu unterziehen, inclusive des dort eingebundenen Shops. Insgesamt fünf Teams arbeiteten daran, aus der IT, aus dem Marketing und aus der Unternehmenskommunikation, und wie mir im Vorfeld gesagt wurde, war das Meiste schon fertig. Als externe Krankheitsvertretung des Projektleiters sollte ich nur noch die letzten Arbeiten koordinieren.
Die Realität, die ich vorfand, war dann allerdings eine andere. Zwar war die Arbeit tatsächlich schon weit fortgeschritten, die einzelnen Teile (Shop, CMS, Redaktionssystem, Single Sign on, etc.) passten aber an keiner Stelle zusammen. Jeder Versuch, irgendetwas fertigzustellen oder mit irgendeinem anderen Teil zu verbinden, führte zu einer Kaskade an Fehlermeldungen. Und mit gleicher Zuverlässigkeit ergoss sich regelmässig eine Kaskade aufgebrachter Stakeholder in das Projektleitungs-Büro.
Genau das erwies sich auch als die Ursache des Problems. In früheren Projektphasen hatte jeder Stakeholder ständig seine Wünsche in das Projekt einbringen dürfen. Und aus dem Wunsch heraus, alle gleich gut zu behandeln, hatte die alte Projektleitung die Teams angewiesen, an allem gleichzeitig zu arbeiten. So war es dazu gekommen, dass zwar Alles angefangen war, aber Nichts fertig, Nichts integriert, Nichts getestet und Nichts funktionierend.
Der einzige Vortrteil an dieser Situation war, dass das Projekt intern bereits als gescheitert galt, und alle Manager sich fern von ihm hielten, um zu verhindern, dass sie mit ihm in Verbindung gebracht wurden (das war auch der wahre Grund, warum ich als Externer der Projektleiter geworden war). Dadurch hatte ich relativ grosse Freiheiten, um neue Wege auszuprobieren. Nur welche das sein sollten, war mir noch nicht kar - also fragte ich die Entwicklungsteams. Und die hatten tatsächlich eine Idee.
Statt gleichzeitig an allem zu arbeiten und nirgendwo weiterzukommen wollten sie sich immer nur auf ein Feature konzentrieren, das fertigstellen, testen und integrieren, dann das Gleiche mit einem zweiten machen, dann mit einem dritten, und so weiter. Um zu zeigen, dass sie dabei wirklich vorankommen würden, boten sie mir einen täglichen kurzen Statusbericht an, vor einem Board auf dem der Fortschritt jedes Arbeitspaketes visualisiert wurde. Kanban nannten sie das (der Begriff war mir damals noch neu).
Der Beitrag, den ich dazu leisten musste, war, ihnen alle Stakeholder vom Hals zu halten, an deren Feature gerade nicht gebaut wurde. Mit Erbitterung und erstaunlicher Ausdauer drangen diese darauf, dass jetzt doch auch endlich sie wieder an der Reihe sein müssten, verlangten Fortschrittberichte, brachten neue Ideen auf, die sie noch spät in die Umsetzung einbringen wollten und eskalierten ständig beim Top-Management (das sich aus den oben genannten Gründen aber heraushielt). Ein Vollzeit-Job.
Während ich mir also irgendwo Powerpoint-Saalschlachten mit uneinsichtigen Leuten lieferte, wurden so fast unbemerkt die ersten Funktionen fertig. Zu Beginn noch mit Ablehnung aufgenommen ("Was? Nur so wenig? Da fehlt doch noch alles andere!") wurden sie nach und nach mehr und mehr. Und mit diesen frühen Funktionsumfängen gelang das erste kleine Wunder: als die ersten Stakeholder sahen, dass ihre Kernfunktionen fertig waren, waren sie fürs Erste zufrieden und zogen ihre Zusatzwünsche zuück.
Die verbliebenen kämpften zwar um so verbissener für ihre Interessen, da jeder befürchtete, dass am Ende für die Letzten keine Zeit und kein Budget mehr übrig sein würde, aber die Runden wurden nach und nach kleiner und beherrschbarer. Und irgendwann gelang das zweite kleine Wunder. Nachdem die konzentrierte Arbeit dazu geführt hatte, dass die Teams endlich liefern konnten, wurde ihren Zeitplänen auf einmal Glauben geschenkt und die Eskalationen wurden seltener.
Das aus der Sicht des Unternehmens grösste Wunder fand aber ganz zum Schluss statt: nach der Fertigstellung eines zufriedenstellenden Funktionsumfangs hatten sich alle auf das eingerichtet, was sie in vergangenen Projekten als unvermeidbaren Teil der Softwareentwicklung kennengelernt hatten - eine lange und für alle Beteiligten quälende Phase des Software-Testens und Reparierens, bei der nie so ganz abbsehbar war, wie lange sie dauern würde. Diesesmal aber was diese Phase kurz und schnell vorbei.
Der Grund dafür war, dass jede fertiggestellte Funktion sofort mit den anderen integriert und zusammen mit ihnen getestet worden war. Und da immer nur an einer gearbeitet wurde, waren die jeweils neuen Umfänge und Fehlerquellen immer überschaubar gewesen, wodurch sich die Test- und Reparatur-Aufwände in Grenzen gehalten hatten. Statt erst ganz am Ende mit der Qualitätssicherung beginnen zu müssen, war das meiste davon zu diesem Zeitpunkt schon abgeschlossen.
Am Schluss war auf diese Weise einiges von der zwischenzeitlichen Verspätung aufgeholt worden, und das Projekt endete mit jeweils zehn Prozent Zeit- und Budget-Überschreitung. In der gesamten jüngeren Unternehmensgeschichte (in der nie ein IT-Projekt pünktlich fertiggeworden war), war das der beste Wert an den man sich erinnern konnte. Und für mich selber war es der Anstoss, nur noch so arbeiten zu wollen (was ich mittlerweile auch geschafft habe).
