On Lean and Agility

Bild: CCNull / Marco Verch - CC BY 2.0

Es dürfte nur wenige Personen geben, deren Image sich in wenigen Jahren so stark gewandelt hat wie das von Elon Musk - vom ökologisch-liberalen Hoffnungsträger zum techno-faschischen Oligarchen. Was dabei in Vergessenheit zu geraten droht ist, dass Musk in seinen Unternehmen vieles umgesetzt hat, was aus "agiler Perspektive" als vorbildhaft gilt.Dazu gehört unter anderem auch das fünfstufige Effektivitäts-Framework von Tesla und SpaceX, der u.a. in seiner autorisierten eponymen Biografie beschrieben ist.

pic.twitter.com/EbATALczdf

— Startup Archive (@StartupArchive_) July 20, 2025

1. Question every requirement (make them less dumb)

Die konsequente Umsetzung dessen, was auch als maximizing the amount of work not done bekannt ist. Wichtig dabei ist als Voraussetzung, dass Anforderungen immer einer Person zuzuordnen sein müssen, bei der man sie hinterfragen kann. Und ebenfalls, dass dieses Hinterfragen nicht nur als Legitim sondern als sinnvoll und gewünscht wahrgenommen wird, da jedem bewusst ist, dass niemand (egal wer er ist) davor gefeit ist, Fehler zu begehen - und zwar auch dumme Fehler.

2. Delete as much process as possible - even if it is too much

Ein Grundsatz, der seit Musks Kettensägen-Bürokratieabbau sicher kritischer gesehen werden muss, der aber einen rationalen Kern hat: von vielen (Umsetzungs-)Prozessen weiss man erst ob sie verzichtbar sind, wenn man durch ihre vollzogene Abschaffung getestet hat ob sie fehlen würden - andernfalls wird sich immer jemand finden, der sie verteidigt (im Zweifel der, dessen Job die Prozess-Aufrechterhaltung ist). Und wenn sie wirklich fehlen, kann man sie ja erneut einführen.

3. Simplify and optimize

Ab hier wird das Vorgehen dem ähnlicher, das aus Scrum, Kanban & Co bekannt ist. Wichtig ist dabei aber, dass zuerst die beiden ersten Schritte durchgeführt worden sind, um zu verhindern, dass unsinnige Anforderungen umgesetzt oder sinnlose Prozesse optimiert werden. Ein bekanntes Beispiel für die danach folgende Vereinfachung und Optimierung sind die Fertigungsstrassen der neuen Tesla-Fabriken, die erst in Zelten gebaut und optimiert werden, bevor die (teure) Fabrik um sie herum gebaut wird.

4. Accelerate cycle time

Sobald ein Fertigungs- oder sonstiger Arbeitsprozess grundlegend eingerichtet ist kann er in seinem Ablauf beschleunigt werden, z.B. indem Arbeitspakete kleiner geschnitten werden, Kopfmonopole aufgelöst werden oder Routinen entwickelt werden. Das Ganze idealerweise auf Basis von Daten wie Durchlaufzeiten, Qualitätsschwankungen oder Abnutzungsraten. Und auch hier gilt: die vorherigen Schritte müssen vorher stattgefunden haben, sonst riskiert man, etwas Falsches zu beschleunigen.

5. Automate

Dass die Automatisierung von Prozessschritten erst ganz am Ende erfolgt, hat einfache Gründe: sie ist kostspielig, und sollte daher erst stattfinden, wenn möglichst klar ist, dass das was automatisiert wird wirklich sinnvoll und effektiv gestaltet ist. Und sobald die Automatisierung stattgefunden hat, sind die Anforderungen und Abläufe der Sichtbarkeit der Menschen entzogen, und damit auch dem kritischen Hinterfragen. Frei nach Thorsten Dirks: automatisierte Scheissprozesse sind zu vermeiden.

Wie oben gesagt, spätestens Elon Musks Tätigkeit für die US-Regierung, in der sich sein Effektivitäts-Framework wiedererkennen lässt, hat aufgezeigt, dass es nicht in jeden Kontext übertragen werden kann oder übertragen werden sollte. Gleichzeitig hat es seine Unternehmen aber unbestreitbar erfolgreich gemacht, bis hin zu zeitweisen Quasi-Monopolen auf ihren Märkten. Wie so oft gilt daher auch hier: bitte nicht unhinterfragt kopieren, sondern zuerst kritisch bewerten. Z.B. mit den eigenen Schritten 1 bis 3.

Eine Gemeinsamkeit praktisch aller bekannten agilen Vorgehensmodelle ist, dass sie aus Amerika kommen und auch von dort angesiedelten Zertifizierungs- und Standardisierungs-Organisationen verantwortet und weitwerentwickelt werden. Es gibt aber Ausnahmen von dieser Regel, und eine davon kommt sogar ursprünglich aus dem deutschsprachigen Raum: die Flight Levels, entwickelt von Klaus Leopold aus der österreichischen Hauptstadt Wien.

Die zugrundeliegende Idee ist zunächst einfach: es wird davon ausgegangen, dass sich alle Arten von Arbeit, die in grossen Organisatinen durchgeführt werden, einem von drei Flight Levels (Flug-Höhen) zuordnen lassen. Operative Arbeit bildet das unterste Flight Level 1, teamübergreifende Koordination (möglichst End to End) das mittlere Flight Level 2, Strategie-Entwicklung und organisationsweite Zielsetzungen finden auf dem oberen Flight Level 3 statt.

Wichtig dabei ist, dass diese drei Flughöhen nicht (!) mit Hierarchieebenen verknüpft, bestimmten Organisationseinheiten zugeordnet oder auf eine andere Art und Weise geschützt oder exklusiv gehalten sind. Stattdessen kann und soll hierarchie- und einheitsübergreifend jeder eingebunden werden können, der zu einem Thema etwas beitragen kann, unabhängig davon wo in der Organisation er fachlich oder disziplinarisch verortet ist. 

Wie Vieles andere, das in der agilen Bewegung entstanden ist, ist diese Idee keine komplette Neuentwicklung, sondern findet sich in ähnlicher Form bereits an anderen Stellen, z.B. im St. Gallener Management-Modell. In der agilen Methodenwelt haben die Flight Levels aber eine spezielle Lücke finden und schliessen können: die der fehlenden Kanban-Skalierungsframeworks. Ursprünglich sind sie auch als Ergänzung des "Lehrstoffs" der Kanban University entstanden und wurden erst später eigenständig.¹

Dieser initiale Kanban University-Hintergrund ist auch die Erklärung dafür, dass die mit den Flight Levels verbundenen fünf Praktiken jedem Anwender von Wissensarbeits-Kanban bekannt vorkommen dürften. Es handelt sich um:

- Die Situation visualisieren
- Fokus setzen
- Agile Interaktionen durchführen
- Veränderungen messen
- Die Strukturen und Abläufe verbessern

Alles in allem also um einen kontinuierlichen Visualisierungs- und Verbesserungsprozess der Wertschöpfung, wie er für Kanban typisch ist.

Ebenfalls erkennbar aus Kanban übernommen ist der bewusste Verzicht auf einen formellen Rahmen aus vorgegebenen Rollen, Meetings und Vorschriften, an dessen Stelle der bewusste Start mit dem bestehenden Ist-Zustand tritt, der dann nach und nach optimiert werden kann. Daraus erklärt sich dann auch die Selbstbeschreibung als blosser "Denkansatz", der in bewusstem Kontrast zu den im Vergleich formalisierteren Ansätzen wie SAFe oder Scrum steht.

