On Lean and Agility

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.

Bild: Unsplash / Carine L. - Lizenz

Es ist eine der klassischen Fragen, mit denen sich jede grössere Organisation früher oder später beschäftigt - wie schaffen wir es, dafür zu sorgen, dass mehrere zusammenarbeitende Teams unbürokratisch die notwendigen Informationen untereinander austauschen können? Formate dafür gibt es viele, vom Scrum of Scrums über die Gilde und die Community of Practice bis zur Management- oder Spezialisten-Abstimmung. Eines ist aber erstaunlich unbekannt - das morphende Daily.

Die Grund-Idee, die dieses Format von fast allen anderen unterscheidet, ist, dass kein zusätzliches Meeting eingerichtet wird, in dem die einzelnen Teams in Gänze oder durch Vertreter zusammenkommen. Stattdessen werden lediglich die normalen Daily-Termine der Einzelteams abgehalten, mit nur einer einzigen Besonderheit: sie finden sequenziell nacheinander statt, und zwar in ein und demselben (physischen oder digitalen) Raum.

Stellen wir uns der Einfachheit halber ein Projekt mit vier Teams vor. Von denen hält das erste sein Daily-Meeting um Neun Uhr ab, das zweite seines um Viertel nach Neun, das dritte um Halb Zehn, das vierte um Viertel vor Zehn (es sind also die agil-typischen 15 Minuten). Und wie es in vielen agilen und nicht-agilen Teams üblich ist, sind diese Meetings öffentlich - jeder der interessiert ist kann zu Besuch kommen, solange er nicht ablenkt, stört oder die Abläufe durcheinanderbringt.

Wie in diesem Szenario die einfachste Form der Informationsübermittlung aussehen könnte, erschliesst sich sofort - jedes Team kann einfach eines oder mehrere Mitglieder bestimmen, die während der gesamten (und mit einer Stunde noch recht überschaubaren) Dauer im Raum bleiben, den jeweils anderen Teams für Fragen zur Verfügung stehen und gegebenenfalls darauf aufmerksam machen können, was aus dem eigenen Team für die anderen relevant sein könnte.

Eine etwas strukturiertere, aber noch immer einfache Variante kann daraus bestehen, dass ein Team einem oder mehreren der anderen im Voraus übermittelt, welches von deren Mitgliedern es gerne am jeweiligen Tag als Gast bei sich haben würde. Das kann z.B. der Spezialist für ein bestimmtes Thema sein (der UX Designer, der Tester, etc.), zu dem aktuell von Abstimmungsbedarf ausgegangen wird. Ggf. kann er im Daily seines eigenen Teams auch bereits Vorklärungen vornehmen.

Auch für übergreifende Rollen, wie Projektleiter, Architekten, Kundenvertreter oder sonstige Stakeholder kann dieses Format geeignet sein. Alleine dadurch, dass sie während der Dailies im Raum bleiben, sind sie über alles Wesentliche aus allen Teams im Bilde, vom Arbeitsfortschritt über aktuelle Probleme bis zu zu klärenden Punkten. Und je nach Rolle können sie sich auch selbst daran beteiligen, z.B. dadurch, dass sie selbst das letzte der aneinandergereihten Dailies durchführen.

Ich habe dieses Vorgehen in verschiedenen Projekten mit bis zu acht Teams erlebt, und es hat in allen einen einfachen Informationsaustausch ohne zusätzliche Abstimmungs- und Koordinationsmeetings ermöglicht (zumindest auf Tagesbasis, wöchentliche oder monatliche Planungs- und Review-Termine sind nochmal ein eigenes Thema, selbst wenn man oft auch sie nach einem vergleichbaren Muster aufeinanderfolgend abhalten kann).

Ein spannendes Phänomen ist dabei, dass es nach einiger Zeit dazu kommen kann, dass die Grenzen zwischen den Dailies der Teams sich auflösen. Vor allem wenn es gelingt, dass Teams mit tendenziell grösseren Berührungspunkten direkt aufeinanderfolgen, kann es an den Schnittstellen zu kurzen Abstimmungen und Übergaben kommen, so dass ein fliessender Übergang ohne klare Grenzen entsteht, das morphende Daily eben, das durchgehend fortläuft und bei dem sich nur die Teilnehmer verändern.

Natürlich wird dieses Format nicht in jedem Kontext passen, und man sollte sich auch bewusst machen, dass bestimmte Voraussetzung zwingend erforderlich sind, etwa die Fähigkeit sich kurz zu fassen und auf das Wesentliche zu beschränken, oder die Fähigkeit auch in diesen kurzen Terminen auf unerwartete Entwicklungen einzugehen, selbst wenn der ursprüngliche Plan etwas anderes vorgesehen hat, das dann ggf. bis zum nächsten Tag warten muss.

Für alle, denen etwas daran liegt, dass mehrere zusammenarbeitende Teams unbürokratisch und ohne zusätzliche Meetings Informationen austauschen und Abstimmungen vornehmen können, ist ein morphendes Daily aber etwas, das man auf jeden Fall ausprobieren sollte, und das man möglicherweise bald so gut finden wird, dass man nicht mehr darauf verzichten möchte.

Wir alle kennen den für agile Teams anzustrebenden Idealzustand: crossfunktional, d.h. in der Lage, alle notwendigen Tätigkeiten selbst auszuüben, und selbstorganisiert, d.h. in der Lage, selbst darüber entscheiden zu können, welche dieser Tätigkeiten wann durchgeführt wird. In der Realität gibt es aber immer wieder Sachzwänge wirtschaftlicher oder regulatorischer Art, die diesen Idealzustand einschränken. Das macht Kommunikation und Koordination mit anderen Teams nötig.

Je nachdem wie (un)hierarchisch eine Organisation aufgestellt ist, kann die Gestaltung dieser Kommunikationsströme unterschiedliche Formen annehmen. Der klassische Weg ist dabei der durch das Management. Ein Team-, Abteilungs- oder Projektleiter sammelt die zu besprechenden Themen in seiner Einheit ein, trifft sich mit seinem Gegenpart aus der anderen Einheit, der dort vorher das Gleiche gemacht hat, bespricht alles mit ihm und bringt die Ergebnisse zurück zu seinen Leuten.

Eine solche Lösung ist zwar naheliegend, allerdings aus verschiedenen Gründen problematisch. Entscheidungskompetenz und Umsetzungsexpertise werden entkoppelt, diese Art der Informationsübermittlung dauert relativ lange, durch die verschiedenen Kommunikations-Stationen entsteht das Risiko von Stille Post-Effekten und es kann sich (ggf. unbeabsichtigt) beim Management Herrschaftswissen herausbilden.

Der häufig propagierte "agile Gegenentwurf" ist die Netzwerk-Organisation. Hierarchien kann es zwar auch hier noch geben, die Kommunikationsströme richten sich aber nicht mehr an ihnen aus. Stattdessen kann jeder Einzelne mit jedem Anderen (sowohl Personen als auch Gruppen) Kontakt aufnehmen und anstehende Themen besprechen und Klären. Gegebenenfalls können dabei auch direkte Kommunikationen zwischen unterschiedlichen Hierarchie-Ebenen zustande kommen.

Auch diese Lösung ist aber nicht unproblematisch. Es besteht das Risiko, dass die Kommunikation zerfasert und unübersichtlich wird, mit der Folge, dass entweder Redundanzen entstehen (die im schlimmsten Fall zu verschiedenen, ggf. inkompatiblen Lösungen für das selbe Problem führen), oder dass ein unverhältnismässig hoher Aufwand investiert werden muss, um für jeden nachvollziebar zu machen, wer gerade mit wem über welches Thema spricht.

