Vorsicht vor SAFe (dem skalierten agilen Framework für Unternehmen), einer unheiligen Inkarnation der Dunkelheit

… oder vielleicht auch nicht.

Wenn Sie lieber SAFe für sich selbst sprechen möchten, können Sie es verwenden der Link oben. Es gibt Hunderte von Dokumentationsseiten, stundenlange Videos, 15 verschiedene Schulungen und mehr. Wenn das ein bisschen viel klingt, werde ich mein Bestes geben, um zu erklären, wie SAFe funktioniert, wenn ich jeden Punkt durchlaufe.

Auf der höchsten Ebene, dem „Portfolio“, befürwortet SAFe Finanzierung unbestimmter „Wertströme“ – die normalerweise ein Produkt, eine Produktlinie oder einen Kundentyp darstellen. Die Lean Portfolio Management-Funktion (LPM), die die Finanzierung steuert (wahrscheinlich dieselben Personen, die zuvor für Projektbudgets im Wasserfallstil verantwortlich waren), hat jedoch die alleinige Befugnis, zu genehmigen, welche Portfolio-Epen (große Initiativen) in die einzelnen Streams verschoben werden. Epen sind keine Erklärungen für ein Problem, das gelöst werden muss. Es handelt sich um vorgefertigte Ideen, wie diese Probleme am besten gelöst werden können.

Auf Anhieb sehen wir Anzeichen für die Denkweise der alten Schule, Teams als „Zustellungsfunktion“ statt als strategische Funktion zu betrachten Level-Denker kommen auf Ideen, und die Low-Level-Macher setzen diese Ideen um. Ignoriert wird die Möglichkeit, dass diejenigen, die der Arbeit am nächsten stehen, am besten gerüstet sind, um Entscheidungen darüber zu treffen. Es ist ein Kernziel des agilen Denkens, dieser fehlgeleiteten Denkweise zu entkommen SAFe kann nicht aus der Ferne ausgeführt werden.

Ein ähnliches Problem tritt erneut auf, wenn wir uns eine etwas niedrigere Ebene ansehen.

SAFe sammelt kleine Produktteams (häufig Scrum-Teams) in „Agile Release Trains“ ”- Gruppen von Teams mit einer zusätzlichen Ebene von Managementrollen, die sich über jede Gruppe auf der sogenannten“ Programmebene „erstrecken.

Im Allgemeinen behindern diese Rollen die Autonomie von Teams. Sie erhöhen den Prozess- und Kommunikationsaufwand überproportional mit dem Wert, den sie bereitstellen.

Diese Rollen umfassen einen Produktmanager (PM), einen S. ystem Architect (SA) und ein Release Train Engineer (RTE).

Die SA und PM definieren und trennen größere Arbeiten (häufig aus dem obigen Portfolio-Prozess geerbt) und übergeben die Teile dann an die Teams.

Der Product Owner und das Team sind möglicherweise theoretisch in der Lage, andere, kleinere Arbeiten gegenüber den ihnen auferlegten Arbeiten zu priorisieren, aber diese Bemühungen haben eine eingeschränkte Sichtbarkeit und ein begrenztes Buy-In von oben. Es wird einen natürlichen Druck geben, die Arbeit vom höchsten Punkt als am wichtigsten zu behandeln – selbst wenn jedes einzelne Teammitglied glaubt, dass andere Dinge wertvoller wären. Aus diesem Grund beschränkt sich die Rolle des Product Owners darauf, Geschichten zu schreiben und Akzeptanzkriterien zu überprüfen, anstatt der einzige Verantwortungspunkt für die Produktführung zu sein, der ursprünglich für die Rolle vorgesehen war.

Der Systemarchitekt ist nicht in der Lage, der tatsächlichen Ingenieurarbeit nahe zu sein, so dass der von ihnen weitergegebene Architekturplan möglicherweise von der Realität der Arbeit getrennt wird. Diese Art von Rollen waren ein Markenzeichen für große Wasserfallprojekte im Vorfeld und sind in SAFe gut erhalten.