Interessant ist dabei, dass es ab der Trennung von der Kanban University (ca 2020) doch zu einer stärkeren Ausdifferenzierung und Vergrösserung der Flight Levels-Idee gekommen ist. Zwar nicht durch Meetings und Rollen, aber durch Erweiterungen wie die "Flight Items" genannten Arbeitspakete, die auf "Flight Routes" durch die Flight Level systeme fliegen, deren Analyse und Design zum Gegenstand von Werkzeugen und Praktiken wie z.B. der "Work Systems Topology" wird.

Im Zusammenhang damit sind schliesslich auch für die Flight Levels die für die agilen Frameworks typischen mehrtägigen Workshops entstanden, an deren Ende man sich einen farbigen Badge in den Lebenslauf einfügen kann, etwa "Flight Levels Professional" oder "Flight Levels System Architecture". Auf den Begriff der Zertifizierung wird dabei zwar bewusst verzichtet, die Art der Nutzung in Lebensläufen und Ausschreibungen ist aber sehr vergleichbar.

Trotz dieser offensichtlichen Gewinnerzielungsabsicht (die für sich genommen auch nicht verwerflich ist) hat sich Flight Levels in weiten Teilen der agilen Community bisher den Ruf eines irgendwie anderen, noch nicht komplett kommerzialisierten Vorgehensmodells erworben, nicht zuletzt wegen seines charismatischen Gründers Klaus Leopold, der es geschafft hat sich als einer der wenigen deutschsprachigen "agilen Thought Leader" zu etablieren.

Ob man damit tatsächlich etwas anfangen kann, liegt am Ende bei den eigenen Präferenzen. Wer offene Ansätze wie Kanban mag wird auch Flight Levels mögen, wer Wert auf stützende Rahmenbedingungen legt, wird eher mit den stärker aufformulierten Frameworks glücklich werden. Und wer aus der technischen Dimension der Agilität kommt wird den Ansatz mit freundlichen Interesse betrachten, ihn aber vor allem wegen seines Prozess-Minimalismus mögen. Jeder wie er mag.

Wer sich inspirieren lassen will, wie ein über Scrum und SAFe hinausgehendes individuelles agiles Framework aussehen könnte, der findet bei erfolgreichen Tech-Unternehmen eine Vielzahl von Beispielen, von Youtube über Amazon und Spotify bis hin zu Netflix und X/Twitter. Ohne nachzudenken kopieren sollte man nichts davon, aber Ideen zum Ausprobieren sind immer wieder dabei. Hier ist eine weitere: die forward-deployed Engineers (FDEs) der Firma Palantir.

Die an verschiedenen Stellen (z.B. hier, hier und hier) erklärte Idee ist einem Gründungsmythos zufolge nach dem Besuch in einem französischen Restaurant entstanden, in dem die Kellner viel Zeit mit den Gästen verbrachten, zusammen mit ihnen von der Karte abweichende Menüs erstellten und diese dann in Teilen selbst mit zubereiteten. In ähnlicher Form sollen zum Kunden entsandte (forward deployed) Teams von Palantir direkt mit den Anwendern Software-Features entwerfen und für sie erstellen.

Bewusst oder unbewusst scheint dieses Vorgehen eine (je nach Sichtweise) Weiterentwicklung oder Umdrehung der Rolle des Onsite Customers aus dem Extreme Programming zu sein. In beiden Fällen ist es das Ziel, Entwickler und Anwender möglichst nah zusammenzubringen. Während das im Extreme Programming aber dadurch stattfand, dass Kundenvertreter in die Entwicklungsteams integriert wurden, ist es bei den forward-deployed Engineers umgekehrt.

Die sich daraus ergebenden Vorteile (enger Zielgruppenkontakt, sofortige Erprobung neuer Ideen, unmittelbares Feedback) sind offensichtlich, allerdings sollte sich jeder bewusst sein, dass diese mit einem Preis kommen, und das ist in diesem Fall wörtlich zu nehmen. Bei Kunden eingesetzte FDEs werden dort lokale Lösungen entwickeln, die ggf. mit anderen lokalen Lösungen redundant oder inkompatibel sind, ihre Integration oder ihr parallel-Betrieb sind aufwändig, die Synergie-Effekte gering.

Dass dieser Weg für Palantir trotzdem der richtige ist, hat mit der Kundenstruktur dieser Firma zu tun. Sie ist im Rüstungssektor tätig und hat darum wenige, dafür aber potentiell riesige Kunden (v.a. die Armeen verschiedener Länder und grosse Rüstungskonzerne, wie z.B. Airbus). Diese Grosskunden sind problemlos in der Lage, die mit diesem Vorgehen verbundenen Kosten zu stemmen, gleichzeitig ist ihre Anzahl so überschaubar, dass die Varianz der entstehenden Lösungen handhabbar bleibt.

Von Bedeutung ist ausserdem, dass es sich bei den in diesem Kundensegment erstellten Palantir-Produkten um Individualsoftware handelt, die zum Grossteil bewusst nicht an andere Kunden verkauft werden soll (und zum Teil aufgrund von Geheimhaltungs- und Exklusivitätsvereinbarungen auch gar nicht verkauft werden darf). Die bei der Erstellung von Standardsoftware normalen und sinnvollen Vereinheitlichungs- und Effizienz-Bestebungen spielen daher hier keine Rolle.

Die forward-deployed Engineers sind daher in gleich doppelter Hinsicht ein interessanter Anschauungsfall. Zum einen weil sie einen Weg zu extrem effektiver und intensiver Kunden- und Nutzer-Interaktion darstellen, zum anderen weil es bei ihnen sehr deutlich erkennbar ist, wie kontextspezifisch ihr Einsatz ist und wie wenig übertragbar er auf die meisten anderen Unternehmen wäre. Daher, wie oben gesagt - eine Inspiration können sie sein, einfach kopieren sollte man sie aber nicht.

Bild: Pixabay / Ferafba - Lizenz

Fast immer wenn in grossen Organisationen der Handlungsdruck gross ist, Termine stark in Gefahr geraten oder irgendwie Nichts weitergeht, werden Task Forces gegründet - kleine, crossfunktionale und auf eine einzige Aufgabe focussierte Einheiten, die die anstehenden Aufgaben schnell erledigen können. Eine Frage die in solchen Situationen häufig gestellt wird ist die, ob sich dieser Arbeitsmodus nicht formalisieren lässt, um in Zukunft von Anfang an derartig lieferfähig sein zu können.

Die Antwort: natürlich geht das, und in verschiedenen Unternehmen gibt es auch Beispiele dafür. Ein prominentes sind die Thermal Teams oder Thermal Projects bei Twitter, bzw. X, deren Funktionsweise die beiden Manager Keith Coleman (VP of Product) und Jay Baxter (ML Lead) in Lenny's Podcast erklärt haben. In Anlehneng an die thermischen Aufwinde, die Vögeln das Fliegen erleichtern, handelt es sich bei ihnen um vom Top-Management geförderte Vorhaben mit besonders guten Rahmenbedingungen.¹

Wie immer in solchen Fällen gilt natürlich auch in diesem hier, dass es sich um eine Fallstudie aus einem sehr spezifischen, nicht in allen Asspekten nachvollziehbaren Kontext handelt, die darum nicht mit Copy & Paste in andere Unternehmen übertragbar ist. Allerdings handelt es sich auch um eine der bekanntesten und erfolgreichsten IT-Firmen der Welt, so dass es durchaus interessant und inspirierend sein kann, sich deren Vorgehensmodell anzuschauen.²

