Ein neues agiles Framework: FAST Guide veröffentlicht

Bild: Pixabay / Mahmur Marganti - Lizenz

Es ist schon eine Zeit lang her, dass zum letzten mal ein erwähnenswertes agiles Framework erfunden wurde. Es gab zwar Versuche, die waren aber entweder nur rudimentär entwickelt (z.B. POPCORN-Flow oder FLEAT) oder lediglich Variationen bereits bestehender Frameworks (z.B. Scrum 3.0 von Scrum oder TameFlow von Kanban). Dieses hier scheint in dieser Hinsicht besser zu sein: FAST (Fluid Agile Scaling Technology), erstmals veröffentlicht im März 2021 in Form des FAST Guide. Ob es erfolgreich sein wird muss sich noch zeigen, es ist aber ausdifferenziert genug um besprochen zu werden.

Wichtig ist zunächst, dass FAST sich selbst als Zusammenfassung und Weiterentwicklung bestehender Ansätze versteht, mit dem expliziten Anspruch Scrum abzulösen. Ron Quartel, der Schöpfer des Frameworks, nennt in dessen "Origin Story" die Hauptquellen Open Space Technology und Open Allocation/Dynamic Reteaming, im FAST-Guide kommen dazu noch Dunbar-Zahl/Tribe,  Ken Schwabers Überlegungen zu Post-Scrum und Verweise auf Conway, McGregor, Lewin, Pink und andere Vordenker. Aus all diesem Input entstehen die folgenden Elemente:

Tribes und (dynamische) Teams

Die  nach FAST arbeitenden Menschen bilden einen so genannten Tribe, der zunächst bis zu 14 Mitglieder haben kann (zu grösseren Einheiten siehe unten). Der Tribe ist in beliebig viele Teams unterteilt, die sich mit jeder Iteration (siehe nächster Absatz) selbstorganisiert in der für den Moment jeweils sinnvollsten Konstellation zusammenfinden. Das kann bedeuten, dass auf diese Art Feature-Teams zustande kommen, aber auch Komponenten-Teams oder Mischtypen sind möglich. Auch ein selbstorganisierter Neu-Zuschnitt der Teams während der Iteration geht, wenn es Bedarf dafür gibt.

Iterationen und FAST Meetings

Dass es Iterationen gibt ist auf den ersten Blick eine Gemeinsamkeit mit Scrum, ungewöhnlich ist aber die kurze Dauer und die sich oft ändernde Länge: empfohlen werden zu Beginn zwei Tage, anzustreben ist der kürzeste mögliche Zeitraum. Auch die Meeting-Struktur ist minimalistisch - es gibt lediglich ein Meeting, das zwischen zwei Iterationen stattfindet und ohne vorbereitete Agenda als Open Space durchgeführt wird. Alle Planungs-, Verbesserungs- und Teambuilding-Aktivitäten sollen selbstorganisiert in diesem Termin zur Diskussion gestellt, beschlossen und eingeleitet werden.

Vier Rollen

Angesichts des bisher zu erkennenden Minimalismus ist erstaunlich, dass es bei den Rollen sogar eine mehr gibt als in Scrum. Ein Product Director stellt im FAST-Meeting seine Vision für die nächste Iteration vor, aus der der Tribe selbstorganisiert seine Arbeit ableitet, ein pro Iteration gewählter Team- oder Feature Steward übernimmt in dieser Zeit die Koordination eines Themas, ein Tribe Coach hilft dabei zu verstehen wie die Methodik gemeint ist. Alle anderen Personen gelten einfach als Tribe Member, von denen jeder an mehreren Themengebieten arbeiten können sollte.

Vier Artefakte

Drei der vier Artefakte bilden mit möglichst geringem Detailgrad den Work Breakdown ab. Release Map (gross), Feature Tree (mittel), Iteration Board (klein, als einziges Artefakt optional). Das vierte bilden die so genannten Tribe Agreements, die aber nicht etwa bestimmte Beschlüsse und Regeln enthalten, sondern lediglich beschreiben wie diese möglichst unbürokratisch zu Stande kommen. Alle vier Artefakte können und sollen regelmässig selbstorganisiert geändert werden, ohne dass im Detail festgelegt ist wann das stattzufinden hat. Hauptsache Verbesserungen finden statt, egal wie.

Skalierung

Der Anspruch von FAST ist, dass es ohne zusätzliches Skalierungsframework funktioniert, bzw. sein eigenes Skalierungsframework ist. Tribes können dazu bis zur Dunbar-Zahl von 150 Mitgliedern anwachsen ohne dass zusätzliche Rollen und Meetings benötigt werden, lediglich das FAST-Meeting wird umfangreicher. Erst oberhalb der Dunbar-Zahl muss der Tribe in mehrere geteilt werden. Alternativ können FAST-Tribes in Skalierungsframeworks wie SAFe oder Flight Level-Kanban eingebettet werden, solange diese die internen Abläufe nicht verändern.

Aber: Ist das wirklich umsetzbar?

Ja, aber. Wie oben gesagt muss man sich FAST als ein Framework vorstellen das für Teams geeignet ist die Scrum gemeistert haben und jetzt einen Schritt auf die nächste Stufe machen wollen. Das bedeutet, dass sie Produkte haben die sich durch kleine, in wenigen Tagen umsetzbare Incremente erweitern lassen. Das bedeutet, dass sie die technische Exzellenz haben die für tägliche Produktionsdeployments nötig ist. Das bedeutet, das ihre Firma ihnen alle nötigen Freiheiten gibt. Und das bedeutet, dass ihre Mitglieder nah am Ideal des Fullstack-Developers sind, der nahezu jede nötige Arbeit erledigen kann.

Um ehrlich zu sein - nur wenige Teams dürften jemals den Entwicklungsgrad erreichen der für FAST nötig ist, nicht zuletzt weil nicht alle notwendigen Rahmenbedingungen selbst beeinflussbar sind. Aber vielleicht ist das auch gar nicht immer nötig - alleine der Versuch sich in diese Richtung zu entwickeln dürfte derartig viele positive Veränderungen bewirken, dass es den Aufwand bereits wert ist. FAST wäre damit weniger ein organisatorischer Rahmen und mehr ein guter Grund um ständig an Verbesserungen zu arbeiten. Aus "agiler Sicht" bereits mehr als ausreichend.