Agile Skalierung mit SAFe® 5.0 - Warum und was ist skaliertes Vorgehen?

Agile & Scrum

Ich möchte in diesem Beitrag Informationen über ein Framework für skaliertes Vorgehen aus der agilen Welt mit Euch teilen. Natürlich ist es auch ein Teaser für die „Agile Welt“ ;-)

Warum skaliertes Vorgehen?

Die meisten werden Scrum kennen oder zumindest schon davon gehört haben. Es geht an sich um ein Team aus Entwicklern, dem Product Owner und dem ScrumMaster, die nach den Regeln des Scrum Guide zusätzlich basierend auf den 4 Werten und 12 Prinzipien des Agilen Manifests mit bestimmten Artefakten und festgelegten Meetings in einem zyklischen Ablauf – den Sprints – zusammenarbeiten.

Soweit ist dies den meisten bekannt - allerdings: Was, wenn die Aufgabe für ein kleines Team zu groß ist? Max. 9 Entwicklerinnen/Entwickler besitzt ein Scrum Team. Was wenn über 100 Personen oder 500+ Personen an einem System arbeiten müssten? Wie sollen solche großen Gruppen agil zusammenarbeiten, sodass am Ende die einzelnen Teile ineinandergreifen und ein funktionierendes System entsteht?

Skalierungs Frameworks

Für die Umsetzung großer Aufgabenstellungen, die die Kapazität eines Teams überfordern, ist eine Skalierung notwendig. Hierfür existieren verschiedene Skalierungs Frameworks (Organisatorische Blaupausen).

In diesem Artikel möchte ich auf SAFe®, das weltweit führende Framework für Business Agility, welches von © Scaled Agile, Inc. bereitgestellt wird, eingehen.

SAFe® 5.0 Überblick

Bei SAFe® handelt es sich um ein Skalierungs Framework mit einem gesamtheitlichen Ansatz, das unter den Begriffen „Business Agility“ und „Lean“ alle Aspekte des agilen Betriebs einer Unternehmung berücksichtigt.

Zur Erreichung von Business Agility sind je nach Einsatz (Umfang der Unternehmung) die Kenntnisse und Fähigkeiten von bis 7 Kernkompetenzen notwendig. Jede dieser Kernkompetenzen besteht wiederum aus jeweils drei Dimensionen, die notwendige Wissensgebiete, Vorgehensweisen, Grundsätze und Verhaltensweisen definieren.

SAFe® nutzt ein Fundament aus vier Core Values, der Notwendigkeit eines Lean Agile Mindset (auf Basis der „House of Lean“ Metapher) plus der 10 SAFe® Lean agile Prinzipien und stellt damit solides Wissen und Leitblanken zur Verfügung, die als Maßstab und Kriterien bei vielerlei zu treffenden Entscheidungen zu spezifischem Vorgehen in einer konkreten gegebenen Situation, dienen können.

Begeistert bin ich von der SAFe® Implementation Roadmap, die basierend auf anerkannten Erkenntnissen des Changemanagements, eine funktionierende transparente Starthilfe für die Transformation bietet.

SAFe® stellt Blaupausen für verschiedene Größen von Skalierungen bereit, diese lauten (von klein nach groß in aufsteigender Reihe):

  • Essential SAFe
  • Large Solution SAFe
  • Portfolio SAFe
  • Full SAFe

Die kleinste Einheit, Essential SAFe®, kann typischerweise aus 50 – 125 Mitarbeiterinnen/Mitarbeitern bestehen, gebildet wird es um einen Wertstrom, d.h. alles was zum Wertzuwachs eines z.B. zu entwickelnden Systems beiträgt, soll in einen Agile Release Train (ART) aufgenommen werden. D.h. mit der Einführung von SAFe® muss sinnvollerweise eine Organisationsänderung einhergehen. Einer der Leitsätze bei SAFe® lautet: Am Anfang steht eine Organisationsänderung, die Kulturänderung wird folgen.

Vorgehensweise in einem Agile Release Train

Es gibt mehrere Scrum Teams, die parallel an der Bearbeitung von Features tätig sind. Welche Features relevant sind, wird mittels Kanban Board von den Business Ownern und dem Produktmanagement priorisiert. Die zehn wichtigsten Features gelangen jeweils in die Program Increment Planning Sessions.

Diese Planning Meetings erstrecken sich über jeweils zwei Tage und alle Beteiligten sind an beiden Tage anwesend, arbeiten zusammen, prüfen und ändern ggf. die Planung.  Am Ende sollen der Inhalt (Program Objectives), die Aufteilung der Features unter den Scrum Teams, die Abhängigkeiten der Features untereinander, die für jedes Feature heruntergebrochenen Userstories, die Risiken, der Business Value, ... für die nächsten 5 Sprints des ART feststehen. Man nennt diesen Zeitraum das Programm Inkrement (PI). Typischerweise beträgt das PI - 5 Sprints (10 Wochen).   