Die erste der oben genannten fördernden Rahmenbedingungen ist bei Twitter/X das Vorhandensein eines möglichst hochrangigen Sponsors (idealerweise in Person von Elon Musk selbst), der auch als Eskalations-Instanz dient, wenn es mit anderen Team zu Konflikten über Architektur, Ressourcen oder Sonstiges kommt. Das sorgt nicht nur für ein schnelles Lösen von Blockaden, es limitiert indirekt auch die Zahl der Thermal Teams, da die Anzahl möglicher Sponsoren nur klein ist.

Bei der nächsten fördernden Rahmenbedingung handelt es sich um die Selbst-Auswahl der Teammitglieder. Wenn der Start eines neuen derartigen Teams verkündet wird, sucht nicht das Management die aus seiner sicht passenden Entwickler aus, sondern diejenigen die Interesse haben melden sich selbst.³ Dadurch ist sichergestellt, dass alle Beteiligten intrinsisch motiviert sind und bereit sind, ihr gesamtes Leistungsvermögen einzubringen.

Als nächste Besonderheit sind die so entstehenden Einheiten möglichst klein, mit im besten Fall deutlich weniger als zehn Teammitgliedern, wodurch die interne Kommunikation einfacher und schneller wird. Ein begrenzender Faktor ist dabei, dass möglichst crossfunktionale Einheiten angestrebt werden, die alle in Frage kommenden Arbeiten selbst ausführen können. Dort wo hohe Spezialisierung nötig ist, führt das ggf. zu grösseren Gruppen.

Wichtig ist ausserdem, dass Thermal Teams soweit wie möglich von allen anderen Verpflichtungen und Vorschriften befreit sind. Das bedeutet vor allem, dass sie nicht parallel in anderen Projekten mitarbeiten dürfen und sich nicht mehr an anderen Meetings und Reportings beteiligen müssen, es bedeutet aber auch, dass sonst vorgehebene Tools und Standards nicht mehr benutzt werden müssen. Coleman und Baxter nennen als Beispiel Jira, von dessen Nutzung Thermal Teams befreit sind.

Als letztes ist von Bedeutung, dass diese Art von Teams bei Twitter/X nur jeweils für eine begrenzte Zeit bestehen sollen (daher auch die alternative Benennung Thermal Projects). Die Grümde dafür dürften offensichtlich sein: zum einen wird so ein Abrutschen in Routinen und ein Zurückgehen der besonderen Motivation verhindert, zum anderen können die Teammitglieder in ihre ursprünglichen Einheiten zurückkehren, in denen ihre Beteiligung schliesslich auch benötigt wird.

Wie oben gesagt, die Idee der Thermal Teams ist nichts was andere Unternehmen einfach kopieren sollten, dafür ist der Kontext in dem sie funktionieren zu spezifisch. Es kann aber eine gute Idee sein, einzelne Elemente davon zu übernehmen, bei sich zu testen, ggf. anzupassen und so sein eigenes Vorgehensmodell zu entwickeln, mit dem sich der eher unstrukturierte Taskforce-Modus ablösen lässt.

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

2. Schritt: Ergebnisse

3. Schritt: Evolution

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:

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.

Eine der Besonderheiten der agilen Community sind die "Insider-Hypes", die von Zeit zu Zeit aufkommen. Es handelt sich dabei um in der breiten Öffentlichkeit eher unbekannte Frameworks, Praktiken und Methoden, die unter Agile Coaches und Scrum Mastern aber eine Zeit lang als "heisser Geheimtip" gelten, bevor sie irgendwann wieder in der Versenkung verschwinden. Einer dieser Insider-Hypes der letzten Jahre ist ein Management-Framework namens Tight Loose Tight.

Für einen Hype ist Tight Loose Tight dabei relativ alt, es wurde bereits um das Jahr 2000 herum von der amerikanischen Unternehmensberatung Mercer Delta erfunden (siehe hier). Formalisiert und popularisiert wurde es dann ab ca 2010 von dem Norweger Rune Ulvnes, was mittlerweile zu dem verbreiteten Missverständnis geführt hat, es handele sich um eine "Führungsmethode aus Norwegen". Aber unabhängig von ihrem Ursprung - was ist das eigentlich?

Liz Guthridge, eine Unternehmensberaterin, die den Ansatz schon vor über 20 Jahren bei Mercer Delta kennengelernt hat, beschreibt seine drei Bestandteile so:

• Tight for purpose and goals: The organization’s executive team set the purpose and goals and tightly controlled them.
• Loose for execution: The business units and functions had autonomy in how they implemented and delivered on the goals, often under resource constraints from the executive team.
• Tight for results: The executive team also defined and measured the results they expected.

Oder mit anderen Worten: einer klaren Zielsetzung folgt eine möglichst grosse Freiheit bei der Umsetzung, gefolgt von einer genauen (und möglichst empirischen) Überprüfung, ob das Ergebnis tatsächlich erreicht wurde. Tight steht dabei für enge Führung, Loose für Delegation und Autonomie.

Rune Ulvnes hat diese Grundstruktur weitgehend übernommen, ihr aber zusätzliche Elemente hinzugefügt. Die Execution-Phase ist bei ihm nochmal unterteilt in Sprints von ein bis vier Wochen, und nach ihnen erfolgt jeweils Feedback zu Umsetzbarkeit, Zielgruppenakzeptanz und anderen Aspekten an das Management, das basierend darauf seine Zielsetzungen anpassen kann. Die Anlehnung an Scrum mit seinen Sprints, Sprint Reviews und Retrospektiven ist hier sehr offensichtlich.

Was ausserdem zur "norwegischen Variante" gehört ist eine Einordnung in ein Raster, in dem anhand der beiden Variablen der Verantwortungs-Delegation und der Arbeitsteiligkeit vier Extremtypen identifizierbar sind: das Steve Jobs-artige Genie mit dem Führungsstil tight tight tight, die nur auf Ressorcen-Optimierung konditionierte Führung mit dem Stil loose tight loose, die Feature Factory mit dem Führungsstil loose loose loose und ein agiles Vorgehen mit dem Führungsstil tight loose tight.

Jede dieser Zuordnungen kann zwar für sich genommen kritisch hinterfragt werden, löst man sich aber von den (in diesem Zusammenhang z.T. nicht unproblematischen) Begrifflichkeiten, kann das Raster ein durchaus sinnvolles Werkzeug sein, anhand dessen man sowohl eine Analyse des Ist-Zustandes als auch eine kontinuierliche Überprüfung der Bewegung zum angestrebten Zielzustand (in diesem Fall in der rechten oberen Ecke) durchführen kann.

Wie so oft bei derartigen Denkmodellen kann die Bewertung weit auseinandergehen, von "ein Augenöffner" bis hin zu "ist doch total banal" habe ich über Tight Loose Tight schon alles Mögliche gehört. Ich würde es aber so sehen: wem das Ganze nichts bringt, der kann es ignorieren, wem es hilft, der kann es benutzen. Und wer in der agilen Community an seinem Status als Thought Leader arbeiten will, der kann auf diesen Insider-Hype aufspringen, und damit sogar Anderen etwas Gutes tun. Also nur zu.

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.

Bild: Pixabay / GlauchauCity - Lizenz

