Kommentierte Links (CXXIII)

Grafik: Pixabay / Brian Penny - 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.

David Pereira: The Refactoring Guide for PMs Tired of Endless Tech Discussions

Eine der klassischen Herausforderungen, an denen (nicht nur agile) Entwicklungsteams scheitern, ist die Erklärung von Refactoring für Menschen ohne IT-Hintergrund. Wer mal wieder in dieser Situation ist, kann sich an diesen Artikel von David Pereira halten. In ihm wird nicht nur das Konzept erklärt, sondern auch warum es wichtig ist, wie mayn es falsch machen kann, wie man es richtig machen kann, wann man es machen sollte und was typische Formen von Refactoring sind.

Jeff Gothelf: OKRs for Organizational Agility

Auf die Gefahr hin, versehentlich in die Falle von Maslows Hammer zu laufen - man kann Objectives und Key Results (OKRs) eigentlich für so gut wie alles benutzen. Jeff Gothelf zeigt hier ein eher selten verwandtes Einsatzgebiet auf: die Verwendung von OKRs für agile Transitionen (oder wie er es nennt, organisatorische Agilität). Im Wesentlichen geht es dabei darum, Reaktions- und Durchlaufzeiten messbar zu verkürzen. Schlicht, aber wirkungsvoll.

Erik de Bos: Using the Flow Channel to Measure Team Effectiveness

Neben dem Durchfluss von zu erledigenden Aufgaben durch ein Verarbeitungssystem hat der Begriff Flow im Arbeitskontext eine zweite Bedeutung: den idealen Zustand, in dem eine Person oder ein Team werder überfordert noch unterfordert ist, und daher hochmotiviert und leistungsbereit. Erik de Bos differenziert das mit Hilfe des so genannten Flow Channel aus, in dem ein Team versuchen kann, dauerhaft zu bleiben, um optimale Ergebnisse erbringen zu können.

Marty Cagan: The Product Model and Agile

Dieser Blogpost hier ist durchaus erstaunlich, da sein Verfasser, Produktmanagement-Thought Leader Marty Cagan, über lange Zeit dafür bekannt war, öffentlich schlecht über agile Rollen und Frameworks zu sprechen. Irgendetwas scheint seine Meinung geändert zu haben, denn auf einmal findet er es nicht nur grundsätzlich ok wenn agil gearbeitet wird, er erkennt sogar an, dass Agile Coaches dazu einen wertvollen Beitrag leisten können - was er allerdings vor allem im Delivery-Bereich sieht.

Sebastian Sigl: High-Performing Teams Focus On These 4 Areas to Remain Successful

Zugegeben, Sebastian Sigls Überschrift klingt auf den ersten Blick so, als würde als nächstes eine Plattitüden-Sammlung folgen. Tatsächlich ist seine Übersicht aber durchaus sinnvoll, denn er zählt nicht nur die vier Bereiche auf (Anpassungsfähigkeit, Zielsetzung, Psychologische Sicherheit und Feedback), sondern er zeigt auch Fehler auf die man vermeiden sollte, wenn man hier besser werden möchte - darunter auch einige unerwartete, wie z.B. ein zu grosses Vertrauen in Expertenwissen.

Zwerge auf den Schultern von Riesen

Bild: Wikimedia Commons / Japanische Akademie der Wissenschaften - CC BY 4.0

Manchmal kommen die tragischen Entwicklungen schnell und unverhofft. Nur zwei Tage nachdem ich sein bahnbrechendes Paper The New New Product Development Game empfohlen habe ist Ikujirō Nonaka gestorben, einer der grossen Vordenker der Methoden, die wir heute ale Agil bezeichnen würden. Was dadurch in Erinnerung gerufen wird: leider müssen wir uns in den nächsten Jahren auf weitere derartige Trauer-Nachrichten einstellen - und die werden Folgen haben.

Zur Einordnung: grossteils aufbauend auf das oben erwähnte Paper sind die meisten agilen Vorgehensmodelle (Scrum, XP, IT-Kanban, Agile Testing, etc) zwischen den späten 80er und frühen 2000er Jahren entstanden. Da ihre Erfinder bereits damals über einige Jahre oder sogar Jahrzehnte Berufserfahrung verfügten, sind sie mittlerweile in ihren 60ern, 70ern oder 80ern angekommen. Und obwohl sie hoffentlich noch lange leben werden - nicht jeder dürfte 90 werden, so wie Nonaka.

