Scaled Agile Framework (SAFe): Ist es so perfekt?

Es scheint, dass es agile Softwareentwicklung schon immer gab. Tatsächlich wurde das Agile Manifest erst 2001 veröffentlicht. Die Agile-Bewegung hat ihre Ziele erreicht. Sie verlagerte das Machtverhältnis und die Verantwortung vom Management auf die Entwickler. Heute ist das Scaled Agile Framework (SAFe) ein Ansatz, Agile-Prinzipien in großem Maßstab anzuwenden. SAFe-Prinzipien mögen wie eine logische Erweiterung von Agile erscheinen. Dennoch wurde SAFe von langjährigen Agile-Praktizierenden wie Ken Schwaber kritisiert.

Die Kritiker von SAFe haben drei Haupteinwände gegen das Framework:

1. Schlechte Kompatibilität mit den Betriebs- und Support-Teams.
2. Erhöhte technische Verschuldung
3. Zuviel Vertrauen in die Normalisierung der Story-Points.

Dieser Artikel bietet einen Überblick über SAFe. Er erklärt die von den SAFe-Kritikern vorgebrachten Probleme und diskutiert die verfügbaren Lösungen. Außerdem wird die Anwendung von SAFe auf Portfolio- und Programmebene behandelt. Schließlich erfahren Sie, wie Sie mit Panayas Release Dynamix (RDx) to SAFe in Ihrem Unternehmen implementieren und einsetzen können.

Was ist SAFe

SAFe wendet die zwölf Punkte des Agile Manifests auf Unternehmensebene an.

Zu den zwölf Punkten gehören:

• Priorisierung der Kundenzufriedenheit durch kontinuierliches Bereitstellen von wertvoller Software.
• Die sich ändernden Anforderungen der Stakeholder.
• Arbeiten in kurzen, festen Zyklen.

Das Framework nimmt im Wesentlichen die wichtigsten Bestandteile auf, die in die Agile-Arbeit einfließen, und überträgt sie in neun neue Prinzipien:

1. Kennen Sie den wirtschaftlichen und geschäftlichen Wert eines Projekts.
2. Treffen Sie Entscheidungen mit einem systematischen Ansatz.
3. Planen Sie mögliche Änderungen mit ein.
4. Entwickeln Sie Produkte in kleinen Schritten.
5. Setzen Sie realistische Ziele und Termine.
6. Beschränken Sie Batches auf die kleinstmögliche Größe.
7. Arbeiten Sie mit konstanter Geschwindigkeit (Entwicklungszyklus).
8. Erkennen Sie die wahren Bedürfnisse der Stakeholder.
9. Dezentralisieren Sie den Entscheidungsprozess.

Aufbauend auf diesen Grundlagen wurde SAFe als ein effizientes Framework für die Entwicklung softwarebasierter Projekte in großen Unternehmen konzipiert. Erreicht wird dies durch die Zentralisierung der Gesamtsteuerung des Entwicklungsprozesses unter der Führungsstruktur des Unternehmens. So können große Unternehmen langfristig planen. Sie können ihre Bemühungen unternehmensweit synchronisieren und koordinieren. Sie können sich Ziele für die Produkteinführungszeiten setzen und erreichen.

Eine der besten Möglichkeiten, SAFe im Detail zu verstehen, ist es, sich anzusehen, wie es EdgeVerve Systems und Fitbit geholfen hat.

EdgeVerve Systems konnte innerhalb eines Jahres nach der Einführung von SAFe wesentliche Verbesserungen verzeichnen. Bei kleinen und großen Produkten konnte die Produktreleasezeit auf drei bzw. sechs Monate verkürzt werden. SAFe half EdgeVerve, Fehler früher im Produktentwicklungszyklus zu erkennen und zu beheben. Dies führte zu weniger Fehlern in ihren Software-Releases und zu einer höheren Kundenzufriedenheit.

Fitbit implementierte SAFe ebenfalls erfolgreich und sorgte damit für nahtlose Workflows in ihrem gesamten Hard- und Software-Ökosystem. Fitbit konnte mehrere Teams koordinieren. Dies trug dazu bei, einen schnellen und flexiblen Entwicklungs- und Release-Prozess zu gewährleisten. Es stellte Mechanismen zur Verfügung, um komplexe Sachverhalte teamübergreifend zu bearbeiten. Durch den Einsatz des Scaled Agile Frameworks konnte Fitbit an allen Fronten Verbesserungen erzielen:

• Task-Backlogs
• Teamübergreifende Programmabhängigkeiten
• Security
• Compliance
• Marketing

SAFe: Probleme & Lösungen

Wenn wir SAFe als „noch Agile, nur größer“ zusammenfassen, warum sind dann viele Agile-Entwickler ihm gegenüber so kritisch? Um das zu verstehen, lassen Sie uns einen weiteren Blick auf die drei Punkte werfen, die wir vorhin angesprochen haben.

Schlechte Kompatibilität mit Betrieb und Support

Die Agile-Entwicklung wurde von Entwicklern geschaffen. Sie wurde konzipiert, um viele der Probleme, die sie mit Wasserfallprozessen hatten, zu lösen. Agile und Wasserfall können sich in der Handhabung der Projektplanung unterscheiden. Beide Ansätze beruhen jedoch auf einer zeitlichen Planung. So funktionieren die Unternehmens-IT, der Betrieb und der Support jedoch nicht. Ihr Fokus liegt auf der tagesaktuellen Erledigung von Aufgaben.

Zu den operativen Arbeiten gehören häufig die Bewältigung von Routine- und geplanten Aufgaben. Dabei geht es um den Umgang mit unerwarteten Ereignissen und die gleichzeitige Bearbeitung mehrerer Projekte. Die Zeit ist begrenzt und reicht kaum für den Umfang der Releaseplanung, den Agile benötigt.

Der Support kann einen Vertreter zu einem Release-Planungstreffen schicken. Allerdings sind sie in der Regel nicht bereit oder nicht in der Lage, sich einzubringen. Noch wichtiger ist, dass sie keine Kontrolle über ihren Aufgaben-Backlog haben. Wenn sie die hätten, würden sich die von ihnen unterstützten Anwender höchstwahrscheinlich sehr aufregen. Im Gegensatz zu Entwicklern, die ihren eigenen Terminplan verwalten können, wird von den Supportmitarbeitern außerdem erwartet, dass sie eine kontinuierliche Abdeckung leisten, oft 24 Stunden am Tag, sieben Tage die Woche.

Die SAFe-Lösung

Ziehen Sie DevOps als Lösung in Betracht. DevOps ist ein Ansatz, der die Entwicklung mit dem Betrieb verbindet, indem er allgemeine operative Aufgaben mittels geschriebenem Code automatisiert. Zu den DevOps-Verfahren gehören Testautomatisierung, verteilte Versionskontrolle und Continuous Integration, Delivery und Deployment.

Erhöhte technische Verschuldung

Technische Schulden gehören zu den schwer bestimmbaren Dingen. Doch die meisten von uns erkennen sie, wenn wir sie sehen. Im Rahmen dieses Artikels definieren wir es als den kumulierten Aufbau ungelöster Probleme während der Laufzeit eines Projekts. Die meisten Menschen gehen mit schwierigen Situationen um, indem sie versuchen, schwierige Entscheidungen so lange wie möglich hinauszuzögern. Die Bewältigung der technischen Schuldenlast eines einzelnen Projekts ist ein ständiger Kampf. Wenn das Team sich des Problems jedoch bewusst ist, kann es durch gemeinsames Handeln angegangen werden.

In einer SAFe-Umgebung ist die Verantwortung für die Bewältigung der technischen Schulden im Management der Organisation zentralisiert. Diese Zentralisierung kann für bestimmte Arten von technischen Schulden sehr vorteilhaft sein. Dazu gehören Schulden, die sich aus dem Druck der Kunden/Märkte oder der Unternehmenspolitik in Bezug auf Zeit, Ressourcen und Budgetallokation ergeben. Diese Arten von Schulden können durch einen Top-Down-Ansatz bewältigt werden.

Die Zentralisierung ist jedoch kein guter Ansatz für technische Schulden, die auf Teamebene entstehen. Diese Art von Schulden hat sehr spezifische Ursachen. Zum Beispiel Entwicklerteams, die die langfristigen Folgen kurzfristiger Entscheidungen nicht verstehen. Diese Art von Schulden entsteht auch in unbeständigen Teams, in denen es eine hohe Fluktuationsrate gibt. Das Management der Organisation muss eine aktive Rolle bei der Bearbeitung lokaler technischer Schulden übernehmen. Andernfalls entsteht ein größeres und hartnäckigeres Schuldenproblem, das mit der Zeit mehr Schäden verursacht.