Dem regelmässigen Leser dieser Seite dürfte es aufgefallen sein, dass ich ein Fan von Chaos Engineering bin. Als technische Praktik kann es entscheidend dafür sorgen, dass die in den methodischen Frameworks vorgesehehene kontinuierliche Liefer- und Reaktionsfähigkeit tatsächlich auch stattfinden kann. Darüber hinaus lässt sich Chaos Engineering aber auch von der Technik lösen und selbst als methodischer Ansatz einsetzen.

Noch einmal kurz zur Erinnerung: Chaos Engineering stellt die Resilienz (und damit auch die Liefer- und Reaktionsfähigkeit) eines Systems sicher indem auf Produktion nach Zufallsprinzip wichtige Ressourcen temporär abgeschaltet werden (Server, Übertragungskapazitäten, etc.). Übersteht das System diesen Stresstest ist alles gut, übersteht es ihn nicht, wird klar, an welcher Stelle an Kompensations-Automatismen gearbeitet werden muss.

Auf dieser Abstraktionsebene beschrieben lässt sich die Idee problemlos auf soziele Systeme übertragen, also auf Teams, Abteilungen oder Projekte. Auch hier lassen sich einzelne Ressourcen (→ Personen) temporär aus den Arbeitsabläufen herausnehmen, um festzustellen ob die anderen diesen Ausfall kompensieren können. Ist das nicht der Fall, ist ein Problem identifiziert, das beim nächsten Urlaub oder Krankheitsfall für Störungen oder Stillstand sorgen würde.

Die Problembehebung ist dann relativ einfach, denn in fast allen Fällen liegt einer von zwei Root Causes vor: entweder fehlen den anderen Mitarbeitern die Kenntnisse, um die Tätigkeiten des ausfallenden Kollegen zu übernehmen. Das kann kompensiert werden, indem sie sich in Richtung T-Shape oder Full Stack entwickeln. Oder ihnen fehlen Zugriffsberechtigungen auf die vom ausfallenden Kollegen verantworteten Systeme, was sich lösen lässt, in dem diese erteilt werden.

Ein zum Glück seltener werdender dritter Root Cause liegt vor, wenn der ausfallende Kollege Code Ownership in Teilen der Anwendung hat, also vereinbart wurde, dass er als Einziger dort Änderungen vornehmen darf. Eine andere Variante dieses Problems ist es, wenn nur eine Person für bestimmte Bereiche Pull Requests annehmen, also Änderungen genehmigen darf. Die Lösung ist in beiden Fällen einfach - man muss nur diese limitierenden Regeln abschaffen.

Die Ergebnisse von "sozialem Chaos Engineering" sind häufig überraschend, da Wissensmonopole, Berechtigungs-Engpässe und Code Ownership nicht immer explizit gemacht werden. Oft sind sie eher unbemerkt entstanden und werden selbst von den Beteiligten in ihrer Tragweite unterschätzt. Um so wichtiger ist es herauszufinden, ob sie vorliegen. Und einen netten Nebeneffekt gibt es auch noch: die temporär abwesenden Kollegen haben Zeit für Weiterbildung oder Überstunden-Abbau.

Grafik: Wikimedia Commons / Henrique José Teixeira Matos - CC BY-SA 3.0

Dass Chaos Engineering zu den eher unbekannten und unterschätzten agilen Frameworks gehört, dürfte auch daran liegen, dass nicht sofort ersichtlich ist, was es eigentlich mit Agilität zu tun hat. Sowohl von der formalen Perspektive (Prozesse, Rollen, Meetings, etc.) als auch von den Ergebnissen (Releases, Incremente, Features, o.Ä.) bietet es wenig von dem, was wir von SAFe, Scrum & Co kennen. Man muss es anders betrachten.

Der erste "agile Aspekt", über den ich bereits geschrieben habe, ist die Resilienz. Wenn wir Agilität als die Fähigkeit definieren, in kurzen Zyklen reaktions- und lieferfähig zu sein, dann muss man verhindern, dass Störungen und Ausfälle die eigenen Systeme für längere Zeiträume betriebsunfähig machen.¹ Der Weg den Chaos Engineering wählt um das zu verhindern sind permanente Stresstests, durch die Schwachstellen möglichst früh erkannt und behoben werden können.

Darüber hinaus ergibt sich aber noch ein zweiter "agiler Aspekt", denn es wird nicht versucht, diese System-Resilienz auf einmal, also in einen Big Bang herbeizuführen. Stattdessen soll sie nach und nach wachsen und ausgebaut werden, was ziemlich genau dem iterativ-incrementellen Ansatz praktisch aller agilen Frameworks entspricht. In gewisser Weise ist dabei die System-Resilienz selbst das Produkt, das basierend auf echten Anwendungserfahrungen ständig weiterentwickelt wird.

In der Umsetzung kann diese "incrementelle Resilienz" so aussehen, dass das System zuerst kleineren, noch beherrschbaren Störungen ausgesetzt wird. Sobald es für diese einen funktionierenden Kompensations-Mechanismus gibt können etwas grössere folgen, sobald auch diese kompensierbar sind nochmal grössere, etc., etc. Beispiele für solche kleineren Störungen wären zu Beginn noch moderate Nutzungs-Anstiege oder eine zunächst nur geringe Reduzierung des verfügbaren Speicherplatzes.

An diesen Beispielen lässt sich gut absehen wie die immer anspruchsvolleren Experimente (so nennt man in Chaos Engineering die Stresstests) aussehen könnten. Das Ausmass der Störfaktoren (in diesen Fällen steigende Nutzungs-Intensität und schrumpfender Speicherplatz) kann mit jedem Experiment hochgeschraubt werden, bis zu dem Punkt an dem selbst Grosstörungen wie der komplette Ausfall einer ganzen AWS-Region simuliert werden können.

Darüber hinaus ist es in späteren "Resilienz-Incrementen" auch sinnvoll verschiedene Experimente gleichzeitig auf dem selben System laufen zu lassen, um auch mögliche Interdependenzen erkennen zu können. Um bei den Beispielen zu bleiben: gleichzeitig steigende Nutzungs-Intensität und schrumpfender Speicherplatz, in einem nächsten Experiment dann zusätzlich dazu noch die Simulation von Übertragungs-Störungen oder ausfallender Leitungen.

Rein theoretisch liesse sich Chaos Engineering sogar nach Scrum umsetzen, mit jeweils einem Experiment als Sprintziel und den damit verbundenen Umsetzungs-, Monitoring- und Stabilisierungs-Massnahmen als Backlog-Items. Gegenstand der Sprint Reviews wären die erfolgreich verhinderten (oder doch stattgefundenen) Systemausfälle, die eingeladenen Stakeholder wären die Verantwortlichen der dort betriebenen Anwendungen, die dann sagen können wie viel mehr Ausfallsicherheit sie benötigen.

Dass es mehr agile Frameworks gibt als Scrum, SAFe und Kanban dürfte den meisten die sich mit diesem Thema beschäftigt haben klar sein, wie viele es sind ist aber doch immer wieder überraschend. Da es insgesamt zu viele sind um sie in einem einzigen Beitrag ausführlich zu behandeln wählt Craig Smith in diesem Vortrag das einzige passende Format: Stakkato. 40 Frameworks und Methoden in nur 40 Minuten.

Obwohl dieses Video nur sieben Jahre alt ist merkt man an ihm übrigens wie sehr sich die agile Methodenwelt in der jüngeren Vergangenheit geändert hat. SAFe ist nur eines unter vielen Skalierungsframeworks, Disciplined Agile ist noch eigenständig, Modern Agile und andere "neuere" Frameworks sind noch unbekannt (oder noch nicht erfunden). Dafür werden andere aufgeführt, die (zurecht?) völlig in Vergessenheit geraten sind, wie z.B. Nonban und ScrumPLOP oder Mikado. Times are a-changin'.