Release Train Engineers definieren konsistente teamübergreifende Prozesse und Trittfrequenz und erledigen viele betriebliche Aufgaben. Letztendlich bleibt den einzelnen Teams weniger Raum, um ihre eigenen Praktiken in einer Weise zu modifizieren, zu verbessern oder zu experimentieren, die von den festgelegten Standards abweicht.

Manchmal werden alle diese Probleme durch Hinzufügen eines „Large“ erneut wiederholt Lösungsebene “- Gruppen von Gruppen von Teams mit analogen Rollen zu denen auf Programmebene, die sich jedoch über Release-Züge erstrecken. In diesem Fall werden wahrscheinlich dieselben Probleme wiederholt, aber die Lösungsebene scheint weniger häufig eingerichtet zu sein.

SAFe wird (häufig) mit Rally gebündelt – WEITERE Einschränkung der Teamautonomie

SAFe ist häufig ein Paket mit der Projektmanagementsoftware Rally. Rally ist die Art von Software, die Sie erwarten würden Ein Unternehmen, das SAFe verwendet, um zu machen – es ist überladen mit Funktionen, unkonzentriert, verwirrend, instabil und folglich schwer zu erlernen und zu verwenden.

Das Wertversprechen der Einführung von Rally for Leadership besteht darin, dass sie es sehen können Berichterstattung, die ihnen ein einfaches, einheitliches Bild von th gibt Der Fortschritt und die Probleme im gesamten Unternehmen.

Dies bedeutet natürlich, dass jeder im Unternehmen Rally nicht nur nutzen muss, sondern es auch konsistent nutzen muss. Dies kann wiederum nur durch ein Diktat von oben nach unten erreicht werden. Die Rallye und die Art und Weise, wie sie über Arbeit denkt, werden allen Teams unabhängig von ihren Vorlieben, ihrem Kontext oder ihrem Buy-In aufgezwungen. Um tatsächlich alle Informationen zusammenfassen zu können, ist ein unglaublicher Aufwand beim Schätzen und Nachverfolgen erforderlich, der alles verlangsamt und die tatsächliche Erledigung der Arbeit äußerst stören kann.

Darüber hinaus ist die Berichterstellung auf oberster Ebene nicht einmal besonders nützlich. Es konzentriert sich auf die Dinge, die Rallye verfolgt – Metriken wie das Volumen der gelieferten Story-Punkte (im wahrsten Sinne des Wortes erfunden) oder die Anzahl der behobenen Fehler (ein schreckliches Maß für die „Produktqualität“).Wenn das Management diese Statistiken ignoriert, ist der Overhead, den sie hinzufügen, umsonst. Wenn sie die Metriken einhalten, werden die Statistiken verfälscht, sodass die Teams gut aussehen und in Ruhe gelassen werden. Schätzungen werden überfüllt, kleine Arbeiten werden übertrieben, und dies kann leicht zu einem Vertrauensverlust führen.

SAFe verfolgt den schlechtesten Ansatz bei der Verwaltung von Abhängigkeiten

A. Abhängigkeit ist ein Fall, in dem ein Team warten muss, bis etwas an anderer Stelle erledigt ist, bevor es seine eigene Arbeit erledigen kann. SAFe basiert auf einer rückständigen Haltung, dass Abhängigkeiten eine unveränderliche Tatsache des Lebens sind, die akzeptiert und verwaltet werden sollte. Manchmal werden sie sogar als strategischer Vorteil bezeichnet. Wenn Sie Abhängigkeiten als eine schlechte Sache betrachten, die bei jeder Gelegenheit minimiert werden muss, stellen Sie in der Realität möglicherweise fest, dass diese Möglichkeiten reichlich vorhanden sind und dass die Nutzung dieser Abhängigkeiten in erster Linie zu Vorteilen führt. Hier sind nur einige Vorschläge, die SAFe unterbetont oder gänzlich ignoriert:

