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 Abstimmung
Governance 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.



1De jure fand die Gründung erst etwas später statt, durch die entsprechenden Anmeldungs- und Registrierungsvorgänge
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