Nach der initialen Planung erarbeiten die Teams im Scrum Modus in 2 Wochen Sprints ihre Userstories, dabei wird möglichst jeden Tag der Entwicklungsstand integriert, automatisch getestet und möglichst - mindestens auf eine Staging Umgebung - bereitgestellt. Nach jedem Sprint findet eine System Demo statt, die das Zusammenspiel und den Fortschritt der Entwicklung zeigt. Der letzte Sprint des Programm Inkrements besitzt eine besondere Bedeutung. Er nennt sich Innovation and Planning Iteration (IP). Dieser IP Sprint soll in der ersten Sprint Woche erlauben, dass die Teams tatsächlich Neues, bzgl. der in den letzten vier Sprints erarbeiteten Lösungen, ausprobieren können (Innovation). Der IP Sprint dient weiterhin dem Zweck eines Puffers, um das hohe Gut einer hohen Liefertreue gewährleisten zu können.

In der zweiten Sprint Woche des IP Sprints erfolgt ein Inspect and Adapt Workshop, in dem ähnlich der System Demo das gesamte System vorgestellt wird und die Business Owner Feedback zum erreichten Business Value geben.

Artefakte und Rollen bei SAFe®

Die üblichen Scrum Rollen und Artefakte existieren auch in SAFe®; daher möchte ich diese hier nicht mehr erwähnen. Neu sind:

  • Enabler
    Sie entsprechen Features, adressieren jedoch den Architectual Runway, der in seiner Gesamtheit der Menge aller technischen Komponenten des Systems oder auch NFAs, als Voraussetzungen für fachliche Funktion, entspricht. Business Features konsumieren den Architectual Runway.
  • System Architekt
    Diese Rolle sorgt für einen in sich konsistenten Architectuel Runway und achtet darauf, dass dieser sich im Laufe der Zeit an neue Herausforderungen anpasst.
  • Release Train Engineer (RTE)
    Er ist der übergeordnete Scrum Master, der die Durchführung der Planningsmeetings verantwortet, die Metriken mitbestimmt, die den Reifegrad der SAFe® Implementierung oder des Programms zeigen. Er führt die Scrum of Scrum Meetings (SM und PO) durch, in dem sich die einzelnen Teams zwischen den Sprints synchronisieren.
  • System Team
    Das System Team unterstütz die Entwicklung des Produktes und die Teams bei der Einrichtung und Nutzung von Repositories, Programmier-Tools, Tools zur Integration und dem DevOps Vorgehen etc.

Wo können Sie mehr zu SAFe® lernen?

„Eine Investition in Wissen bringt immer noch die besten Zinsen“, sagte Benjamin Franklin (amerikanischer Politiker und Wissenschaftler 1706 - 1790), Führungskräfte, die ein Steuerungssystem für die Zusammenarbeit von mehreren agilen Teams benötigen, sollten sich weiterbilden. Genau hier bietet die Scaled Agile, Inc. (USA) mit ihrem Scaled Agile Framework SAFe®, das bisher am weitesten ausgereifte Framework für skalierte Agilität an.

Ich mache Ihre Mitarbeiter fit für SAFe®: >> SAFe® 5.0 Training 

Lernen Sie in diesem 2-tägigen SAFe® Training, die sieben Kernkompetenzen für schlanke Unternehmen kennen. Erkennen Sie die Notwendigkeit und Wirkung der zugrundeliegenden Prinzipien. Lernen Sie die konkreten Vorgehensweisen des Scaled Agile Framework® zur Erreichung von Business Agility und lassen Sie sich in die Lage versetzen eine Agile Transformation zu steuern.

 

Hinweise:

Dieser Artikel will einen ersten Überblick auf SAFe® liefern und erhebt daher keinen Anspruch auf Vollständigkeit. Der Leser sei für weitere Details zu SAFe® an © Scaled Agile, Inc. dem Bereitsteller von SAFe® verwiesen.

Der Autor ist Associate Partner der Proventa AG, SAFe® Program Consultant (SPC) und bietet das SAFe® Training „Leading SAFe“ an.

Die in diesem Artikel verwendeten Markenzeichen ® sind Eigentum der jeweiligen Markeninhaber.

Eckhard Ernst Autor

Eckhard Ernst hat nach seinem E-Technik Studium viele Jahre selbst Software entwickelt und war ua. für ein weltweit tätiges Technologie Unternehmen im Consulting tätig. Umfangreiche Erfahrung in klassischer IT- Projektleitung und Projektmanagement zeichnen ihn aus. Er verfügt über eine vielschichtige IT-Erfahrung und kann sagen, dass es kaum einen Aspekt der Software- oder Systementwicklung, in Firmen oder IT Großprojekten gibt, mit dem er nicht schon persönlich in Berührung gekommen ist. Agile Vorgehensweisen lernte er Anfang der 2000er Jahre mit „Rapid Application Development“ kennen. Während seiner Einsätze als Scrum Master und Agile Coach in großen Kunden/Projektorganisationen hat er das Potential von SAFe ® erkannt und ist heute als SAFe ® Programm Consultant für anspruchsvolle Aufgaben im skalierten Umfeld tätig.

Tags