Ein Versuch, einen Mittelweg zwischen diesen beiden Extremen zu finden, kommt von James Coplien, einem der unbekannteren Pioniere der agilen Software-Entwicklung (unter anderem hat er das Daily Scrum/Daily Standup erfunden). In seinem Ansatz der Scale Free Organisation ergänzt er die Netzwerk-Organisation um Personen, die Informationsknotenpunkte, die so genannten Hubs, bilden, welche die zu kommunizierenden Informationen konsolidieren, bzw. verteilen.

Der Unterschied zu dem Management-zentrierten Ansatz ist, dass es sich bei diesen die Informationen konsolidierenden, bzw. verteilenden Personen nicht um Manager oder sonstige Funktionsträger handelt, sondern lediglich um Menschen, die aufgrund ihrer Kommunikativität, ihrer Versetzungshistorie, ihrer Bereitschaft Wissen zu teilen oder sonstiger Faktoren (z.B. der Mitgliedschaft im Betriebssportverein) überdurchschnittlich viele andere Menschen kennen und bei Bedarf Kontakt zu ihnen herstellen können.

Ebenfalls im Unterschied zum Management-zentrierten Ansatz erfolgt die Herausbildung von Hubs selbstorganisiert, emergent und ggf. temporär. Mit anderen Worten: da kommunikative und/oder gut vernetzte Personen mit höherer Wahrscheinlichkeit angesprochen werden oder an Abstimmungs-Meetings (z.B. einem Scrum of Scrums) teilnehmen werden als andere, verstärkt sich ihr Hub-Status selbst. Fallen Hubs aus (z.B. durch Versetzung) entsteht durch die gleichen Mechanismen ein Ersatz.

Bedingt durch diese Selbstorganisations- und Kompensationsmechanismen (die Coplien in 200 von ihm untersuchten Unternehmen identifizieren konnte) sind Organisationen, deren Kommunikation über derartige Hubs läuft, mit einer hohen Effektivität, Flexibilität und Resilienz ausgestattet, da in ihnen direkte Verbindungen immer da entstehen wo sie gerade gebraucht werden, ohne dass sie sich durch Regulierung oder Normierung verfestigen.

Irgendwann zwischen 2015 und 2020 hat ein zunächst merkwürdig anmutender Trend begonnen. Waren die Berichte aus den agilen Methoden-Implementierungen grosser Konzerne bis dahin entweder von den Buzzwords aus SAFe oder denen aus dem Spotify Model durchsetzt, gab es ab diesem Zeitraum plötzlich viele, in denen beides vermischt wurde. Tatsächlich taucht seitdem in immer mehr Unternehmen ein Hybrid aus beiden Ansätzen auf, häufig als "SpotiSAFe" bezeichnet.¹

Um zu verstehen wie es dazu gekommen ist, muss man sich eine Besonderheit von SAFe vor Augen halten: als einziges agiles Framework gestaltet es auch die Budgetierung um. Während klassische projektorientierte Organisationen Pools gleichartiger Spezialisten finanzieren (Entwickler, UX-Designer, etc.), von denen die Projekte ihre Teammitglieder "mieten" müssen,² geht das SAFe Lean Portfolio Management einen anderen Weg und budgetiert die Value Stream-basierten Release Trains direkt.

Wenn eine Organisation aber ihre Matrix-Organisation aus Spezialisten-Pools und Projekt-/Produktteams beibehalten will, sei es aus schlechten Gründen (haben wir schon immer so gemacht) oder aus guten (zur Förderung fachlicher Exzellenz oder zur Ermöglichung langfristiger Personalentwicklung über mehrere Projekte hinweg), dann muss sie SAFe an dieser Stelle anpassen. Wenn aber vorgegeben ist, "dass alles agil werden soll"³ braucht es in diesem Fall auch eine "agile Variante der Matrix-Organisation".⁴

Und an dieser Stelle kommt das Spotify Model ins Spiel, dass ja nichts anderes als eine derartige Matrix ist. Die Spezialisten-Pools heissen in ihm Chapter und die "entleihenden" Einheiten sind die "Squad" genannten Teams, bzw. die aus mehreren Squads bestehenden Tribes. Dadurch, dass diese Chapter jetzt auch in SAFe eingeführt werden, so dass die Release Trains aus ihnen ihre Mitglieder beziehen können, entsteht auch dort eine Matrix-Organisation in Form von SpotiSAFe.

Je nachdem wie weit die "Spotifyisierung" von SAFe getrieben werden soll können auch noch weitere Elemente aus SAFe nach vergleichbaren Einheiten aus dem Spotify Model umbenannt werden, so dass z.B. aus den Teams die Squads werden, aus den Release Trains die Tribes und aus den Communities of Practice die Gilden. Der zentrale Punkt bleibt aber die Kombination von SAFe und Matrix-Organisation (mit irgendwie "agil klingenden" Namen).

Das ist es also, das SpotiSAFe Model, das seit etwa einem Jahrzehnt von den McKinseys, Boston Consultings und anderen Beratungen in einem Konzern nach dem anderen eingeführt wird. Es zu bewerten ist nicht eindeutig möglich, wie oben gesagt gibt es sowohl gute als auch schlechte Gründe für eine Beibehaltung eines Matrix-Aufbaus. Wie immer gilt also auch hier, dass es auf den jeweiligen Einzelfall ankommt - und darauf, wie gut man "agile Buzzwords" verträgt.⁵

Grafik: Pixabay / GDJ - Lizenz

Sobald irgendwo mehrere agile Teams zusammenarbeiten sollen kommen sie ins Spiel: agile Skalierungsframeworks. Mittlerweile gibt es eine ganze Reuhe von ihnen, die alle ihre Fans und Skeptiker haben. Eine Frage wird dabei aber erstaunlich selten gestellt - gibt es Strukturmerkmale, anhand derer man sie grundlegenden Mustern zuordnen kann? Für ein Buchprojekt habe ich versucht, eine entsprechende Übersicht zu erstellen, die ich auch hier teilen möchte.

Wichtig für das Verständnis ist dabei, dass die einzelnen Vorgehensmodelle hier nicht im Detail vorgestellt werden sollen. Es geht darum hervorzuheben, was sie von den anderen unterscheidet und welche ihrer Elemente wesensbestimmend sind. Detailbeschreibungen zu jedem einzelnen gibt es an verschiedenen anderen Stellen, das hier ist ein Versuch einer grundlegenden Gruppierung, die einen Einstieg in das Thema der agilen Skalierung erleichtern soll.

Scrum-Skalierungsframeworks

Beginnen wir mit den Minimalisten. Die Scrum-Skalierungsframeworks LeSS (Large Scale Scrum) und Nexus haben den Anspruch, Scrum zu skalieren ohne ihm Meetings und Rollen hinzuzufügen. Ihre Grundidee: mehrere Scrum Teams teilen sich einen Product Owner, ein Backlog und eine Definition of Done und haben gemeinsame Plannings und Reviews, führen die dazwischenliegenden Sprints aber getrennt durch. Sehr unbürokratisch, für den Product Owner aber ggf. sehr fordernd.

Hierarchische Skalierungsframeworks

Im deutlichen Kontrast dazu führen hierarchische Skalierungsframeworks wie Scaled Agile Framework (SAFe) und Scrum@Scale oberhalb der Scrum Teams neue Hierarchieebenen ein, SAFe etwa den Product Manager und den Release Train Engineer, Scrum@Scale den Chief Product Owner und den Scrum of Scrums Master [sic]. Bei grösseren Vorhaben ist das nochmal erweiterbar, für weitere Hierarchieebenen können nochmal weitere Rollen geschaffen werden.

Dynamische / Fluide Skalierungsframeworks

Dynamische Ansätze wie FAST (Fluid Agile Scaling Technology) und Unfix stellen die Idee des crossfunktionalen und autonomen Teams in den Mittelpunkt. Bei grossen oder komplexen Produkten kann es sein, dass eine solche Einheit deutlich mehr als die üblichen zehn Personen umfassen muss. Um trotz dieser Grösse agil bleiben zu können ist es vorgesehen, dass sich innerhalb dieser stabilen Einheiten Untereinheiten je nach Bedarf bilden und wieder auflösen können. Quasi ein agiles Organigramm.