Bild: Pixabay / StevePB - Lizenz

Die agile Produktentwicklung hat Vieles nachhaltig verändert: den Umgang mit Abnehmern und Kunden, die Durchführung der Qualitätssicherung, die handwerklichen Praktiken der Softwareentwicklung und vieles mehr. Ein zentraler Bereich der Unternehmensführung ist allerdings eher unberührt geblieben - der Budgetierungsprozess. Glücklicherweise gibt es aber hier einen kompatiblen, zeitgleich entstandenen Ansatz, der diese Lücke füllen kann. Die Rede ist von Beyond Budgeting.

Ähnlich wieim Fall von #NoEstimates steht hinter Beyond Budgeting eine überzeugte (und in verschiedenen Firmen hoch erfolgreiche) Community, nach aussen sorgt die etwas unglückliche Namensgebung aber dafür, dass es oft gar nicht erst zu einer näheren Beschäftigung mit diesem Ansatz kommt. Dabei soll hier keineswegs der Budgetierungsprozess abgeschafft werden, er soll erhalten bleiben, nur eben deutlich verbessert.

Dieser Verbesserungsbedarf wird aus verschiedenen problematischen Aspekten der klassischen Budgetierung abgeleitet. Dazu gehört vor allem die Fixierung auf die Planung für jeweils das nächste Kalenderjahr, die am Anfang zu langfristig und am Ende zu kurzfristig ist, aber auch weitere übliche Praktiken, etwa die in dieser Jahresplanung oft enthaltene Vermischung von Prognosen und Zielen oder die Kopplung von Gehaltsbestandteilen an aus diesen Jahreszielen abgeleitete persönliche Ziele.

Über diese Budgetierungs-nahen Grundlagen hinaus sind nach und nach weitere Kritikpunkte an häufigen Elementen des traditionellen Budget-Managements in Beyond Budgeting aufgenommen worden, etwa an dem Nicht-Weitergeben von Informationen in die Belegschaft, an zu detaillierter Regulierung von Arbeitsprozessen, an zu bürokratischen Reporting-Strukturen und an der Optimierung auf interne Effizienz statt auf Nutzen für den Endkunden.

Bei der Antwort auf die Frage wie all das besser organisiert werden könnte bleibt Beyond Budgeting absichtlich unklar, da zu konkrete Empfehlungen in vielen Einzelfällen nicht passen würden, zumindest wurden als Richtlinie aber zwölf leitende Prinzipien verfasst:

1. Purpose
   Engage and inspire people around bold and noble causes; not around short-term financial targets
2. Values
   Govern through shared values and sound judgement; not through detailed rules and regulations
3. Transparency
   Make information open for self-regulation, innovation, learning and control; don’t restrict it
4. Organisation
   Cultivate a strong sense of belonging and organise around accountable teams; avoid hierarchical control and bureaucracy
5. Autonomy
   Trust people with freedom to act; don’t punish everyone if someone should abuse it
6. Customers
   Connect everyone’s work with customer needs; avoid conflicts of interest
7. Rhythm
   Organise management processes dynamically around business rhythms and events; not around the calendar year only
8. Targets
   Set directional, ambitious and relative goals; avoid fixed and cascaded targets
9. Plans and forecasts
   Make planning and forecasting lean and unbiased processes; not rigid and political exercises
10. Resource allocation
    Foster a cost conscious mind-set and make resources available as needed; not through detailed annual budget allocations
11. Performance evaluation
    Evaluate performance holistically and with peer feedback for learning and development; not based on measurement only and not for rewards only
12. Rewards
    Reward shared success against competition; not against fixed performance contracts

Um die Idee greifbarer zu machen gibt es mittlerweile neben diesen Leitlinien aber auch verschiedene Good Practices, die in verschiedenen Büchern zu diesem Thema nachzulesen sind.

Die naheliegende erste Praktik ist eine rollierende Planung anstelle einer Kalenderjahr-basierten. Das kann in der Realität so aussehen, dass zwar fünf Quartale im Voraus geplant wird, dass diese Planungen aber nach jedem Quartal überprüft und angepasst werden. Dadurch entfernt sich die Umsetzung nie länger als drei Monate von der Planung, gleichzeitig wird vermieden, dass der Planungsvorlauf zu Jahresende nur noch wenige Wochen beträgt.

Ebenfalls häufig ist die Entkoppelung von Prognose und Zielsetzung. In den Prognosen für den jeweiligen Planungszeitraum wird nur berücksichtigt was wahrscheinlich ist, das was wünschenswert ist (die Ziele) wird in einem zweiten, getrennten Dokument festgehalten. Das gilt auch dann (und sogar ganz besonders dann) wenn die wahrscheinlichen Zahlen unschön oder sogar bedrohlich sind. Sie zu verändern nur weil andere Zahlen schöner wären ändert schliesslich die Sachlage nicht.

Auch bei den Zielen (sowohl bei Geschäftszielen als auch bei Zielen von Personen oder Personen-Gruppen) ist eine kontinuierliche Setzung und Nachverfogung besser als eine Orientierung am Jahresrhythmus. Das bedeutet nicht zwingend, dass sie nur für kürzere Umsetzungszeiträume gesetzt werden, z.B. für Monate oder Quartale. Sie können auch für längere Zeiträume gesetzt werden, müssen dann aber in kurzen Zyklen immer wieder überprüft und an aktuelle Entwicklungen angepasst werden.

Auch bei der Art der Zielsetzung bevorzugt Beyond Budgeting eigene Wege. Statt zahlengebundener Ziele (z.B. Gewinn-Volumen oder Anzahl an Geschäftsabschlüssen) findet man eher relative Ziele, also solche, deren Zielsetzung es ist besser zu sein als eine Vergleichsgruppe. Das kann bedeuten, dass eine ganze Firma sich das Ziel setzt besser zu sein als der Marktdurchschnitt, es kann aber z.B. auch bedeuten, dass eines von 50 Vertriebsteams sich das Ziel setzt zu den besten 10 zu gehören.

Für jeden der in seiner Organisation die agile Transition ganzheitlich vorantreiben will ist Beyond Budgeting daher ein sehr zu empfehlender Ansatz. Und wenn die Namensgebung als zu kontrovers wahrgenommen werden sollte - man kann es auch agile Budgetierung nennen, wichtig ist, dass die dahinter stehenden Ideen umgesetzt werden, nicht der Name.

Bild: Pexels / Jep Gambardella - Lizenz

Wir müssen uns über DevOps unterhalten. Über jene Idee also, die seit einiger Zeit parallel, überlappend oder ergänzend zur Agilität auftritt und von dieser auch nicht klar zu trennen ist. Zum einen weil es sich um ein gutes und wichtiges Konzept handelt, das jeder der in der IT arbeitet kennen sollte, zum anderen aber auch weil es leider immer mehr verkompliziert und mystifiziert wird, bis zu dem Punkt an dem kaum noch klar ist was es sein soll. Dabei ist es eigentlich ganz einfach.

DevOps bedeutet, dass Entwicklung (Development) und Betrieb (Operations) einer Software nicht mehr von unterschiedlichen Einheiten verantwortet wird sondern von einer gemeinsamen. Das reduziert Übergaben und Wartezeiten und beschleunigt damit die Prozesse, es führt durch seinen Grundsatz "you build it, you run it" aber auch zu besserer Wartbarkeit, da kaum ein Entwickler übermässig komplex zu betreibende Software erstellen wird, wenn er weiss, dass er selbst darunter leiden würde.