1. Förderung einer Kultur des Inner-Sourcing, bei der ein Team Arbeiten an die Codebasis eines anderen Teams senden kann, ohne sich darüber hinaus darauf verlassen zu müssen Akzeptieren der Zusammenführung
2. Machen Sie es Teammitgliedern einfach, Teams vorübergehend oder dauerhaft auszutauschen, wenn dies sinnvoll ist.
3. Konzentrieren Sie sich darauf, Teams einzustellen, zu strukturieren und zu schulen, um ihre eigenen Bedürfnisse zu erfüllen ohne fremde Hilfe

Wie SAFe tatsächlich Abhängigkeiten verwaltet, hängt davon ab, dass der Fokus auf Planung, Prozess, Hierarchie und Standardisierung liegt. Vorhersehbar führt dies zu vielen Besprechungen, die die Arbeitsfähigkeit beeinträchtigen. Dieser Ansatz wird durch einen universellen Roll-out eingeführt, der die gesamte Organisation auf einmal betrifft. Es wird nicht berücksichtigt, welche Bereiche ohne die zusätzliche belastende Struktur eigenständig gewesen wären.

SAFe orientiert sich übermäßig an der Planung

Ein Kernmerkmal von SAFe ist die Idee von ~ 10 Wochen Programminkremente (PIs). Sie können sich diese Art von riesigen Sprints vorstellen, die alle Ihre normalen Sprints enthalten.

Jeder PI beginnt mit einem PI-Planungsereignis, das ungefähr zwei Tage dauert. Die PI-Planung erfordert auch Vor- und Nachplanungsaktivitäten auf Programmebene.

Es ist auf jeden Fall sinnvoll, Menschen persönlich zusammenzubringen, um Beziehungen aufzubauen, Informationen auszutauschen und sich an Zielen zu orientieren. Auf der anderen Seite ist es viel weniger wertvoll, dieses begrenzte Zeitfenster zu verwenden, um 10-Wochen-Pläne für bestimmte User Stories basierend auf vordefinierten Funktionen zu erstellen und sich dann für diese Pläne zu engagieren.

Sobald die PI-Planung endet, werden diese Pläne auf der Grundlage von Limited erstellt Verständnis und zahlreiche Annahmen werden hinfällig, sobald etwas Neues gelernt wird. Die Teams werden ständig hin- und hergerissen zwischen dem Festhalten an dem Plan, den sie gelernt haben, und der Neuausrichtung der Erwartungen aus Gründen, die die über ihnen möglicherweise nicht verstehen können.

SAFe orientiert sich am Volumen. kein Wert

Bei all dem Fokus auf Volumenmetriken, Schätzungen und Abwanderungsarbeiten durch die Pipeline geht das Konzept dessen, was tatsächlich wertvoll oder erfolgreich ist, leicht verloren. Es wird oft angenommen, dass mehr Arbeit, die aus der Tür geliefert wird, „Wert“ sein muss, selbst wenn die Erfahrung mit dem Produkt tatsächlich leidet und die Benutzer nicht von den zusätzlichen Funktionen profitieren.

SAFe ist sich der Kritik bewusst, dass Es ist nicht wertorientiert und hat kürzlich „Design Thinking“, „Customer Centricity“ und andere Konzepte zu seiner Dokumentation hinzugefügt, um dies zu kompensieren. Bisher bin ich nicht davon überzeugt, dass es wesentliche Änderungen in seinem Prozess vornimmt, die tatsächlich Platz für diese Dinge schaffen

Zum Beispiel lässt die Definition von „Kunden“ von SAFe die Tür offen, um Geschäftsinteressenten oder diejenigen, die die Wertströme finanzieren, als „Kunden“ zu definieren unterscheidet sich stark von der Neuausrichtung aller (einschließlich derjenigen, die die Finanzierung bereitstellen), um sich auf die Bedürfnisse der Endbenutzer zu konzentrieren, die die Software tatsächlich verwenden. Dies ist ein Kernelement des Design-Denkens.

SAFe ist unnötig komplex

