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.