Das ist deshalb von Bedeutung, weil diese Vordenker bisher durch ihre öffentlichen Meinungsäusserungen ein Korrektiv zu den verbreiteten esoterischen oder komerziell getriebenen Fehldeutungen ihrer Arbeit bilden konnten, legitimiert dadurch, dass sie schliesslich selbst am Besten sagen können, was sie mit ihren Ansätzen beabsichtigt haben und was nicht (das bekannteste Beispiel dafür dürfte ihre einhellige Ablehnung des Scaled Agile Framework / SAFe sein).

Mit dem absehbaren Verschwinden dieser Stimmen (das auch bereits durch einen altersbedingten Rückzug aus der Öffentlichkeit geschehen kann) dürfte es in der Zukunft immer weniger mit einer derartigen Autorität ausgestattete Widersprüche gegen absichtliche oder versehentliche Verfremdungen der agilen Ideen und Prinzipien geben. Und noch bedenklicher: kommerzielle Organisationen wie Scrum Alliance, SAFe, Kanban University und PMI werden diese Autorität vermutlich für sich beanspruchen.

Um so wichtiger wird es werden, die von den agilen Pionieren verfassen Originalquellen (von denen es aufgrund der Entstehung der Agilität in den Schatten ohnehin viel zu wenige gibt) in Erinnerung zu behalten und als Massstab für die Bewertung neuer Entwicklungen zu benutzen, von der Forschung Nonakas und Takeuchis über die frühen Vorträge auf den OOPSLA- und Agile-Konferenzen bis zu den Büchern und Artikeln der Verfasser des Manifests für agile Softwareentwicklung.

Die grosse Herausforderung dabei wird es sein, derartig auf den Schultern der Riesen zu stehen, dass deren Absichten gewahrt bleiben, ohne dass es zu einer rückwärtsgewandten Erstarrung der damit verbundenen Methoden kommt. Andererseits - verglichen mit dem, was zwischen den späten 80er und frühen 2000er Jahren geleistet wurde, ist das eine fast schon einfache Aufgabe. Und noch haben wir genug Zeit um uns von den agilen Vordenkern inspirieren zu lassen.

Ein Hoch auf die Wissenschaft

Wenn man Aussagen sucht, auf die die agile Bewegung sich einigen kann, dann wird man schnell auf die stossen, dass agiles Arbeiten Empirie- und Evidenz-getrieben sein sollte, oder mit anderen Worten: wissenschaftlich. Ernst genommen bedeutet das zum Einen, dass man im Kleinen selbst versuchen sollte, so vorzugehen, zum Anderen aber auch, dass man sich für wissenschaftliche Erkenntnisse interessieren sollte, die das eigene Arbeitsfeld betreffen - und wer danach sucht, findet Einiges.

Ich bin mit der Zeit auf eine ganzen Reihe wissenschaftlicher Papers gestossen und spiele gerade mit dem Gedanken, eine Beitragsreihe zu starten, in der ich jeweils einige von ihnen vorstelle. Ob es wirklich dazu kommt wird sich zeigen, für den Moment habe ich aber zumindest fünf, die mir erwähnenswert erscheinen. Sie gehen quer durch alle möglichen Themen durch und sind natürlich eine subjektive Auswahl, aber eine die ich empfehlen möchte. Hier sind sie:

Takeuchi, Hirotaka; Nonaka, Ikujiro: The New New Product Development Game

Eine der Initialzündungen dessen, was wir heute agile Produktentwicklung nennen. Vereinfacht gesagt haben Takeuchi und Nonaka Feldforschung betrieben um herauszufinden, warum manche Firmen effektiver Produkte entwickeln als andere. Ihre Forschungsergebnisse sind zwar schon 40 Jahre alt, haben aber nichts von ihrer Aktualität eingebüsst.

Verwijs, Christiaan; Overeem, Barry: The Double-Edged Sword Of Diversity In Teams

Manchmal tun Erkenntnisse weh. Verwijs und Overeem haben versucht, den in der agilen Bewegung verbreiteten Glaubenssatz zu validieren, dass Diversität in Entwicklungsteams etwas grundsätzlich Gutes ist. Ihre Erkenntnis - ganz so einfach ist es nicht. Zwar gibt es eindeutig positive Effekte, in einigen Dimensionen ist Diversität aber ohne Auswirkungen oder führt sogar zu Nachteilen.

Eilers, Karen; Peters, Christoph; Leimeister, Jan: Why the agile mindset matters

Diese Arbeit ist wirklich verdienstvoll. Zum ersten mal habe ich hier gesehen, wie versucht wird, den umstrittenen Begriff des "Agilen Mindset" neutral und sachlich einzuordnen und zu untersuchen. Ein wohltuender Kontrast zu dem eher esoterischen und zum Teil sogar übergriffigen Umgang, der sonst in der Beschäftigung mit diesem Begriff vorherrschend ist.

