Mit dem Scaled Agile Framework (SAFe) Agilität auf der Programmebene etablieren

ONEPOINT Projects

In Entwicklungsprojekten ist agiles Vorgehen nicht mehr wegzudenken. In die übergeordneten Planungs- und Steuerungsebenen sind agile Projekte meist über Schnittstellen integriert. Das wollen vor allem große Unternehmen nun ändern. Mit dem Scaled Agile Framework (SAFe) bringen sie die wesentlichen Erfolgsfaktoren der Agilität beim Umgang mit Unsicherheit nun direkt auf die Programmebene. Was diesen Ansatz ausmacht und wie er funktioniert, das beschreibt Gerald Aquila, Geschäftsführer des PM-Lösungsanbieters ONEPOINT Projects im folgenden Interview.

Herunterladen Download

Mit dem Scaled Agile Framework (SAFe) Agilität auf der Programmebene etablieren

ONEPOINT Projects

In Entwicklungsprojekten ist agiles Vorgehen nicht mehr wegzudenken. In die übergeordneten Planungs- und Steuerungsebenen sind agile Projekte meist über Schnittstellen integriert. Das wollen vor allem große Unternehmen nun ändern. Mit dem Scaled Agile Framework (SAFe) bringen sie die wesentlichen Erfolgsfaktoren der Agilität beim Umgang mit Unsicherheit nun direkt auf die Programmebene. Was diesen Ansatz ausmacht und wie er funktioniert, das beschreibt Gerald Aquila, Geschäftsführer des PM-Lösungsanbieters ONEPOINT Projects im folgenden Interview.

Herr Aquila, das Kürzel „SAFe“ erscheint immer häufiger auf Projektmanagement-Seiten, meist verbunden mit den Attributen „neu“ und „agil“. Es ist aber gar nicht so einfach zu verstehen, was genau sich dahinter verbirgt. Sie und Ihr Team haben sich intensiv mit diesem Ansatz beschäftigt und jetzt angekündigt, ihn im nächsten Software-Release von ONEPOINT Projects zu integrieren. Können Sie uns SAFe erklären?

SAFe zu verstehen ist tatsächlich nicht ganz einfach. Es ist zunächst ein Ansatz für agiles Vorgehen bei komplexen Entwicklungen, für die man mit einem agilen Team oder auch zwei oder drei nicht auskommt. Doch es gibt auch eine klare Abgrenzung zum agilen Projektmanagement. Dazu gehört, dass man hier nicht in Projekten mit festem Terminplan und Budget denkt, sondern in Prozessen, die kein definiertes Ende haben. Im Fokus stehen Ergebnisse wie Produkte oder Services, die das Unternehmen immer weiterentwickeln und weiter verkaufen will. SAFe ist damit keine neue Projektmanagement-Methode, sondern ein Prozessmanagement-Modell ohne Endtermin. Aber es stützt sich auf die gleichen agilen Erfolgsfaktoren.

Program Increments und Agile Release Trains

Welche konkreten agilen Ansätze bietet SAFe?

Lassen Sie mich beginnen mit den Begriffen beziehungsweise Elementen „Program Increment“ und „Agile Release Train“. Program Increments verknüpfen Sprints zu größeren Einheiten, die meist aus fünf Sprints bestehen und insgesamt acht bis zwölf Wochen umfassen. Dabei werden in der Regel die ersten vier Sprints aktiv geplant, der fünfte dient als eine Art Puffer. So lässt sich ein Program Increment also grob mit einer Phase im klassischen Projektmanagement vergleichen. Der Agile Release Train ist das Kernelement von SAFe. Zu ihm gehören sowohl mehrere agile Teams wie auch mehrere Program Increments. Es ist somit ein Programm mit festen Phasenlängen, aber ohne Ende – ein Schnellzug, der immer weiterfährt.

Wird dabei auch mit User Stories gearbeitet?

Auf Teamebene wird nach wie vor mit agilen User Stories gearbeitet. Auf SAFe-Ebene geht es im Grunde um das, was man in Scrum unter Epics versteht, also die Zusammenfassung von mehreren Stories. SAFe spricht hier von Features, denn das passt besser zu den gängigen Größen, mit denen auf Programmebene gearbeitet wird. Das ist das wirklich Coole an SAFe: Man bringt die Vorteile der Agilität auf die Programmebene und verknüpft sie dort mit anderen Vorgehensweisen. Zugleich ist diese SAFe-Ebene nahtlos mit den Scrum-Projekten der Teams integriert.

Typische agile Planungsansätze und Kennzahlen in SAFe

Das klingt spannend! Wie lässt sich der SAFe-Ansatz auf Programmebene denn konkret in die Software einbauen?

Wir bei ONEPOINT Projects haben SAFe in ein umfassendes SAFe Modul – wir sprechen von der „Enterprise Agile Option“ – integriert. Das neue Release geht voraussichtlich im Januar 2022 live. Nutzerinnen und Nutzer können dann mit der SAFe Implementierung direkt auf Portfolio-Ebene einen Agil Release Train anlegen und die Program Increments planen. Dabei werden diese Elemente automatisch mit den Stories darunter verknüpft. All die Möglichkeiten, die ONEPOINT Projects bietet, gibt es auch auf der SAFe-Ebene, etwa zahlenbasierte Kostenplanung und Ressourcenplanung oder Controllinginstrumente wie Soll-Ist-Vergleiche. Daten werden automatisch auf die nächsthöhere Ebene aggregiert.