Kanban-Skalierungsframeworks

Aufgrund der "Open Source-Natur" von Kanban sind die Skalierungs-Möglichkeiten in diesem Bereich sehr wenig formalisiert, bzw. sehr individuell. Die grundlegende Idee ist aber eine Optimierung des Arbeitsflusses oder Wertstroms. Skalierung bedeutet in diesem Sinn, dass Umfang oder Anfangs- und Endpunkt des Wertstroms immer weiter definiert werden, etwa durch Einbeziehung von Zulieferern oder Parallel-Fertigungen. Bestehende Rollen und Hierarchien bleiben dabei zunächst unverändert.

Kommunikationsorientierte Skalierungsframeworks

Ähnlich wie bei den Kanban-Skalierungsframeworks verzichten kommunikationsorientierte Ansätze wie Flight Levels oder Open Space Agility zunächst auf neue Rollen und Strukturen. Stattdessen werden übergreifende Abhängigkeiten für alle sichtbar visualisiert (Flight Levels) oder in Grossgruppen-Formaten regelmässig mit allen Beteiligten besprochen (Open Space Agility). Basierend darauf können dann Kommunikation und Zusammenarbeit dort stattfinden wo es Sinn macht.

Sonstige Skalierungsframeworks

Über die gerade gennten agilen Skalierungsansätze hinaus gibt es auch weitere die immer wieder genannt werden, u. a. das so genannte "Spotify Model" und organisationsweite Objectives and Key Results (OKRs). Bei ihnen handelt es sich aber nicht um agile Skalierung im eigentlichen Sinn, sondern eher um eine kreative Neubenennung klassischer Organisationsprinzipien (Spotify = Matrix-Organisation, organisationsweite OKRs = Zielkaskadierung). Auch ok, nur ein anderes Thema als das hier.

Soviel zur Übersicht - aber was kann man jetzt mit ihr machen?

Eine guter Einsatzmöglichkeit ist, vor (!) dem Beginn einer wie auch immer gearteten agilen Skalierung zu überprüfen, welche dieser Grundmuster in der eigenen Organisation vermittelbar wären. Sind beispielsweise Scrum oder Kanban auf Teamebene gesetzt? Dann machen diese Ansätze vermutlich auch in der Skalierung Sinn. Wird Wert auf Hierarchien gelegt? Dann passen SAFe und Scrum@Scale. Soll maximale Flexibilität möglich sein? Dann passen die dynamischen Skalierungsframeworks besser.

Was durch ein derartiges Vorgehen möglich wird, ist eine Lösung die zur Aufgabenstellung passt, statt einer Lösung an die die Aufgabenstellung angepasst werden muss. Denn so merkwürdig es klingt - Variante zwei ist zur Zeit noch verbreiteter als Variante eins. Das umzudrehen kann nur im Interesse aller Beteiligten sein.

Bild: Pixabay / The Real Cicero - Lizenz

Zu den am weitesten verbreiteten Missverständnissen über Scrum gehört vermutlich, dass es nur für einzelne Teams ausgerichtet wäre. Tatsächlich ist das aber falsch, der Scrum Guide ist da sehr klar: es können sich z.B. mehrere Teams einen Product Owner und ein Product Backlog teilen, ausserdem (und darum soll es hier gehen) es kann sein, dass es eine unternehmensweite Definition of Done gibt, die für alle Teams verbindlich ist.

If the Definition of Done for an increment is part of the standards of the organization, all Scrum Teams must follow it as a minimum. If it is not an organizational standard, the Scrum Team must create a Definition of Done appropriate for the product.

Scrum Guide, 2020

Aus einer Scrum-puristischen Sicht erscheint diese Regelung zunächst wie eine Zumutung, schliesslich wird durch sie massiv in die Selbstorganisation des Teams eingegriffen. Dass diese Regelung trotzdem 2013 in den Scrum Guide aufgenommen wurde und in den seitdem stattgefundenen Aktualisierungen auch beibehalten wurde, muss also gewichtige Gründe haben. Sich diese bewusst zu machen kann für Verständnis sorgen und die Akzeptanz dieser Regelung erhöhen.

Ein erster gewichtiger Grund, der vor dem Hintergrund zu sehen ist, dass Scrum bis heute vor allem in der Software-Entwicklung eingesetzt wird, ist, dass eine gemeinsame Definition of Done gemeinsame Entwicklungsstandards möglich macht. Die können aus Coding-Standards, Schnittstellen-Definitionen, Testabdeckungs-Vorgaben oder ähnlichen Regeln bestehen und dafür sorgen, dass keine Team-basierte Code-Ownership entsteht und der Code auch teamübergreifend verständlich und weiterentwickelbar ist.

Ein zweiter Grund kann sein, durch eine gemeinsame Definition of Done übergreifende Release-Prozesse zu vereinfachen. Wenn z.B. grössere Mengen an Features erst ab einem bestimmten Zeitpunkt verfügbar sein sollen (etwa dem Weihnachtsgeschäft), kann es unnötig verkomplizierend wirken, wenn diese zum Teil bereits auf Produktion verfügbar aber ausgetoggled sind und zum Teil noch in einer Staging-Umgebung warten. Das zu vereinheitlichen erleichtert Qualitätssicherung und Go Live.

Ein dritter Grund kann der sein, dass ein einheitliches Auftreten gegenüber dem Kunden sichergestellt wird. Wenn z.B. "Done" so definiert wird, dass neue Features für den Anwender benutzbar sein müssen, dann kann es sinnvoll sein, übergreifend festzulegen in welchem Ausmass auch die Aktualisierung von FAQs und Benutzer-Handbüchern dazugehört. Findet das nicht statt werden die Anwender möglicherweise unterschiedliche Beschreibungstiefen vorfinden und Frustrationserlebnisse haben.

Im Zweifel sind noch weitere Gründe vorstellbar, dass eine übergreifende Definition of Done Sinn machen kann dürfte aber klar geworden sein. Dort wo man sie einführen will sollte man sich allerdings eines Risikos bewusst sein: wenn sie alles enthält was für alle betroffenen Teams relevant ist, kann sie gross und unübersichtlich werden und ggf. dadurch noch weiter aufgebläht werden, dass in ihr beschrieben werden muss, welche ihrer Teile nur für bestimmte Teams gelten und welche nicht.

Um das zu verhindern empfiehlt es sich, den Abschnitt aus dem Scrum Guide nochmals durchzulesen. Ihm zufolge bildet die übergreifende Definition of Done nur einen Minimalteil, den die Teams individuell erweitern können. Sich auf die nur unbedingt nötigen Mindeststandards zu beschränken und alles andere den Teams zu überlassen kann daher dabei helfen, aufgeblähte Umfänge und in Einzelfällen nicht mehr überall relevante Vorgaben zu vermeiden.

Zuletzt sollte immer in Erinnerung bleiben, dass die Definition of Done eine Hilfe für die Teams bei der Erstellung ihrer Incremente ist, und nicht ein Kontroll- oder Managing-Instrument. Es macht sehr viel Sinn regelmässig nachzufragen ob das was in ihr steht von den Teams als hilfreich oder behindernd wahrgenommen wird. Und wenn letzteres der Fall ist sollte es immer möglich sein Anpassungen vorzunehmen, um erneut zu einer allgemein akzeptierten Form zu kommen.

Wenn es um das so genannte Spotify Model geht, bin ich durch vermutlich den gleichen Hype Cycle gegangen wie viele andere auch. Zu Beginn fand ich es spannend und cool, habe es später abgelehnt als etwas, was nicht einmal Spotify selbst macht und bin mittlerweile an dem Punkt angekommen, an dem ich es für einen nicht überall anwendbaren aber grundsätzlich sinnvollen Ansatz halte. Dieser Vortrag von Joakim Sunden, einem der ersten Agile Coaches bei Spotify, bestätigt mich in dieser Ansicht.