Flyvbjerg, Bent; Budzier, Alexander: Why Your IT Project May Be Riskier than You Think

Der bemerkenswerte Forschungsschwerpunkt von Bent Flyvbjerg sind (scheiternde) Grossprojekte. Dass die häufig ausser Kontrolle geraten ist zwar bekannt, er differenziert es aber entscheidend aus. Vereinfacht gesagt: es geht nicht immer schief, aber wenn es schiefgeht, dann richtig. Und: die Gründe dafür sind identifizierbar und es gibt erfolgsversprechende Gegenmassnahmen.

Kühl, Stefan: Das Scharlatanerieproblem – Zwischen Professionsbildung und Professionalisierung

Noch einmal Erkenntnisse, die weh tun. Über die Zeit hat sich Stefan Kühl die Rolle des Hofnarren der (agilen) Berater-Szene erarbeitet, der er ihre Unzulänglichkeiten aus soziologischer Perspektive und mit erkennbarer Freude vorhält. An dieser Stelle mit Fokus auf einem der grossen strukturellen Defizite: dem weitgehenden Fehlen verbindlicher professioneller Standards zur Qualitätssicherung ihrer Arbeit.

Agile Sucess Stories: Die agile Revision

Bild: Pexels / Vlada Karpovich - Lizenz

Leider ist es so, dass viele "agile Methodiker" (Agile Coaches, Scrum Master, etc.) mit der Zeit eine eher negative Weltsicht 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, möchte ich dagegenhalten, indem ich ab und zu selbst erlebte "agile Erfolgsgeschichten" veröffentliche.

Diese hier hat sich in einem grossen Unternehmen in einer gesetzlich regulierten Branche zugetragen. Die Einhaltung dieser Regulierungen wurde von einer eigenen Abteilung überprüft, der Revision, die von Zeit zu Zeit anderen Abteilungen einen Besuch abstattete, sich deren Abläufe und Ablaufdokumentationen zeigen liess, diese überprüfte und für regulierungskonform oder nicht regulierungskonform erklärte. Wenn das zweite der Fall war, mussten diese angepasst werden, danach wurden sie nochmals überprüft.

Bewusst oder unbewusst hatte sich in dieser Firma mit der Zeit ein eher dysfunktionaler Umgang mit der Revision etabliert: im Vorfeld wurde die Herausgabe von Informationen möglichst stark verzögert, während der eigentlichen Prüfung wurde die Revision dann dafür mit möglichst viel Material überflutet. In dem waren einige offensichtliche aber sehr geringfügige Fehler prominent plaziert, um schnell gefunden zu werden und die Revisoren von einer genaueren Überprüfung der anderen Bereiche abzulenken.

Als externem Berater/Agile Coach war ich in diese Feinheiten nicht eingeweiht worden, weshalb ich mir keine grossen Gedanken machte, als ich kontaktiert und nach einer Prozessdokumentation der agilen Software-Entwicklung gefragt wurde. Bereitwillig verwies ich auf den Scrum Guide und einige Intranet-Seiten, auf denen erklärt wurde, wie Scrum in der Entwicklungsabteilung umgesetzt wurde, die ich zu dieser Zeit begleitete. Noch am selben Tag brach dort Unruhe aus.

Schlafende Hunde hätte ich geweckt und die Revisoren "angefüttert", hiess es, jetzt hätten die mehr Zeit als sonst um sich zu informieren, sich vorzubereiten und noch genauer als sonst zu prüfen, und dadurch würden sie auch mehr finden können und für alle mehr Arbeit verursachen. Ein grosses Drama. Um alle zu beruhigen bot ich schliesslich an, die Vorbereitungs-Arbeiten der Revisions-Prüfung selbst zu übernehmen. Es waren noch etwa fünf Wochen bis zum Revisionstermin.

Eine wirkliche Idee was ich alles abzuliefern hätte hatte ich am Anfang noch nicht, dafür aber eine Idee wen ich fragen könnte - den Revisor, der mich nach Prozessdokumentation gefragt hatte. Und tatsächlich, von ihm bekam ich die "Richtlinien zur Inbetriebnahme, Modifizierung und Ausserbetriebnahme von Netzwerk- und Informationssystemen". Ein riesiges, unübersichtliches Dokument, voller Fachbegriffe und juristischer Formulierungen. Ich verstand bestenfalls die Hälfte.