Was dazukommt ist noch eine kleine aber feine Begriffs-Nuancierung. DevOps ist nicht etwa nur Dev und Ops, es bedeutet alles von Dev bis Ops. So arbeitende Teams müssen daher auch sämtliche Tätigkeiten durchführen können mit denen neu entwickelte Features in die Betriebsumgebungen kommen, also auch Integration, Test und Release sowie ggf. Rollbacks, Wiederherstellungen und Anwender-Support. Der Verantwortungsbereich wird dadurch nochmal grösser und vielfältiger.

Ein Grossteil der DevOps-Befürworter wird dieser Erklärung zwar zustimmen, gleichzeitig aber betonen, dass sie unvollständig ist. Je nach Person wird er ergänzen, dass ausserdem noch bestimmte Praktiken, Phasenmodelle,¹ Tools oder Mindsets dazugehören. Das ist zwar gut gemeint, trägt letztendlich aber nur zu der oben erwähnten Verkomplizierung und Mystifizierung bei, denn so hilfreich all das auch ist - es ist nur Mittel zum Zweck, und der Zweck bleibt das Zusammenführen von Dev, Ops und Zwischenschritten.

Werfen wir einen näheren Blick darauf. Ein DevOps-Team in dem nur die bisherigen Verantwortlichen für Entwicklung, Integration, Test, Release, Betrieb und Support zusammengefasst werden wird von Anfang an eine Unwucht haben, in der die Entwicklung neuer Funktionen nur der kleinere Teil der Aufgaben ist, die um die bestehenden Funktionen kreisenden Tätigkeiten dagegen den grösseren ausmachen. Es besteht das Risiko, dass immer mehr Kapazität dorthin verlagert wird. Aus DevOps wird nur noch Ops.

Um dem zu begegnen ist es nötig diesen grösseren Teil so zu organisieren, dass er nur einen möglichst kleinen Teil der Arbeitskapazität benötigt. Dieses Kunststück kann nur vollbracht werden indem möglichst viele Tätigkeiten aus diesem gösseren Bereich automatisiert werden und dann entweder ununterbrochen durchlaufen (z.B. Regressionstests und Monitoring) oder auf Knopfdruck durchgeführt werden können (z.B. Deployments und Rollbacks).

An dieser Stelle wird die Differenzierung offensichtlich - Praktiken, Phasenmodelle, Tools oder Mindsets können Teil von DevOps sein wenn sie dazu beitragen den Arbeitsaufwand von Nicht-Entwicklungs-Tätigkeiten zu begrenzen und zu reduzieren - was je nach Einzelfall sehr unterschiedlich aussehen kann. Dort wo sie aber zu einem grundsätzlich vorgegebenen Bestandteil erklärt werden bilden sie an vielen Stellen eine Lösung ohne Problem, die den Sinn des ganzen Ansatzes unklar werden lässt.

Das Fazit ist also: DevOps bedeutet die effektivitätssteigernde Zusammenfassung aller Tätigkeiten von Dev bis Ops, unter optionalem Einschluss weiterer Elemente, sofern die dafür sorgen, dass der Nichtentwicklungsteil so wenig aufwändig ist wie möglich. Eine schlichte Erklärung, unkompliziert, unmystisch und sofort nachvollziehbar.

Bild: Public Domain Pictures - CC0 1.0

Unter den verschiedenen agilen Frameworks gehört das Chaos Engineering zu den weniger bekannten, was vermutlich auch so bleiben dürfte. Es gibt keine bekannten Gründer-Figuren wie im Fall von Scrum, keine dahinterstehende kommerzielle Organisation wie im Fall von SAFe und (leider ein wesentlicher Punkt) keine Zertifikate, durch die der agil-industrielle Komplex zu seiner Verbreitung beitragen würde. Dafür hat Chaos Engineering etwas ganz Anderes: praktische Relevanz.

Entwickelt wurde der Ansatz ca. 2010 bei Netflix, dem amerikanischen Video-Streamingdienst. Den Entwicklern dort wurde über die Zeit schmerzhaft klar, dass sie auf ihren Test-Umgebungen weder das Systemverhalten noch das Anwenderverhalten genau so simulieren konnten wie es in der unberechenbaren Realität auftrat. Wiederholt kam es dort daher zu Fehlern. Ihre Lösung: die Verlagerung einer Grossteils der Qualitätssicherung in den Live-Betrieb.

Die dahinterstehende Logik: wenn Störungen der Live-Umgebungen schon nicht zu vermeiden sind, dann sollten sie zumindest schnell entdeckt werden können und sofort behebbar sein. Und wenn möglich sollten Fehler während der Arbeitszeit auftreten, wenn jemand da ist der sie schnell beheben kann und nicht irgendwann in der Nacht. Um das zu erreichen sollten die Systeme tagsüber ständigen Stresstests ausgesetzt werden, um diese Fehler so auslösen und beheben zu können.

Since we knew that server failures are guaranteed to happen, we wanted those failures to happen during business hours when we were on hand to fix any fallout. We knew that we could rely on engineers to build resilient solutions if we gave them the context to expect servers to fail. If we could align our engineers to build services that survive a server failure as a matter of course, then when it accidentally happened it wouldn’t be a big deal. In fact, our members wouldn’t even notice. This proved to be the case.

Netflix Tech Blog, 2015

Der technische Kern des Chaos Engineering ist die so genannte Affen-Armee, eine Gruppe von Programmen die diese Tests durchführen. Die bekanntesten unter ihnen sind der Chaos Monkey, der nach Zufallsprinzip Live-Server kurzzeitig abschaltet und der Chaos Gorilla, der das Gleiche mit ganzen Rechenzentren macht. Darüber hinaus existieren u.a. der Latency Monkey, der Conformity Monkey und der Security Monkey, die meisten von ihnen als Open Source veröffentlicht.

Den methodischen Rahmen um die Technik bilden die Principles of Chaos Engineering, die ein grober Leitfaden für die Anwendung des Frameworks sind. Im Kern stehen dabei die vier Grund-Prinzipien:

1. Start by defining ‘steady state’ as some measurable output of a system that indicates normal behavior.
2. Hypothesize that this steady state will continue in both the control group and the experimental group.
3. Introduce variables that reflect real world events like servers that crash, hard drives that malfunction, network connections that are severed, etc.
4. Try to disprove the hypothesis by looking for a difference in steady state between the control group and the experimental group.

Mit anderen Worten: definiere einen messbaren, stabilen Ausgangszustand, lass die Affen-Armee auf ihn los und wenn etwas kaputtgeht finde heraus warum. Wichtig ist an dieser Stelle, dass in diesen Prinzipien von dem bei Netflix im Mittelpunkt stehenden Testen auf der Live-Umgebung noch nicht die Rede ist. Dadurch wird Chaos Engineering auch für kritische Anwendungen nutzbar, etwa den Betrieb von Stromnetzen, die man nicht testweise abschalten sollte.

Für andere Anwendungen, bei denen eine Ausfallzeit von wenigen Sekunden oder Minuten unkritisch ist gibt es die "Advanced Principles", deren Umsetzung schwieriger ist, dafür aber auch einen deutlich  höheren Mehrwert bringt:

1. Build a Hypothesis around Steady State Behavior.
2. Vary Real-world Events.
3. Run Experiments in Production.
4. Automate Experiments to Run Continuously.
5. Minimize Blast Radius.