SAFe hat einen natürlichen Schutzvorteil es aus der Kritik; Es ist so kompliziert, dass es schwer zu verstehen ist. Trotz der zusätzlichen Zeit, die ich mit der Erforschung des Frameworks verbracht habe, werde ich wahrscheinlich immer noch einige Dinge falsch machen oder einige wichtige Punkte übersehen. Eine Fülle von Komplexität ist jedoch selbst ein berechtigtes Anliegen. SAFe hat so viele Besprechungen, Prüfpunkte, Werte und Methoden, dass es grundsätzlich unmöglich ist, alle auf die gleiche Seite zu bringen.

SAFe begrenzt Rückblicke und kontinuierliche Verbesserungen

Rollen auf Programmebene und Die oben genannten können möglicherweise nicht an allen Team-Retrospektiven teilnehmen.Dies bedeutet, dass Rückblicke nicht direkt von den Personen gehört werden, die tatsächlich viele der diskutierten Dinge ändern können.

Die Art und Weise, wie SAFe versucht, dies zu kompensieren, reicht nicht aus.

PI-Planung Dies ist das einzige Mal, dass jeder in einem Release Train garantiert persönlich zusammen ist. Leider enthält es eine kurze Retrospektive, die sich nur auf den Erfolg des Planungsereignisses selbst bezieht.

SAFe enthält gegen Ende jedes PI ein „Inspect and Adapt“ -Ereignis, das jedoch fast so konzipiert ist, dass es übersprungen wird Wie schwierig es ist, sich für die RTE zu koordinieren. Wenn die Veranstaltung stattfindet, wird sie vorbereitet, indem natürlich die Volumenmetriken des letzten PI überprüft werden. Zusätzlich werden nur 30 Minuten der Veranstaltung für eine tatsächliche Retrospektive vorgesehen, bei der Probleme auftauchen und vereinbart werden Wenn diese Zeit gleichmäßig auf alle Mitglieder eines 100-Personen-Release-Zugs verteilt ist, erhält jeder Teilnehmer alle ~ 10 Wochen etwa 18 Sekunden Zeit, um Probleme in einem Kontext anzusprechen, in dem sie möglicherweise tatsächlich gehört werden.

SAFe enthält auch einige andere Elemente wie „Bewertungsdiagramme“, in denen Teams umfassender befragt werden. Diese bestätigen jedoch in hohem Maße, dass die SAFe-Praktiken befolgt werden, nicht, ob sie wirksam sind oder nicht.

SAFe verschlechtert die Konzepte, die es aggregiert

Ein Schlüssel Ein Teil von SAFe, den ich noch nicht angesprochen habe, ist die Zusammenfassung bestehender Konzepte wie Scrum, Kanban, Lean Product, Lean UX und DevOPs.

Wenn Sie nicht vertraut sind, würde ich vorschlagen, jedes Konzept zu untersuchen unabhängig im Laufe der Zeit und nicht auf einmal. Viele sind selbst wertvoll, aber SAFe leistet keine großartige Arbeit bei der tatsächlichen Synthese und kann manchmal zu Verwirrung führen. Ein typisches Beispiel:

SAFe setzt sich routinemäßig dafür ein, wie seine Praktiken den „Lean-Agile“ -Prinzipien folgen. Der Trick besteht darin, dass sich „Lean-Agile“ nicht auf „Lean“ – oder „Agile“ -Prinzipien bezieht.

Stattdessen sind „Lean-Agile Principles“ eine Kreation von SAFes eigenem Design. Diese neuen „Prinzipien“ verzerren die Konzepte, die sie aufnehmen. Zum Beispiel untergräbt sich die Seite über die Dezentralisierung von Entscheidungen (die als das niedrigste aller Prinzipien eingestuft wird) auf subtile Weise, indem sie die Bedeutung der Zentralisierung der Entscheidungsfindung für viele Anwendungsfälle hervorhebt. Andere aufgelistete Prinzipien haben ähnliche Probleme. Für eine Person, die mit all diesen Informationen auf einmal vertraut ist, kann die tatsächliche Bedeutung der ursprünglichen Konzepte verloren gehen.