Steht auch bei SAFe die „Velocity“ im Fokus?

Ja, die für agiles Vorgehen elementare Größe Geschwindigkeit wird auf Ebene des Agile Release Trains automatisch berechnet. Die Möglichkeit zum Einschätzen beziehungsweise Qualifizieren von Komplexität und Aufwand – Stichwort Story Points – ist hier ebenfalls vorhanden. Das agile Risikomanagement erfährt durch SAFe übrigens noch mal eine Aufwertung. Es wird für die Ebene des Agile Release Trains ausdrücklich empfohlen, das abgestufte Vorgehen dafür ist sehr genau definiert. Was die Schnittstellen betrifft, so ist die SAFe-Ebene über die Teams mit JIRA und SAP verknüpft und kann Kennzahlen aus diesen Systemen aggregieren. Damit konnten wir beide Forderungen von Kundenseite umsetzen: Volle Unterstützung von Essential SAFe plus Integration der klassischen, der hybriden und der agilen Vorgehensweisen und Kennzahlen.

Für welche Unternehmen und Projekte SAFe wirklich passt

Wofür steht „Essential SAFe“?

Da kommen wir zu dem „S“ in der Abkürzung SAFe, das ja für „Scaled“ steht. Das bezieht sich auf  den Aspekt des modulares Frameworks, das in unterschiedlichen Konfigurationen oder Stufen eingesetzt werden kann. Die erste Stufe „Essential“ steht für die Anwendung von SAFe auf Ebene des Agile Release Trains und ist zugleich die Grundlage für noch weitergehende SAFe -Konfigurationen. Diese binden neben der Programmebene die Portfolioebene ein, eine weitere „Large-Solution-Ebene oder in der Ausbaustufe „Full“ das gesamte Unternehmen.

Wo sehen Sie die Grenzen von SAFe in der Projektlandschaft? Wofür ist es gut geeignet und wofür weniger?

Das ist eine wichtige Frage, denn zumindest das Essential SAFe erlebt derzeit einen Hype auch für Umgebungen, für die es weniger gut passt. Generell gelten die gleichen Punkte wie für agiles Projektmanagement: Hohe Unsicherheit spricht eher dafür. Harte Termine, viele terminliche Abhängigkeiten und fixe Ressourcenzuteilungen sprechen dagegen. Die SAFe-Gründer definierten SAFe für Vorhaben, bei denen mehr als 100 Entwicklerinnen und Entwickler zusammenarbeiten bis hin zu mehreren Hundert oder Tausend – Größenordnungen, die mit agilen Tools wie Scrum nicht mehr zu handhaben sind.

Ist SAFe nach Ihrer Erfahrung denn bereits in den Unternehmen angekommen?

In den USA ist SAFe schon lange ein Thema, nicht zuletzt bei den großen Tech-Konzernen. Aber auch im deutschsprachigen Raum ist es angekommen, vor allem bei großen Unternehmen, etwa in der Automobilbranche. Sie sehen in SAFe eine gute Chance, wichtige Entwicklungsprozesse zu optimieren und Vorteile herauszuholen. Wir bei ONEPOINT Projects haben uns dazu entschlossen, bei unserer eigenen Produktentwicklung mit SAFe zu arbeiten, obwohl wir eigentlich nicht die typische Größe erreichen – eine durchwegs positive Erfahrung. Auch als wir vor einigen Wochen ein Webinar zum Thema SAFe angeboten haben, überstieg das Interesse unsere Erwartungen bei Weitem.

Wenn sich ein Unternehmen für SAFe interessiert, was sollte es für eine erfolgreiche Einführung beachten?

Wichtig ist aus unserer Sicht, dass SAFe wirklich verstanden wird und das Unternehmen sehr sorgfältig prüft, ob dieser Ansatz zu den eigenen Prozessen passt und wenn ja wo. Für die eigentliche Implementierung ist es zum einen sehr wichtig, den jeweiligen Agile Release Train gut zu definieren und sauber aufzusetzen. Zum anderen ist sicherzustellen, dass die erforderlichen Rollen gut verstanden und besetzt sind, allen voran die Funktion des Release Train Engineer, in etwa vergleichbar mit dem agilen Scrum Master. Dazu gelten die Regeln für gutes Change Management: Alle Beteiligten, vor allem die Führungskräfte und andere Multiplikatoren wie Change Agents, müssen das Wie und Warum verstehen. Die Umsetzungsebene muss eine gute Vorbereitung erhalten und vor allem in der Einführungsphase wissen, wo sie Antworten bei Fragen und Unterstützung bei Problemen erhält.

Herr Aquila, herzlichen Dank für das Gespräch.

Das Interview führte Elisabeth Wagner.

Herunterladen Download

Jetzt Feedback geben und mitdiskutieren!

Wir würden uns über Ihre Bewertung und/oder einen Kommentar freuen ‒ nur so können wir Ihnen in Zukunft noch bessere Inhalte liefern.

Diese Funktion steht nur eingeloggten Nutzern zur Verfügung.
0 Kommentare anzeigen & selbst mitreden!
Gesamt
Bewertungen 1
Kommentare 0