Seine Ausführungen basieren im Wesentlichen auf der agilen Transition des norwegischen Telekommunikationsunternehmens Telenor, dass er in einem späteren Job auf das Spotify Model umgestellt hat. Die wichtigsten Erkenntnisse (wenn man sie hören will): das Spotify Model kann ein funktionierendes "agiles Betriebssystem" sein, dass man in Firmen einführen kann, Es ist mehr als nur Tribes, Squads, Chapters und Gilden, und für viele sicher überraschend - es ist kompatibel mit SAFe.

Bild: Pixabay / Annca Pictures - Lizenz

Die grosse Skepsis, mit der die agile Community SAFe betrachtet, hat dazu geführt, dass auch viele der mit diesem Skalierungs-Framework in Verbindung gebrachten Ideen abgelehnt werden. Das ist in den meisten Fällen bedauerlich, schliesslich wurde fast nichts von SAFe selbst erfunden sondern so gut wie alles aus anderen Kontexten übernommen, in denen die Umsetzung deutlich näher am agilen Idealbild war. Ein Beispiel an dem man das gut nachvollziehbar machen kann ist der Release Train.

In seinem Kern beruht dieses Konzept auf einer frühen Vor-Form von Continuous Delivery. Die ursprünglich üblichen Quartals- oder Jahres-Releases sollten vermieden werden, gleichzeitig waren automatisierte Build Pipelines und Continuous Integration zum Entstehungszeitpunkt der Release Train-Idee noch wenig verbreitet. Die Lösung für dieses Problem waren regelmässige (wöchentliche oder monatliche) Releases, die jeweils alles enthielten was zu diesem Zeitpunkt fertig entwickelt war.

In diesen regelmässigen Releases waren verschiedene relativ langwierige Vorgänge enthalten, die nicht unterbrochen oder übersprungen werden durften wenn die Qualität des Ergebnisses sichergestellt sein sollte, etwa das Konfigurieren von Staging-Umgebungen, das Einspielen von Testdaten, das Durchführen automatisierter und manueller Tests, etc. Für alle Features die zum Release-Zeitpunkt noch nicht fertig entwickelt waren war daher "der Zug abgefahren". Aus diesem Bild entstand dann die Benennung.

Aus heutiger Sicht erscheint das alles nur eingeschränkt agil (die aktuelle Benchmark sind beliebig viele Releases pro Tag), in der damaligen Zeit (frühe 2000er Jahre) war es dagegen revolutionär und verhalf Unternehmen wie Yahoo, Netscape, AOL, eBay und Google zu ihren damals marktbeherrschenden Positionierungen. Es gibt Vermutungen, dass Release Trains ursprünglich von eBay erfunden wurden, wozu passen würde, dass zu den frühesten Quellen der ehemalige eBay-Manager Marty Cagan gehört.

In bestimmten Konstellationen können Release Trains sogar heute noch Sinn machen, z.B. überall dort wo Regressionstests mehrere Stunden oder Tage dauern können (ein typischer derartiger Fall wäre die Embedded Software von autonomen Fahrzeugen oder Robotern, deren Testzyklus-Dauer durch die maximale Fahrtgeschwindigkeit und durch die Menge der möglichen Navigations-Manöver bestimmt wird und dadurch ggf. sehr lange sein kann).

Interessant und kontrovers ist schliesslich die Frage ob es in Release Trains spezifische Management-Rollen geben sollte. Im oben verlinkten Marty Cagan-Artikel aus dem Jahr 2007 ist allgemein von Projektmanagern und spezifisch von der Rolle des so genannten Conductor (Schaffner) die Rede, in SAFe gibt es den Release Train Engineer (Lokführer). Aus einer "agilen Perspektive" sollte man den beteiligten Teams dagegen zutrauen sich unkompliziert selbst zu koordinieren.

Leider drehen sich mittlerweile die meisten Release Train-Diskussionen nur noch um diesen Aspekt, bis zu dem Punkt, dass (SAFe-) Release-Trains heute primär über ihre Koordinations-Rollen und -strukturen definiert (und wegen ihnen abgelehnt) werden. In den Vordergrund zu stellen wie die Idee eigentlich gemeint ist könnte dabei helfen die Debatten wieder fokussierter und zielführender zu machen.

Bild: Flickr / Rasmus Anderson - CC BY-NC 2.0

Reden wir noch einmal über das berühmt-berüchtigte Spotify Model, jenen Erfahrungsbericht, der ohne dass es von seinem Verfasser jemals geplant war zu einer Blaupause für zahllose agile Transitions- und Skalierungsvorhaben geworden ist. Dass diese Verwendung nicht im Sinne des Erfinders ist und besser unterlassen werden sollte ist ein immer wieder vorgebrachtes Mantra vieler überzeugter Agilisten. Ein bekannter Name sieht das allerdings anders - der Erfinder selbst, Henrik Kniberg.

Wird Kniberg zu "seinem" Framework befragt (z.B. hier) äussert er sich in der Regel undogmatisch und realistisch. Er sagt, dass in seiner Wahrnehmung die überwiegende Mehrzahl der Umsetzungen weder zu Verbesserungen noch zu Verschlechterungen führt, dass es eine kleine Menge gibt bei der es zu signifikanten Verbesserungen kommt, aber fast keine Beispiele dafür, dass Verschlechterungen die Folge sind. Und diese Beobachtung ist bemerkenswert genug für einige Überlegungen.

Dass die Mehrzahl der Umsetzungen alles beim Alten lässt liegt an einem schlichten Grund: das Spotify Model wird von Beratungen vor allem an Konzerne verkauft, und die sind in der Regel als Matrix-Organisation aufgestellt. Auch das Spotify Model ist eine solche Matrix-Organisation, so dass seine Einführung oft nur eine Umbenennung ist - aus Abteilungen werden Chapter, aus Projekten Squads oder Tribes. So wird zwar nichts besser, aber eben auch nichts schlechter.

Zu Verbesserungen kommt es dort wo die über den blossen Organisationsaufbau hinausgehenden Vorteile des Spotify Models erkannt und umgesetzt werden (mehr dazu hier). Die Ähnlichkeit zur klassischen Matrix-Organisation kann dabei sogar ein Vorteil sein, da der Umbruch weniger hart erscheint und die Sorgen und Widerstände dementsprechend geringer ausfallen. Die Veränderungen erfolgen in solchen Fällen eher evolutionär, was sie aber nicht weniger wirksam macht.

Wirklich interessant ist aber, dass es kaum Fälle gibt in denen eine Umstellung auf das Spotify Model zu einer Verschlechterung des Gesamtzustandes führt (was ich aufgrund der Erfahrungen die ich in über 10 Jahren bei vielen Kunden und auf zahllosen Meetups gemacht habe nur bestätigen kann). Gerade vor dem Hintergrund, dass erschütternd viele Veränderungsvorhaben nur Verschlimmbesserungen hervorbringen, sollte das nicht geringgeschätzt werden.

Näher betrachtet ist ein Grund dafür, dass es nicht nötig ist die alte, funktionierende Struktur zu zerstören um die neue Zielstruktur errichten zu können. Die Ähnlichkeit zur alten Matrix-Organisation ermöglicht schrittweises Ausrollen, eine beliebig lange Koexistenz von alter und neuer Welt und im Extremfall sogar ein relativ schmerzloses rückgängig Machen. Ein riskanter "methodischer Big Bang Release" wird dadurch unnötig, ein dezentrales und asynchrones Change Management wird einfacher.