Die SAFe-Lösung

Der beste Weg, mit dieser Art von technischen Schulden umzugehen, ist die Befolgung agiler Prinzipien. Delegieren Sie beispielsweise Entscheidungen zur Problemlösung an die Teams, die die Software entwickeln und testen. Geben Sie diesen Teams die Möglichkeit, ihre eigenen Termine festzulegen und ihre Outputgeschwindigkeit zu messen. Sie werden sich für ihre Arbeit verantwortlich fühlen und in der Lage sein, mit Problemen umzugehen, wenn sie auftreten. Es sollte eine Kultur der Ehrlichkeit und Offenheit geschaffen werden, die den Einzelnen ermutigt, technische Schulden und damit zusammenhängende Probleme zu identifizieren, zu bewerten und zu beheben.

Das Management kann eine wichtige Rolle im Umgang mit technischen Schulden spielen. Zum Beispiel durch das Schreiben von standardisierten Akzeptanz- und Ausstiegskriterien. Das Management sollte eine klare Definition von „erledigt“ liefern, die in allen Projekten einheitlich angewendet wird. Das Management sollte außerdem Daten von einzelnen Teams aggregieren und Online-Systeme einrichten, die diese Daten für alle sichtbar machen.

Normalisierung von Story-Points

Zu schätzen, wie lange es dauert, eine einzelne Aufgabe zu erledigen, ist ein Problem, das nie gelöst wurde. Die herkömmliche Lösung bestand darin, die Anzahl der Manntage für die Implementierung einer einzelnen User Story zu berechnen. Ein Projektleiter könnte schätzen, dass der Aufwand für die Implementierung einer User Story ein Manntag ist. Beachten Sie, dass die Anzahl der Manntage den absoluten Aufwand für die Ausführung der Aufgabe angibt. Mit anderen Worten, der Projektleiter könnte zwei Entwickler beauftragen und die Aufgabe in der Hälfte der Zeit erledigen, aber der Gesamtaufwand bleibt ein Manntag./span>

Eine häufige Kritik an der aufwandsbasierten Schätzung ist, dass sie die Komplexität oder Schwierigkeit der Ausführung einer Aufgabe nicht berücksichtigt. Stattdessen hat die Agile-Welt (einschließlich SAFe) Story-Points übernommen.

Ein Story-Point ist ein Maß für den Aufwand, eine einzelne User-Story zu implementieren, welches zusätzliche Faktoren berücksichtigt. Zum Beispiel Aufwand, Schwierigkeit, Komplexität und Risiken. Story-Points werden als Wert auf einer abstrakten Skala ausgedrückt, wie z. B. eine Zahlenfolge, T-Shirt-Größen (Small, Medium, Large usw.) oder die Fibonacci-Sequenz. Beispielsweise können Sie eine Skala von 1 (leicht) bis 5 (schwierig) verwenden, wobei jede Zahl in einen Manntag Aufwand umgerechnet wird. Eine Aufgabe, die einen Manntag in Anspruch nimmt, ist also gleichbedeutend mit einem Story-Point.

In einer SAFe-Umgebung werden die entscheidenden Story-Points in die Hände des Managements gelegt. Dadurch wird die Skala, mit der der Aufwand gemessen wird, abstrakter und im Grunde nutzlos. Außerdem haben die einzelnen Teams das Gefühl, dass sie keine Kontrolle oder Verantwortung über den Entwicklungsprozess haben.

Die SAFe-Lösung

Eine der wichtigsten Lösungen ist es, den Entwicklungsteams die erforderliche Autonomie zu geben. Dazu gehört, dass man ihnen die Autorität und das Vertrauen einräumt, ihre eigenen Kennzahlen zu bestimmen. Entwicklungsteams sollten in der Lage sein, ihr Handeln selbst zu steuern. Das Management sollte die Teams zudem darüber aufklären, wie Geschwindigkeit als Leitfaden und nicht als Maß für Produktivität und Erfolg verwendet werden sollte. Auch hier kann das Management wieder eine wichtige Rolle spielen, indem es die Mitarbeiter in modernen, Agile-Projektmanagement-Verfahren weiterbildet und schult.

Implementierung von SAFe auf Portfolioebene

Im Rahmen des SAFe-Frameworks kann das Management auf Portfolioebene die Ausrichtung der Unternehmensstrategie auf die Portfolio-Ausführung überprüfen. Dies wird durch die Schaffung klarer Wertströme erreicht, die das Verständnis der Investitionen in die jeweiligen Initiativen erleichtern.