Immerhin, er war bereit, es mir zu erklären, also stellte ich einen längeren Termin mit ihm ein, der erstaunlich konstruktiv und produktiv war. Hinter den meisten Formulierungen verbargen sich sehr einfache und nachvollziehbare Vorgaben, z.B. dass es ein Vorgehen zur Priorisierung von Anforderungen geben müsste, dass ein Vier-Augen-Prinzip gewährleistet sein müsste und dass neu entwickelte Funktionen eine Qualitätssicherung dürchlaufen müssten.

Umgekehrt konnte ich erklären, was es mit den verschiedenen Fachbegriffen aus Scrum auf sich hatte. Welche Meetings es gab, wer an ihnen teilnahm und dort welchen Beitrag leistete und welche zusätzlichen Praktiken in den Teams verwendet wurden, z.B. User Stories, Pair Programming und Code Reviews. Wir gingen auseinender mit einer Idee: bis zur nächsten Woche sollte ich eine Übersicht erstellen, welche Richtlinien durch welche Scrum-Regeln und Praktiken abgedeckt wurden.

Im nächsten Termin konnte ich bereits für die meisten Richtlinien etwas vorweisen: das Refinement für die Anforderungs-Priorisierungen, die Code Reviews für das Vier-Augen-Prinzip, die Akzeptanz- und Regressionstests für die Qualitätssicherung, etc. Natürlich war noch nicht alles abgedeckt, aber wir konnten jetzt sortieren - Themen bei denen es nichts mehr zu tun gab, Themen bei denen nur noch die Dokumentation genauer werden musste und offene Themen.

In den verbleibenden drei Wochen arbeiteten wir diese Liste durch: zwischen den jeweils wöchentlichen Terminen konnte ich die Prozessdokumentation vervollständigen und Vorschläge erarbeiten, welche noch offenen Richtlinien wie in Scrum umgesetzt werden könnten (z.B. wurden Security-Vorgaben in die Definition of Done aufgenommen), umgekehrt konnte der Revisor sich mit seinen Kollegen abstimmen, ob das auch nach deren Meinung ausreichend war.

Letzteres führte dann auch zu einem unerwarteten Effekt: einige der anderen Revisoren hatten vorher in anderen Firmen bereits agile Prozesse überprüft, und konnten berichten, wie Regularien dort erfüllt worden waren. Sobald uns das bewusst war, fragten wir auch  bei weiteren noch unklaren Fällen nach Erfahrungswerten, und bekamen auch einige (z.B. dass die Nennung einer einzuhaltenden Richtlinie in den Akzeptanzkriterien einer User Story eine ausreichende Dokumentation war).

Der Revisionstermin war dann trotz allem lang und umständlich, schliesslich war es vorgegeben, dass mehrere Revisoren zusammen mit mehreren Mitgliedern der Entwicklungsabteilung den gesamten Prozess und seine Dokumentation im Detail durchgehen mussten. Anders als bei den letzten Terminen war das Meiste den Revisoren aber bereits bekannt - und als ein weiteres Ergebnis der Vorbereitung war die zu sichtende Dokumentation auf das Wesentliche reduziert, hatte also deutlich weniger Umfang.

Am Ende stand die geringste Menge an notwendigen Nacharbeiten, an die sich alle Beteiligten erinnern konnten, und gleichzeitig waren die Vertreter der Revisionsabteilung der Meinung, dass sie noch nie die Prozesse einer geprüften Abteilung so gut verstanden hätten. Auch in der Entwicklungsabteilung wurde anerkannt, dass die frühe und transparente Zusammenarbeit mit den Revisoren nicht die befürchteten negativen Folgen gehabt hatte, sondern sinnvoll gewesen war.

Ein kleines Highlicht fand ganz zum Schluss statt: ein zufällig anwesender Manager hatte von den wöchentlichen Vorbereitungsterminen erfahren und glaubte daraus ableiten zu können, dass jetzt auch die Revisionsabteilung jetzt nach Scrum arbeiten würde. Die Revisoren korrigierten ihn höflich - agil wäre das Vorgehen durchaus gewesen und incrementell-iterativ auch, aber kein Scrum, da das aus bestimmen Gründen hier nicht sinnvoll anwendbar wäre. Sie hatten es tatsächlich verstanden.

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.

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.

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:

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.¹ 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.² 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.³ 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.⁴

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.

¹De jure fand die Gründung erst etwas später statt, durch die entsprechenden Anmeldungs- und Registrierungsvorgänge
²solche Zertifizierungen haben sich im agilen Bereich nie etabliert und wären vermutlich auch nie ein Business Case geworden
³Anscheinend hat die Agile Alliance für ihre Konferenz auch langfristige Verträge abgeschlossen, aus denen sie nicht herauskommt
⁴Auf Linkedin waren nach der Bekanntgabe des Zusammengehens viele Beiträge mit diesem Tenor zu lesen