Ein zweiter Grund ist die einzigartige Benennung der Organisationseinheiten, die verhindert, dass aus anderen Kontexten bereits mit Bedeutungen belegte Begriffe umgedeutet werden müssen. Weder bedeuten alte Namen wie Abteilung oder Projekt plötzlich etwas anderes, noch müssen "agile Fachbegriffe" für Konzern-Erfordernisse verbogen und verfremdet werden, wie es z.B. mit der Scrum-Terminologie in SAFe passiert. Mehrdeutigkeit und Missverständnisse werden so unwahrscheinlicher.

Zusammengenommen tragen diese Faktoren zu Knibergs Beobachtungen bei, dass das Spotify Model meistens wenig verändert, immerhin manchmal die Zustände verbessert und sie dafür nur sehr selten verschlechtert. Zwar bedeutet das, dass man mit ihm keinen "Grossen Sprung nach vorne" durchführen kann, das Risiko, dass es zu Widerständen kommt und die Wahrscheinlichkeit von versehentlichen Verschlimmbesserungen sind dafür aber gering.

Mir ist gerade aufgefallen, dass es auf dieser Seite noch kein Video von mir gibt - bis jetzt. Das hier ist mein Vortrag vom Scaling Agile Summit im letzten Sommer, den ich auf dem Telekom Agilista-Barcamp wiederholt habe, wo er freundlicherweise aufgenommen wurde. Das Thema ist eines das mich schon lange begleitet und beschäftigt, die agile Skalierung.

Ich weiss nicht ob es daran liegt, dass ich zu dem Zeitpunkt Corona-positiv und dadurch etwas unkonzentriert war, aber ich höre in meinem Vortrag viel zu viele Ähs. Da muss ich noch an mir arbeiten

Bild: Pexels / Gustavo Fring - Lizenz

Drei Jahre ist es mittlerweile her, dass das Project Management Institute (PMI) das agile Framework Disciplined Agile (DA) gekauft hat. Sicher hat auch hier die Corona-Pandemie einiges von den ursprünglichen Plänen durcheinandergeworfen, trotzdem lohnt sich mittlerweile wieder ein Blick: wie hat sich das DA-Regelwerk entwickelt, wie ist mittlerweile der an den Zertifizierungen ablesbare Verbreitungsgrad, was gibt es sonst noch?

Zuerst zum Regelwerk. Der Baukasten-Ansatz ist weiter vorangetrieben worden, die Möglichkeit den eigenen Arbeitsprozess selbst zu gestalten steht im Vordergrund. Grundlegend ist das auch gut so, die Anleitung für den Auswahlprozess ist aber eine kuriose Mischung aus esoterisch und mechanistisch. Z.B. soll dort wo agiles Arbeiten in Frage kommt das Mindset der Teams geprüft werden. Ist es ein agiles Mindset soll agil gearbeitet werden, wenn nicht dann Lean. Alleine diese Vorgabe wirft viele Fragen auf.

Auch das agile Mindset selber hat jetzt eine Ausformulierung bekommen, in seiner DA-Form besteht es aus den drei Bereichen der Prinzipen, Versprechen und Richtlinien. Auch hier ist wieder grundlegend alles sinnvoll, im Detail aber hinterfragbar. Dass zum Beispiel gleich das erste Versprechen die Herstellung von Psychologischer Sicherheit ist, ist gewagt. Ein derartig fragiles und privates Gefühl ist nur schwer zu beeinflussen. Daran arbeiten kann (und sollte) man, aber es versprechen?

Während diese Aspekte noch ambivalent betrachtbar sind dürfte ein anderer den meisten Agilisten zu Schnappatmung verhelfen: die Rollen. Alleine auf Teamebene gibt es 10 Team- und Unterstützungsrollen, für die umgebende Organisation kommen nochmal 40 weitere dazu. Selbst wenn herausgestrichen wird, dass man nicht alle einführen muss und dass ggf. eine Person mehrere übernehmen kann - das ist im Vergleich zur ursprünglichen Rollen- und Posten-aversen Agilität ein heftiger Paradigmen-Bruch.

Auch einen zweiten Paradigmen-Bruch kann man im aktuellen Stand von DA beobachten: DevOps hat in seiner DA-Variante zwar theoretisch noch seine ursprüngliche Bedeutung von Entwicklung und Betrieb in einer Hand, in den Detailbeschreibungen ist aber vieles doch wieder verkompliziert und in eigene Organisationseinheiten ausgelagert, in denen dann einige der gerade genannten Rollen vorgesehen sind. De facto entsteht so doch wieder eine Parallelexistenz von Entwicklung und Betrieb.

Bei weiterer Betrachtung ist diese Konstellation Teil eines grösseren Musters: je länger man liest desto mehr Themen findet man die sich nicht in der Verantwortung der umsetzenden Einheiten befinden. Einige davon nachvollziehbarerweise (z.B. Recht), bei einigen anderen handelt es sich aber um solche deren Verantwortung man normalerweise innerhalb und nicht ausserhalb eines agilen Teams verorten würde, zum Beispiel Produktmanagement und Architektur. Dies ist der dritte, und bei weitem grösste, Paradigmenbruch.

Nun ja. Bei realistischer Betrachtung ist das PMI mit dieser Einstellung nicht alleine, die meisten grossen Firmen denken so. Kann man daraus schliessen, dass DA zumindest in Konzernen bereitwillige Abnehmer vorfindet und nach und nach dieses Marktsegment aufrollt? Eher nicht. Eine aktuelle Auswertung kommt auf lediglich 5000 verkaufte Zertifizierungen. Zum Vergleich: Scrum Alliance und SAFe haben über eine Million, Scrum.org 700.000, sogar vom veralteten agilen ACP-Zertifikat von PMI gibt es noch 50.000.¹

Und apropos Zertifizierungen - die bilden weiterhin ein Kuriosum. Zwar sind sie mittlerweile neu strukturiert und umfassen an Stelle des ehemaligen "Disciplined Agile Lean Scrum Master" (DALSM) jetzt den "Disciplined Agile Scrum Master" (DASM), den "Disciplined Agile Senior Scrum Master" (DASSM), den "Disciplined Agile Coach (DAC) und den "Disciplined Agile Value Stream Consultant" (DAVSC) - im gesamten Regelwerk tauchen sie aber kein einziges mal auf.

Der Gesamteindruck: Disciplined Agile wurde erkennbar strukturiert und konsolidiert, macht aber noch immer über weite Teile einen eher konfusen Eindruck. Und bei vielen Inhalten stellt sich die Frage wie agil es überhaupt noch ist. Nimmt man den Verkauf der Zertifikate als Massstab ist das Ganze zudem ein wirtschaftlicher Fehlschlag. Auch darüber hinaus scheint einiges im Argen zu liegen, im oben erwähnten Artikel steht auch, dass die DA-Gründer Mark Lines und Scott Ambler das PMI verlassen haben.

Das muss natürlich noch nicht das Ende sein, mit seinen Finanzreserven und seiner globalen Verbreitung hat das PMI noch immer gewaltige Ressourcen die es in seinen agilen Bereich stecken kann. Es ist aber zumindest zweifelhaft ob es in absehbarer Zeit dazu kommen wird, dass Disciplined Agile mehr als nur ein Nischendasein fristen wird.

Mal wieder ein origineller Blick darauf wie in Organisationen Agilität skaliert werden kann. Die hier von Jim Coplien vorgetragene Sichtweise beruht auf der Idee, dass in einem weitgehend hierarchiefreien System netzwerkartige Verbindungen zwischen den einzelnen Einheiten bestehen, die auf den jeweils kommunikativsten Teammitgliedern beruhen. Diese bilden die Knotenpunkte eines organisationsweiten Netzwerks und formen gleichzeitig mit ihren weniger kommunikativen Kollegen kleinere lokale Netzwerke, in denen jeweils die Wertschöpfung stattfindet.

Was Copliens Ausführungen besonders macht ist ihre wissenschaftliche Fundierung. Seit den frühen 90er Jahren erforscht er Organisationen und verdichtet die in diesem Rahmen erhobenen Daten zu wiederkehrenden Mustern. Das auch auf die eigene Organisation anzuwenden könnte spannend sein, das Tool stellt er zur Verfügung.