SAFe ist nicht agil

Inzwischen sind viele der Möglichkeiten, wie SAFe ist Inkonsistent mit einer agilen Denkweise sollte ziemlich klar sein. Es ist planorientiert, bürokratisch, kompliziert, beinhaltet viele oft unnötige Prozesse, beeinträchtigt die Teamautonomie und vieles mehr.

Aber spielt es eine Rolle, ob SAFe agil ist oder nicht, wenn es uns wirklich um Effektivität geht oder nicht ?

Ja. Dies ist der Fall.

Agile Prinzipien sind nur agile Prinzipien, da sie allgemein als wirksam anerkannt und vereinbart wurden. Dieses Denken fand Resonanz bei einer breiteren Gemeinschaft von Praktizierenden, weshalb die Bewegung ursprünglich startete. Wenn Sie der Meinung sind, dass Agilität ein Prädiktor für die Effektivität ist (ein Glaube, der vermutlich hinter einem Teil des Interesses an SAFe steht), ist es ziemlich wichtig, ob SAFe mit agilem Denken übereinstimmt. Menschen über das, was sie kaufen, in die Irre zu führen, ist eine schlechte Sache, und es ist nicht falsch, dies zu nennen.

Was ist mit all den Fallstudien, in denen SAFe nachweislich funktioniert hat?

Auf scaledagileframework.com gibt es ungefähr 40 Fallstudien zur erfolgreichen Einführung von SAFe. Die Fallstudien zu Fehlern fehlen auffällig. Im Gegensatz zum Akronym beinhaltet SAFe die gleichzeitige Änderung eines riesigen neuen Prozesses in einem riesigen Ökosystem – ein massives Risiko. Sofern nicht jedes dieser 40 erfolgreichen Unternehmen 11.250 zertifizierte SAFe-Praktiker hatte, gibt es einige Unternehmen, von denen wir nichts hören.

Außerdem habe ich in den Fallstudien, die dies tun, nicht viel zu viel Wert gelegt existieren. Selbst wenn die Volumenmetriken, auf die sie sich konzentrieren, wirklich wertvoll waren, ist es einfach, ein paar Statistiken auszuwählen, die den Eindruck erwecken, dass die Dinge gut gelaufen sind.

Um sich auf ein bestimmtes Beispiel zu konzentrieren, werfen wir einen Blick auf einen Auszug Aus der Fallstudie zur Implementierung von SAFe bei Fitbit:

Im Jahr 2016 brachte das Verbrauchertechnologieunternehmen Fitbit vier neue Produkte auf den Markt, die von positiv aufgenommen wurden Verbraucher und versendete über 22 Millionen Geräte. Die Bereitstellung der höchsten Anzahl von Produkten pro Jahr ist teilweise auf das Engagement des Unternehmens und den Erfolg bei der Einführung von SAFe® (Scaled Agile Framework®) zurückzuführen, um das Team so zu skalieren, dass die Zieltermine erreicht werden.

© Scaled Agile, Inc.

Hier ist der Aktienkurs von Fitbit in den letzten fünf Jahren:

Ja… 2016 sieht für Fitbit wie ein großartiges Jahr aus.

Nun können wir den Untergang von Fitbit nicht wirklich SAFe zuschreiben Annahme mit der Menge an Informationen, die wir haben.Aber wenn ein Unternehmen so viel zu kämpfen hat und dennoch die Akzeptanz von SAFe als Verbesserung der Reaktionsfähigkeit seiner Produktentscheidungen begrüßt, werde ich meine Augen ein paar Grad enger zusammenziehen, wenn ich mir die restlichen Fallstudien ansehe.

Als Übergangsschritt ist es jedoch in Ordnung, oder?

Wenn Sie jemand sind, der dieses Argument vorbringen würde, müssen Sie denken, dass SAFe von einem Übergang entfernt werden muss. In diesem Punkt sind wir uns einig!