Auch das in vereinfachten Worten: definiere in der Live-Umgebung einen messbaren, stabilen Ausgangszustand, lass die Affen-Armee in immer neuen Variationen auf ihn los und arbeite daran, dass die Auswirkungen immer geringer werden. Der letzte Punkt ist dabei das grosse Ziel - durch immer bessere Ausweichmechanismen und immer grösser werdende Unabhängigkeit von Komponenten und Regionen wird die Auswirkung von Fehlern und Ausfällen immer kleiner (hier ein Beispiel).

Grafik: modernagile.org - CC BY-SA 4.0

Es soll ja Menschen geben denen sogar ein so minimalistisches Framework wie Scrum noch immer zu viele vorgegebene Regeln, Rollen und Meetings hat. Für diese Menschen (und erfunden von einigen von ihnen) gibt es einen der minimalistischsten agilen Ansätze: Modern Agile. Keine Rollen, keine Meetings, keine Sprints und keine Vorgaben. Nur vier Prinzipien und einige empfohlene Praktiken, die man befolgen kann aber nicht befolgen muss.

Die Prinzipien sind Make People Awesome, Make Safety a Prerequisite, Experiment & Learn Rapidly und Deliver Value Continuously. Es handelt sich bei ihnen nicht um konkrete Handlungsanweisungen sondern um grundlegende Maximen, an denen man jede seiner Handlungen messen kann. Jede Handlung die man im beruflichen Kontext vornimmt sollte auf mindestens eines der Prinzipien einzahlen, ist das nicht der Fall sollte man hinterfragen ob man sie wirklich braucht.

Hinter Make People Awesome (mache die Menschen grossartig) verbirgt sich sowohl eine Leitlinie für den Umgang mit den Käufern und Nutzern des eigenen Produkts als auch eine für den Umgang mit den eignenen Mitarbeitern. Die Idee dahinter ist, dass Produkte und Firmen kein Selbstzweck sind sondern nur Mittel um Nutzern und Mitarbeitern grösstmögliche Selbstentfaltung und Produktivität zu ermöglichen. Diese sollte daher im Mittelpunkt von Produkt- und Organisationsentwicklung stehen.

Make Safety a Prerequisite (mache Sicherheit zur Vorbedingung) umfasst in erster Linie die psychologische Sicherheit, also die Gewissheit im Arbeitskontext alle Meinungen zu äussern und Fragen stellen zu können ohne dafür angegriffen, gedemütigt oder von oben herab behandelt zu werden. In einer weiteren Deutung gehört dazu auch die Arbeitssicherheit, also das Vorhandensein von Techniken und Routinen zur Verhinderung und Begrenzung von Unfällen und Schäden.

Experiment & Learn Rapidly (experimentiere und lerne schnell) ist am deutlichsten als agiles Prinzip erkennbar. Über das klassische Inspect & Adapt geht es allerdings hinaus, da es nicht nur die regelmässige Überprüfung von Teilergebnissen beinhaltet sondern auch die Gewinnung von Wissen durch ergebnisoffene Experimente. Wichtig ist, dass das schnell geschehen soll, die Lern- und Experimentier-Zyklen also möglichst kurz sein sollen.

Deliver Value Continuously (liefere kontinuierlich Mehrwert) geht in eine ähnliche Richtung. In einer bewussten Abkehr von Jahres-, Quartals- und sogar Sprint-Releases soll die Auslieferung neuer Features und Services nicht nur in kurzen Abständen erfolgen sondern auch möglichst regelmässig, idealerweise täglich. Dabei soll nicht bloss ein einmal gefasster Plan abgearbeitet werden, sondern auch der soll sich als Ergebnis der Auslieferung ständig ändern.

Obwohl ursprünglich nicht vorgesehen haben die Erfinder von Moder Agile später ein Mapping ihrer vier Prinzipien auf das Manifest für agile Softwareentwicklung adaptiert:

Neben dem Prinzipien-Teil gibt noch die zu Beginn genannten empfohlenen Praktiken. Zu ihnen gehören unter anderem Charter-Veranstaltungen zu Projektbeginn, Elemente aus Lean Startup und Lean UX, Continuous Integration, Refactoring, Blameless Retrospectives, Radar Charts und Pair- bzw. Mob-Programming. Umgekehrt wird auch von einigen Elementen abgeraten, unter anderem von Sprints, Product Owner- und Scrum Master-Rollen und Story Points.

Bild: Unsplash / Marvin Meyer - Lizenz

Eigentlich könnte man denken, dass der Markt für agile Vorgehensmodelle gesättigt ist. Auf Teamebene hat sich Scrum durchgesetzt, vor Kanban und mit weitem Abstand dahinter Extreme Programming, auf Ebene der Skalierungsframeworks liegen SAFe und das so genannte Spotify Model vorne, dahinter ebenfalls mit grossem Abstand die Scrum-Skalierungen LeSS, Nexus und Scrum@Scale sowie Flight Level-Kanban und Disciplined Agile. Zum ersten mal seit langem gab es in letzter Zeit aber neue Ansätze, 2021 das Fast Framework und Anfang 2022 ein noch neueres: das Unfix Model (zu finden hier).

Hinter diesem neuen Namen steckt Jurgen Appelo, der breiteren Öffentlichkeit als Erfinder von Management 3.0 bekannt, das er auch als eine der Inspirationen für seine neueste Erfindung nennt. Die anderen sind das Spotify Model und die Bücher Dynamic Reteaming, Team Topologies und Turn the Ship around, aus denen er jeweils verschiedene Elemente übernommen hat. Erstmals vorgestellt wurde die Idee zu Unfix im Herbst 2021, der offizielle Start war im folgenden Januar. Wichtig für ihn: Unfix soll kein Framework mit festen Vorgaben sein, sondern eine "Pattern Library" aus optionalen Bausteinen.

Zum Inhalt: die Grund-Einheit in Unfix ist die so genannte Base, eine Gruppe von bis zu 150 Menschen, die an einem gemeinsamen Produkt arbeiten und einen oder mehrere Chiefs als Vorgesetzte haben (je nach Gesamtgrösse, bei kleineren reicht einer). Eine Base muss alle für das Produkt nötigen Arbeiten selbst ausführen können, d.h. dafür qualifizierte Mitglieder haben. Feste Untergruppen existieren nicht, bei sehr arbeitsintensiven Produkten können aber mehrere Bases für jeweils ein Teilprodukt verantwortlich sein und zusammen eine so genannte Super-Base bilden.¹

Innerhalb der Bases können bei Bedarf kleinere Untereinheiten von ca. fünf Personen temporär oder für längere Zeit gebildet werden, die so genannten Crews. Idealerweise sind es crossfunktionale und End to End-verantwortliche Value Stream Crews, ebenfalls möglich sind aber auch Facilitation Crews (aus Coaches und Trainern), Capability Crews (Komponenten-Teams), Governance Crews (aus mehreren Chiefs), Platform Crews (z.B. Infrastruktur), Experience Crews (Kunden- und Nutzerservice) und Acquisition Crews (Einkauf). Teilzeit-Mitgliedschaften in ihnen sind nicht wünschenswert aber möglich.

Für die Koordination zwischen den einzelnen Crews existieren Querschnittseinheiten, die Forum genannt werden. Welche das sind kann je nach Bedarf entschieden werden, von technischen Standards bis hin zu organisatorischen Themen lässt sich für alles Denkbare ein Forum einrichten. Foren werden von einem Chair moderiert, sind in der Form ihrer Zusammenarbeit selbstorganisiert, nicht aber in der Themenauswahl. Sie werden durch die Chiefs gegründet und erhalten Arbeitsaufträge von den Captains. Wenn zwei Bases eine Super-Base bilden können gleichartige Foren ein Super-Forum bilden.