Grafik: Less.works - CC BY-NC-ND 2.0

Wenn es um die Skalierungsframeworks für Scrum geht sind es in den letzten Jahren vor allem drei die immer wieder genannt werden. SAFe, das vor allem in Konzernen immer populärer wird, sowie Nexus und Scrum@Scale, die den Vorteil haben, dass jeweils einer der beiden Urheber von Scrum hinter ihnen steht. Tatsächlich gibt es aber noch ein weiteres: Large Scale Scrum (abgekürzt LeSS), das 2005 entwickelt wurde und damit sogar deutlich älter ist als die drei anderen.¹

Diese Kombination aus relativ geringer Bekanntheit und relativ weit zurückliegender Entstehung hat dazu geführt, dass selbst unter den Skalierungs-erfahrenen Scrum Mastern und Agile Coaches viele sind die eine bestenfalls wolkige Vorstellung von diesem Framework haben. Je nachdem wen man fragt kann es als z.B. sehr schlank oder sehr umfangreich, als Teil des eigentlichen Scrum-Frameworks oder als separate und inhaltlich erkennbar abweichende Variante beschrieben werden.

Am schnellsten lässt sich die zuletzt genannte Unklarheit aufklären. LeSS war mal de facto ein Teil des offiziellen Scrum, hat sich aber mit dessen Versionen von 2017 und spätestens 2020 von ihm gelöst. Wesentliche neue Teile wie das Produkt-Ziel wurden nicht übernommen, gestrichene Teile wie die verpflichtenden drei Fragen im Daily wurden dagegen beibehalten. LeSS ist damit auch nach eigener Auffassung zu einer weiteren Variante geworden, die inhaltlich erkennbar eigenständig ist.

Komplizierter ist es bei der Frage wie schlank das LeSS-Framework ist. Von der Grund-Idee ist es sehr schlank, es basiert auf den Skalierungs-Aspekten die ohnehin im offiziellen Scrum-Guide stehen: wenn mehrere Teams an einem gemeinsamen Produkt arbeiten haben sie ein gemeinsames Product Backlog, einen gemeinsamen Product Owner und eine gemeinsame Definition of Done. Plannings und Reviews sind jeweils Team-übergreifend, neue Rollen und Termine werden vermieden.²

In den Büchern und auf der Website finden sich allerdings noch umfangreiche weitere Inhalte. Zugrundeliegende Prinzipien, notwendige Vorbedingungen in der Aufbau- und Ablauforganisation, Ausführungen zur Rolle des Managements, notwendige agile Praktiken der Software-Entwicklung und Anleitungen für die initiale Methodeneinführung werden hier beschrieben, in Summe kommen so mehrere hundert Seiten Text zusammen.

Die Frage ist jetzt ob diese erweiterten Inhalte als Teil von LeSS gesehen werden oder nicht. Wenn nicht ist es tatsächlich ein sehr schlankes Framework, dessen Regeln ähnlich wie die von Scrum selbst auf wenigen Seiten zusammenfassbar sind. Sind sie dagegen Teil von ihm kommt ein Gesamt-Umfang zu Stande der vermutlich zur Zeit nur noch von SAFe übertroffen wird. Entscheidend ist die eigene Interpretation, eine klare Trennung zwischen einem "LeSS-Guide" und Good Practices gibt es nicht.

Aus diesen Klärungen ergeben sich auch Implikationen für die Umsetzung. Firmen in denen für bereits nach Scrum arbeitende Teams nach einem Skalierungsframework gesucht wird sollten sich die Eigenständigkeit von LeSS bewusst machen und sich fragen wie wohl sie sich mit dem parallelen Einsatz von zwei verschiedenen Scrum-Varianten fühlen würden.³ Ist das unbedenklich kann LeSS eine interessante Option sein, da es keine zusätzlichen Rollen und Meetings erfordert.

Auch neu mit Scrum startenden Unternehmen sollte der Unterschied zum offiziellen Scrum bewusst sein, allerdings gibt es für sie ein weiteres klares Argument für LeSS: mit seinen umfangreichen Beschreibungen der notwendigen Vor- und Rahmenbedingungen geht LeSS weit über den Scrum Guide hinaus und macht die notwendigen Umstellungen in der Gesamt-Organisation besser erkennbar. Das erfordert grössere Anstrengungen, verhindert aber Optimierungen die nur lokale Effekte haben.

Für alle denen diese Vorgaben zu weit ins Detail geht und die gleichzeitig mit dem offiziellen Scrum kompatibel bleiben wollen gibt es übrigens mit Nexus eine Alternative die LeSS sehr ähnlich ist aber einen geringeren Umfang hat⁴ und auf dem aktuellen Scrum Guide aufbaut. Letztendlich gilt aber auch für beide das Urteil des Dodo: wenn sie auf den gleichen Absichten und Erkenntnissen aufbauen werden sie auch ähnliche Ergebnisse mit sich bringen.

Bild: Unsplash / Parabol - Lizenz

Wenn mehrere agil arbeitende Teams merken, dass sie häufigen Austauschbedarf haben, ist in den meisten Fällen die Einrichtung eines gemeinsamen Daily Meeting die Folge, in dem ein tagesaktueller Austausch zu Neuigkeiten, Abhängigkeiten und gemeinsamem Vorgehen möglich ist. Derartige teamübergreifende Dailies sind die früheste und einfachste Form der agilen Skalierung, aber bereits eine die in verschiedenen Varianten durchgeführt werden kann. Da diese jeweils verschiedene Vor- und Nachteile haben lohnt es sich kurz zurückzutreten und sie nebeneinander zu betrachten.

I. Sequentielle Team-Dailies mit "Scouting"

Die einfachste Variante. Alle Team-Dailies finden nacheinander statt (idealerweise in einem Raum oder in einem gemeinsamen Call), so dass jedes Team einen Vertreter (oft "Scout" genannt) bestimmen kann, der bei den jeweils anderen teilnimmt. Der Vorteil dieses Vorgehens ist, dass so keine neuen Meetings entstehen, der Nachteil, dass sich das Scouting bei mehreren Teams sehr in die Länge ziehen kann. Scouting wird u.a. im Skalierungs-Framework LeSS empfohlen.

II. Ein übergreifendes Daily vor den Team-Dailies

Ein eher seltener Ansatz. Die Grundidee hier ist es, Informationen zusammenzutragen die für die danach folgenden Team-Dailies wichtig sind, wie z.B. die Ergebnisse nachts durchlaufender Regressionstests. Das kann Sinn machen, die Schwierigkeit dabei ist aber, dass neue Inputs aus den Team-Dailies erst mit einem Tag Verspätung in die grosse Runde kommen. Ein typisches Umfeld für diese früh stattfindenden übergreifenden Dailies ist das Skalierungs-Framework Nexus.

III. Ein übergreifendes Daily nach den Team-Dailies

Der Klassiker. Der Austausch über das was in den Teams kurz vorher als übergreifend wichtig erkannt wurde ist unter dem Namen "Scrum of Scrums" in vielen Firmen anzutreffen und gehörte zu den ersten Skalierungselementen von Scrum die erfunden wurden, noch vor den Skalierungs-Frameworks. Der Vorteil ist, dass Erkenntnisse aus den Team-Dailies schnell verbreitet werden, es besteht aber das Risiko, dass auch vieles aus den Teams berichtet wird, was keine übergreifende Relevanz hat.

IV. Mehrere Spezialisten-Dailies

Ein Vorgehen das z.B. im Skalierungsframework Scrum@Scale zu finden ist. Nach den Daily Scrums der Teams folgen hier die der Product Owner und der Scrum Master, möglich sind auch die der Frontend-Entwickler, der Tester, etc., etc. Der Überblick der in solchen Runden entsteht ist sehr spezifisch, zur Verbreitung eigentlich irrelevanter Informationen kommt es seltener. Dafür besteht das Risiko, dass es an keiner Stelle zu einem Gesamtbild kommt sondern überall nur Ausschnitte sichtbar sind.¹