Um diesen Übergang zu erreichen, müssen wir natürlich einige Zeit damit verbringen, auf die Teile hinzuweisen, die nicht gut funktionieren.

Ist das etwas, was Sie haben? Sie haben viel Zeit damit verbracht?

Auch wenn Sie es sind, ist SAFe so eingerichtet, dass Sie nicht tatsächlich wechseln können. Die Autorität, die es in die Hände des Managements legt, dient als Legitimation der Top-Down-Kontrollmentalität. Dies passt schlecht zu den fehlenden Methoden zur Prozessverbesserung, die wir bereits behandelt haben. Die Berechtigung, SAFe an den entsprechenden Kontext anzupassen, steht den tatsächlichen Teams, die am besten in der Lage sind, zu erkennen, was nicht funktioniert, größtenteils nicht zur Verfügung Kernpraktiken als Übergang. Wenn es sich um einen Übergangsrahmen handelt, ist es ziemlich schlecht, irgendeine Art von Übergangsplan bereitzustellen.

Der Hyperfokus auf Zertifizierungen beeinträchtigt auch die Flexibilität des Frameworks Wenn Sie stundenlang daran arbeiten, sich zertifizieren zu lassen, wird die Zertifizierung zu einem Teil Ihres eigenen Wertes. Ein Übergang zu etwas, das weniger wie SAFe aussieht, scheint diesen Wert zu gefährden. Ich kann niemanden beschuldigen, in einem zertifiziert zu sein Arbeitsmarkt wo Zertifizierungen wichtig sind. Diese Personen haben jedoch eine besondere Verantwortung, auf die Nachteile von SAFe und mögliche Möglichkeiten zur Verbesserung oder Abweichung von SAFe zu achten.

Diese Probleme treten allgemein auf

Ich bin nicht allein viele dieser Kritikpunkte zum Ausdruck bringen – obwohl ich hoffe, dass ich ein bisschen weiter gegangen bin, um sie mit den spezifischen Praktiken im Rahmen zu verbinden. Wenn Sie nach bestätigenden Zeugnissen suchen, sind hier einige:

Ken Schwaber, Mitentwickler von Scrum, äußerte bereits 2013 ernsthafte Bedenken hinsichtlich SAFe.

Nicholas M. Chaillan Der Chief Software Officer der US Air Force rät davon ab, „starre, vorgeschriebene Frameworks wie das Scaled Agile Framework (SAFe) zu verwenden“.

Forbes-Mitarbeiter Steve Denning ruft SAFe in seinem Artikel zu „besonders besorgniserregend“ auf Wie man gefälschte Agile erkennt.

Marty Cagan von der Silicon Valley Product Group erklärt, wie SAFe der Denkweise von Silicon Valley-Unternehmen widerspricht.

Bleib sicher da draußen (nicht SAFe)

Während SAFe sicherlich viel Kritik erhalten hat Mein persönlicher Eindruck ist, dass diese Kritik über bestimmte Online-Kreise hinaus möglicherweise kein großes Publikum erreicht hat. Dies ist besonders wahrscheinlich, wenn man bedenkt, dass immer mehr Unternehmen das Framework täglich anwenden.

Für viele Menschen ist die Vorstellung, dass mit SAFe etwas nicht stimmt – oder dass es überhaupt im Widerspruch zu agilen Prinzipien steht – möglicherweise völlig neu.

Eine verstärkte Diskussion, die sich an ein breiteres Publikum richtet, kann wahrscheinlich helfen. Ich hoffe, dass ich in Zukunft mehr auf dieses Thema eingehen und detailliert beschreiben kann, welche anderen Alternativen es gibt.

Selbst wenn Sie nicht in einer SAFe-Umgebung arbeiten, ist dies keine Entschuldigung, um selbstgefällig zu werden . Die Bedenken, die ich hier dargelegt habe, sollten als allgemeinere Warnung verstanden werden – selbst die vernünftigsten Ideen können leicht kooptiert, korrumpiert und verwirrt werden, wenn Sie nicht genau aufpassen.