It's time for an alternative.
The unFIX model (updated) #orgdesign #agile #scalinghttps://t.co/YleuSo8qnq pic.twitter.com/TziXSlXPgc

— Jurgen Appelo (@jurgenappelo) January 3, 2022

Das ist es, das Unfix Model. Wie Appelo selber schreibt ist eigentlich nichts davon neu, jedes Element findet sich unter irgendeinem Namen bereits in zahlreichen Unternehmen wieder. Sein Anspruch ist aber, alles zum ersten mal gebündelt und mit wiedererkennbaren Benennungen versehen zu haben. Und für alle die an einer Abgrenzung zu anderen Frameworks interessiert sind findet sich auf der Website ein Vergleich mit SAFe, LeSS und dem Spotify Model. Dem letzten dürfte Unfix auch am ähnlichsten sein, selbst wenn Appelo die bei ihm fehlende Matrix-Struktur als grundlegenden Unterschied sieht.²

Ob Unfix eine grössere Verbreitung finden wird bleibt abzuwarten, das Dynamic Reteaming in den Crews dürfte aber viele Unternehmen abschrecken. Andererseits hat es mit seinem Schöpfer ein international bekanntes und populäres Zugpferd, was zu einer schnellen Verbreitung beitragen könnte. Und was man nicht vergessen darf: am Anfang gab es auch grosse Skepsis gegenüber dem Spotify Model (zu alberne Namen) und gegenüber SAFe (viel zu kompliziert). Wir werden sehen wie es sich entwickelt.

Nachtrag 16.04.2022:

I've been busy this week creating new unFIX visuals and examples. I'm trying to nail the message that it's NOT a prescriptive one-size-fits-all framework. It's an all-sizes-fit-one pattern library. Join the community. There's a new meetup next Thursday. https://t.co/ykwAfS5r8o pic.twitter.com/lp8cYAgrv6

— Jurgen Appelo (@jurgenappelo) April 15, 2022

Bild: Wikimedia Commons / Lisamarie Babik - CC BY 2.0

Bei der heutigen "Monokultur" von Scrum, Kanban und SAFe mag man es kaum noch glauben, aber gab eine Zeit, zu der keines dieser drei das dominierende agile Framework war. Um das Jahr 2000, also zu der Zeit als das agile Manifest geschrieben wurde, war ein anderes das bekannteste: Extreme Programming (XP). Damals noch so bekannt, dass es in den Dilbert-Comics veralbert wurde, sank es später zu einem nur noch schwach erinnerten Mythos herab. Höchste Zeit ihn hervorzuholen und zu entstauben.

Ein Sprung zurück in der Zeit: 1996 befindet sich beim amerikanischen Chrysler-Konzern ein IT-Projekt der Lohnbuchhaltung in der Krise, drei Jahre nach Beginn der Software-Entwicklung konnte noch kein einziges Gehalt mit dem neuen System ausgezahlt werden. Die Probleme sind dieselben die sich bis heute in IT-Grossprojekten finden - die Integration von Entwicklungs-Branches führt zu schwerwiegenden Merge-Konflikten, Tests, Bugfixes und Releases erzeugen massive Aufwände, die Kommunikation zwischen Fachabteilungen und Entwicklern ist voller Missverständnisse und Konflikte.

Neu zum Projekt gestossene Projektmanager und Entwickler untersuchen die Ursachen und finden ein Muster - da alle der gerade genannten Tätigkeiten für die Beteiligten anstrengend und unerfreulich sind, werden sie so lange wie möglich aufgeschoben. Bedingt dadurch wachsen sie zu riesigen Arbeitspaketen heran, die zum Zeitpunkt ihrer Umsetzung zum Teil bereits veraltet sind und durch ihre Grösse, Unübersichtlichkeit und Vernetztheit selbst zu ernsthaften Fehlerquellen werden.

Die gemeinsam erarbeitete Lösung für dieses Problem ist das Durchführen dieser Tätigkeiten in immer kürzeren Abständen und immer kleineren Umfängen. Die Idee dahinter: kleine Arbeitspakete sind übersichtlicher, weniger in sich vernetzt und werden bei Fehlern tendenziell kleinere Bugs erzeugen, kurze Abstände sorgen für häufige Wiederholung und damit auch für mehr Übung, für engere Zusammenarbeit, intensivere Kommunikation und als Folge dessen für weniger Missverständnisse.

Wichtig für das Verständnis dieser Entstehungsgeschichte ist, dass in all dem wenig Neues steckte. Code Reviews, Merges, Tests, Releases und Kommunikation mit Kunden und Auftraggebern gibt es, seitdem Software entwickelt wird. Das Ungewöhnliche war die aus damaliger Sicht unglaubliche Beschleunigung. Aus einmal pro Quartal oder pro Jahr wurde mehrmals pro Woche oder sogar pro Tag. Diese extreme Häufigkeit gab dem Ganzen ihren Namen: Extreme Programming.

Die einzelnen Praktiken von XP sind vor diesem Hintergrund zu verstehen: Pair Progamming ist die extrem intensive Zusammenarbeit von zwei Entwicklern, Unit Tests sind extrem kleine Validierungen von Funktionalität. Iterationen (ein- bis dreiwöchige Zeiträume) sind extrem kurze Lieferzyklen, Refactorings sind extrem häufige Überarbeitungen der Codebasis, etc. Dass sie für XP nötig sind, ist offensichtlich, und dass sie so zentral sind macht es zu einem der IT-spezifischsten unter den agilen Frameworks.

Vermutlich ist dieser sehr starke IT-Bezug auch einer der Gründe dafür, dass Extreme Programming der ganz grosse Durchbruch verwehrt geblieben ist. Bereits die "sichtbaren Praktiken" wie Pairing und Reviewing sind in Berater- und Management-Präsentationen nur schwer zu vermitteln, auf "unsichtbare Praktiken" wie Test First und Refactoring trifft das um so mehr zu. Und selbst wenn sie verstanden werden, ist ihre Einführung ungleich schwerer als die neuer Rollen und Meetings.

Aus diesen Umständen ergibt sich auch ein fast schon tragisches Phänomen: das was von XP in andere Frameworks übernommen wurde, ist in der Regel nicht der IT-spezifische Kernbereich, sondern es sind die im Vergleich weniger wichtigen Prozess-Elemente. Das heisst nicht, dass diese (v.a. User Stories, Story Points, Planning Poker und Onsite Customer) nicht gut und richtig wären, aber dass vor allen sie in Scrum und SAFe integriert wurden, vermittelt ein schiefes Gesamtbild ihres Ursprungs.

Noch einmal anders gesehen kann man aber auch Positives daran finden, dass Extreme Programming aus dem Scheinwerferlicht verschwunden ist. Da aus Softwareentwicklungssicht kaum ein anderes Framework so passend zur IT ist, kann man seinen Bekanntheitsgrad als Indikator dafür benutzen, ob und wie vertieft sich ein Entwicklungsteam mit dem Thema Agilität auseinandergesetzt hat. Wenn XP dort ein Begriff (oder sogar in Anwendung) ist, kann man als Agile Coach direkt zu den fortgeschrittenen Themen springen und kann auf Grundlagenarbeit verzichten.

Quelle: Twitter