Welche dieser Varianten die am besten passende ist dürfte von Fall zu Fall unterschiedlich sein und sich möglicherweise sogar über die Zeit ändern. Um die passende zu finden bieten sich zwei Vorgehensweisen an: initial kann man sich fragen welchen Zweck das teamübergreifende Daily überhaupt haben soll, oft ergibt sich daraus schon ein Hinweis auf den passenden Modus. Sobald die Termine stattfinden kann man in den Inspect & Adapt-Modus übergehen, überprüfen ob sie den erhofften Mehrwert bringen und ggf. neues ausprobieren.

Nur von einem ist abzuraten: dem "Reporting-Daily" für das Management. Die gehen soweit an der Idee selbstorganisierter Teams vorbei und laden so stark zum Micro-Management ein, dass man sie gar nicht erst einführen sollte.

Ich bin begeistert. Darren Yeates hat es geschafft in diesem Vortrag genau das zu sagen was auch ich allen Menschen mitzugeben versuche, die mich danach fragen wie sie Agilität bei sich im Unternehmen skalieren sollten. Verkürzt gesagt: frage Dich zuerst ob Du es nicht auch ohne Skalierung erreichen könntest, sei Dir bewusst, dass es auch ein kulturelles Thema ist, pass gut auf ob Du nicht versehentlich Missverständnisse skalierst.

Was sich mir nicht völlig erschliesst ist lediglich der Untertitel "Electile Dysfunction". Offensichtlich ist es eine Anspielung auf "Erectile Dysfunction", mein Englisch reicht aber nicht aus um zu erkennen was damit gemeint ist.

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

Dass das Scaled Agile Framework (SAFe) in der agilen Community eher kritisch gesehen wird dürfte sich mittlerweile herumgesprochen haben. Es zu bashen gehört mittlerweile fast schon zum guten Ton, was dazu führt, dass es leider nur noch sehr einseitig betrachtet wird. Man kann ihm nämlich auch positive Aspekte abgewinnen, darunter einen der auf den ersten Blick überraschend wirkt - SAFe ist einfach zu erklären und zu verstehen.

Überraschend ist das deshalb weil in der öffentlichen Wahrnehmung vor allem das grosse Wimmelbild auf der Startseite von scaledagileframework.com bekannt geworden ist. Das als Grundlage einer einfachen Erklärung zu nutzen wäre tatsächlich eine Herausforderung. Was dabei allerdings oft übersehen wird ist, dass diese Übersicht stark mit Elementen überladen ist die optional sind oder bei denen es sich um Implementierungsdetails handelt. Um SAFe zu verstehen braucht man nur wenige.

Fangen wir oben an, bei einem Teil der zentral ist und in keiner Umsetzungen vernachlässigt werden sollte: dem Portfolio Kanban. Sein Design kann sich zwar je nach Fall unterscheiden, wichtig ist aber, dass hier die grossen Arbeitspakete (Epics) der zur Zeit umgesetzten Initiativen von links nach rechts wandern. Idealerweise wird diese Übersicht genutzt um zu verhindern, dass zu viele gleichzeitig begonnen werden, so dass mehr Focus und weniger Multitasking entstehen.

Bei der Organisation der Umsetzung tritt eine zentrale Annahme von SAFe in den Vordergrund: die, dass es einzelnen Team in kurzen Zeiträumen nicht möglich ist Arbeitspakete von relevantem Wert abzuschliessen. Aus diesem Grund wird eine doppelte Gruppierung vorgenommen - jeweils mehrere Teams arbeiten über mehrere aufeinanderfolgende Kurz-Zeiträume an einem solchen Arbeitspaket. Der Name einer solchen Gruppierung ist Release Train, die Zeitspanne nennt sich Program Increment (PI).

Damit die Teams eines Release Trains nicht nur gemeinsame Umsetzungszeiträume haben sondern auch an zusammengehörigen Themen arbeiten (und dabei die untereinander bestehenden Abhängigkeiten berücksichtigen) findet zu Beginn jedes Program Increments eine gemeinsame Planung statt, das PI Planning, bzw. Big Room Planning. Ggf. können begleitend dazu auch Retrospektiven stattfinden, entweder davor (für das letzte PI) oder danach (für das PI Planning selbst).

In der Theorie arbeiten die einzelnen Teams zwischen zwei PI Plannings nach Scrum (in mehreren Sprints), de facto ist dieser Arbeitsmodus aber stark beschnitten, da die Integration in einen Release Train dafür sorgt, dass die eigentlich vorgesehene Team-Autonomie nur noch eingeschränkt möglich ist. Vor allem die Kompetenzen des Product Owners und Scrum Masters werden zum Teil auf entsprechende Koordinationsrollen im Release Train übertragen, den Product Manager und den Release Train Engineer.

Und das ist sie auch schon, die einfache Erklärung von SAFe in nur vier Absätzen. Wendet man diesen Erklärungsansatz an hat das zwei Vorteile: zum Ersten den, dass erkennbar wird, dass sich hinter dem unübersichtlichen offiziellen Übersichtsbild eigentlich nur ein relativ einfacher Skalierungsansatz verbirgt. Hat man den erfasst wird es auch einfacher zu beurteilen welche der zahlreichen anderen Elemente man nutzen will und welche nicht.

Zum anderen kann man die zentrale Annahme von SAFe herausstreichen: die, dass es einzelnen Team in kurzen Zeiträumen nicht möglich ist Arbeitspakete von relevantem Wert abzuschliessen, weshalb sie in Release Trains und Program Incrementen zusammengekoppelt werden. Und an dieser Stelle wird diese einfache Erklärung auch für die SAFe-Skeptiker interessant - wenn sie belegen können, dass die Teams dazu doch in der Lage sind, entfällt die Notwendigkeit SAFe einzuführen.

Umgekehrt betrachtet: dort wo einzelne Teams nicht in der Lage sind in einzelnen Sprints Mehrwert abzuliefern ist SAFe zumindest eine Option. Ob es die richtige ist muss sich im Vergleich mit anderen Skalierungsframeworks klären, deren Befürworter dann in der Lage sein sollten sie ähnlich einfach zu erklären wie das bei SAFe möglich ist.

Bild: Flickr / Marco Verch - CC BY 2.0

Es gilt als eines der Erkennungsmerkmale von SAFe, ist aber als verbreitete Praktik auch in anderen agilen Skalierungsframeworks zu finden, und sogar in manchen klassisch aufgestellten Organisationen als Teil ihrer Jahres- oder Quartalsplanung. Die Rede ist vom Big Room Planning oder BRP (mittlerweile in SAFe in PI Planning umbenannt), einer Veranstaltung die genutzt wird um die Backlogs oder Roadmaps der beteiligten Teams aufeinander abzustimmen.

Wichtig zu seinem Verständnis ist, dass es aus puristisch agiler Sicht eigentlich Ausdruck einer Dysfunktion ist, bzw. diese kompensiert. Agil arbeitende Teams sollen möglichst crossfunktional sein, d.h. alle zum Abschluss ihrer Vorhaben nötigen Fähigkeiten und Berechtigungen selbst besitzen. Dort wo das gegeben ist gibt es für übergreifende Planungsstrukturen keine Notwendigkeit. Da das in der Realität oft aber nicht gewollt oder möglich ist wurde das Big Room Planning erfunden.

Als eine agile Praktik wird es deshalb angesehen, weil es zwei Sachen anders macht als traditionelle Planungspraktiken. Zum einen werden von einander abhängige Arbeitspakete nicht sequentiell abgearbeitet (wie häufig in Gantt-Charts zu sehen) sondern weitgehend parallelisiert. Die zusammengehörigen Aufgaben werden dabei von den Teams in den selben Sprints oder Wochen eingeplant um bereits in ihnen zusammengeführt und integriert zu werden.