Auf der SAFe-Portfolioebene werden die Teams und Prozesse dargestellt, die erforderlich sind, um Lösungen zu entwickeln, die das Unternehmen zur Erreichung seiner strategischen Ziele benötigt. Es können mehrere SAFe-Portfolios in einem Unternehmen existieren.

Jedes SAFe-Portfolio umreißt sowohl die strategischen Themen für das Portfolio, die es durch sich ändernde Geschäftsziele führen, als auch einen konstanten Fluss von Rückmeldungen aus dem Portfolio an die Stakeholder des Unternehmens. Dies schließt ein:

• Der aktuelle Stand der Lösungs-Wertstrom-KPIs des Portfolios
• Qualitative Beurteilung der Zweckmäßigkeit der aktuellen Lösung

Durch die Bereitstellung der grundlegenden Budgetierung und der notwendigen Governance-Mechanismen kann das Management sicherstellen, dass Investitionen in Lösungen den Return on Investment (ROI) liefern, den das Unternehmen benötigt, um seine strategischen Ziele zu erreichen.

Implementierung von SAFe auf Programmebene

Auf der Programmebene stellt das Management Entwicklungsteams, Business User und andere Ressourcen für eine kontinuierliche Lösungsentwicklung zur Verfügung. Alle Ressourcen, die einem einzigen Programm zugeordnet sind, werden im Agile Release Train (ART) ausgewiesen. Ein ART umfasst auch die Teams, Rollen und Aktivitäten auf Programmebene, die schrittweise einen kontinuierlichen Wertfluss liefern. In der Regel hat ein Programm ein festes Start- und Enddatum sowie temporär zugeordnete Ressourcen.

ARTs sind jedoch langlebig und haben daher eine beständigere Selbstorganisation, Struktur und Mission als ein klassisches Programm. ARTs sind virtuelle Organisationen, die gegründet wurden, um unnötige Übergaben und Schritte zu vermeiden. Sie beschleunigen die Wertschöpfung durch die Implementierung von SAFe-Praktiken.

Fazit: So funktioniert SAFe

Die agile Entwicklung begann als Basisinitiative von Entwicklern für Entwickler. Ein Grund für die schnelle Verbreitung war, dass sie die Entscheidungsfindung dezentralisierte und den Entwicklern die Autonomie gab, Entscheidungen zu treffen und auf sinnvolle Weise danach zu handeln.

SAFe ist ein Ansatz, von der Agile-Bewegung zu lernen. Optimieren Sie Projektmanagement, Koordination und Entscheidungsfindung, indem Sie diese zentralisieren. Einer der vielen Vorteile von SAFe ist der Einsatz des Wertstrommanagements, wodurch ein tiefes Verständnis für den Wert dessen, was entwickelt werden soll sowie für das Timing hinter jedem Release ermöglicht wird.

Egal wie Sie die Anforderungen von Agile und SAFe in Einklang bringen, Panayas Release Dynamix (RDx) bietet die Tools, um Ihre Agile- und SAFe-Deployments zu unterstützen und sie zum Laufen zu bringen. Im Gegensatz zu anderen Release-Management-Produkten wurde RDx von Grund auf neu entwickelt, um umfangreiche agile Bereitstellungen von Unternehmensanwendungen zu managen. Sie können damit den gesamten Entwicklungsprozess überwachen und Ihr Portfolio, Projekt- und Release-Train, Value-Trains, Anforderungen, Tests und Risiken verwalten. Es sammelt zudem Daten und zeigt Kennzahlen und Dashboards an. RDx liefert Berichte, die Ihnen wichtige Erkenntnisse und Analysen liefern.

Wie bei vielen vorgegebenen Frameworks ergeben sich auch bei SAFe viele Probleme aus dem Versuch, es zu starr anzuwenden und nicht an die Bedürfnisse einer bestimmten Organisation anzupassen. Letztendlich ist es wichtiger, die richtige Lösung für die jeweilige Aufgabe zu finden, als sich an die Prinzipien einer einzelnen Methode zu halten.

Panayas Release Dynamix (RDx) kann Ihnen helfen, die Elemente von sowohl Agile als auch SAFe zu implementieren, die den Zwecken und Zielen Ihrer spezifischen Aufgabe am besten dienen, sei es auf Programmebene, auf Projektebene oder auf Portfolioebene.