Das zweite agile Merkmal der Big Room Plannings ist, dass die Koordination der Teams nicht von einem dafür zuständigen Management übernommen wird sondern von den jeweiligen Teammitgliedern selbst. Um das möglich zu machen führen die beteiligten Teams ihre Planungsaktivitäten gemeinsam in einem grossen Raum durch (daher der Name)¹ um sich bei Bedarf schnell besuchen und unbürokratisch miteinander abstimmen zu können.

Ein typischer Ablauf sieht so aus, dass bereits im Vorfeld grob geklärt wurde welche Arbeitspakete externe Zulieferungen benötigen (ggf. in teamübergreifenden Refinements). Basierend darauf können diese in einer initialen teamübergreifenden Vorstellungsrunde hervorgehoben werden, wodurch der Bedarf klargemacht wird. Zusätzlich können alle anderen überprüfen ob auch sie ebenfalls davon betroffen sein könnten.

In einer ersten Planungsrunde erarbeitet und priorisiert danach zuerst jedes Team für sich die eigenen Anforderungen und Zulieferungen, in einer zweiten Phase werden diese Ergebnisse den anderen Teams mitgeteilt und diesen wird die Möglichkeit zu Feedback und Änderungsvorschlägen gegeben, in einer dritten passt jedes Team basierend darauf seine Pläne an. Dieser Wechsel von Einzelplanung und Abstimmung kann so lange wiederholt werden bis ein gemeinsamer Plan herauskommt.

Als zusätzlicher Effekt können durch ein Big Room Planning nicht nur die Umsetzungs- sondern auch die Planungszeiträume deutlich verkürzt werden. Die teamübergreifend gemeinsame Terminierung, die direkte Kommunikation und die kurzen Wege können in Stunden oder Tagen ermöglichen, was vorher mitunter Wochen und Monate gedauert hat.² Natürlich unter der Voraussetzung, dass alle Mitglieder aller beteiligten Teams für die gesamte Dauer der Veranstaltung zur Verfügung stehen.

Bereits für eine effizientere Durchführung der Planungen für bestehende Teams kann ein Big Room Planning auf diese Weise einen erheblichen Mehrwert liefern, zu einer nachhaltigen Agilisierung des Unternehmens trägt es aber paradoxerweise dadurch bei, dass es sich selbst nach und nach abschafft. Die in ihm offensichtlich werdenden Abhängigkeiten lassen sich nämlich festhalten und auf langfristige Muster untersuchen, die dann grundlage für Prozessverbesserungen sein können.

Wenn beispielsweise alle Teams jedesmal von einem einzelnen abhängen kann überlegt werden dessen Skills und Berechtigungen auf die anderen zu übertragen (wenn es ein Spezialistenteam ist) oder seine Systeme für die Bearbeitung durch andere zu öffnen (wenn es ein Komponententeam ist). Andere denkbare Verbesserung wären die Vergrösserung von Flaschenhals-Teams oder das Aufteilen eines Teams (und seiner Systeme) analog zu fachlichen Domänen.

Als Folge derartiger Optimierungen werden Big Room Plannings häufig mit der Zeit kleiner oder teilen sich in voneinander unabhängige "Small Room Plannings" auf. Umgekehrt kann ein mit der Zeit immer grösser werdendes Big Room Planning ein Zeichen dafür sein, dass die Zahl der Abhängigkeiten zwischen den Teams wächst und die Gesamtorganisation dadurch schwerfälliger wird. Sicherlich eine weitere interessante Transitionsmetrik.

Bild: Wikimedia Commons / Florian Koppe - CC BY-SA 4.0

Wirft man einen Blick auf die Versuche grosser Organisationen sich agil zu organisieren, wird man mit grosser Wahrscheinlichkeit schon nach kurzer Zeit auf das so genannte "Spotify Model" stossen (das hier näher erklärt wird). 2012 eher zufällig in dieser Firma eintwickelt (und mittlerweile in der Ursprungsform dort gar nicht mehr im Einsatz) scheint es in vielen Konzernen einen Nerv getroffen zu haben. ING, Axa, Commerzbank, Telekom und viele mehr versuchen es bei sich umzusetzen.

Dass sich diese Change-Programme in der Realität schwierig gestalten (Beteiligte berichten unter der Hand von z.T. sehr durchwachsenen Ergebnissen) liegt natürlich zum einen daran, dass derartige Vorhaben immer schwer sind, zum anderen aber auch daran, dass der Ansatz mittlerweile aus verschiedenen Richtungen sehr stark politisiert und dogmatisiert wird, wodurch eine unbefangene Beschäftigung mit ihm immer schwerer wird.

Zum einen sieht diese Dogmatisierung so aus, dass versucht wird das Spotify Model unreflektiert als Blaupause für alle agilen Skalierungsvorhaben einzusetzen (warum das ein Problem ist kann man hier nachlesen), zum anderen hat sich als Gegenreaktion darauf unter vielen Scrum Mastern und Agile Coaches eine so reflexhafte und ebenso unreflektierte Ablehnung verbreitet, dass auf den Begriff ähnlich hysterisch reagiert wird wie in im Film Life of Brian auf das Wort Jehova.

In beiden Fällen bleibt eine wirkliche Beschäftigung mit dem Modell auf der Strecke. Das ist vor allem deshalb schade, weil viele seiner Elemente gute Lösungsansätze für real existierende Probleme bieten, so dass es sehr wohl Sinn machen kann einige oder sogar alle von ihnen bei sich einzuführen - immer unter der Voraussetzung, dass man diese Probleme wirklich hat, und dass regelmässig überprüft wird ob sie sich wirklich so lösen lassen.

Beispielsweise kann das Konstrukt eines Tribes, also einer Gruppe von Teams die aufeinander abgestimmt an einem gemeinsamen Produkt arbeiten, eine grosse Hilfe sein wenn die einzelnen Teams (noch) nicht oder nur zu langsam in der Lage sind dieses Produkt alleine weiterzuentwickeln. Ebenfalls nicht zu unterschätzen ist die Aussenwahrnehmung, in der ein Tribe deutlich sichtbarer und ansprechbarer erscheint als eine Ansammlung von für Teilprodukte zuständigen Einzelteams.

Auch die in den Tribes vorhandenen Chapter (Querschnittsorganisationen für gleichartige Spezialisten) können einen Mehrwert bieten. Zum Einen wegen ihrer Koordinations- und Abstimmungsfunktion, zum Anderen wegen der Beschränkung der "Chapter Lead"-Rolle auf eine Teilzeitstelle, die von einem Mitglied neben der Entwickler-Tätigkeit übernommen wird. Die bei Team- und Gruppenleitern sonst häufige Entfremdung von der Arbeit der Teams kann so gar nicht erst entstehen.

Ebenfalls hilfreich können die Gilden sein, der dritte Skalierungs-Aspekt des Spotify Models. Von Bedeutung ist hierbei, dass sie explizit keine Koordinationsfunktion haben (für die es ja bereits die Chapter gibt) sondern dass sie lediglich gemeinsame Interessen zum Gegenstand haben. Bedingt dadurch entfällt die Notwendigkeit für Führungsrollen, Regeln, Dokumentationspflichten und ähnliche Bürokratie-anfälligen Elemente, so dass der Fokus ganz auf Wissensaustausch und Erkenntnisgewinn liegen kann.

Um es noch einmal klar zu sagen: jeder der das Spotify Model bei sich einführen will sollte vorher überprüfen ob die Probleme für deren Lösung es entwickelt wurde in der eigenen Organisation vorhanden sind (und nicht bereits anders gelöst werden), nur dann macht die Einführung Sinn. Wenn diese Voraussetzung gegeben ist, ist dieser Weg aber eine brauchbare (wenn auch regelmässig zu validierende) Vorgehensweise.