Liefert SAFe bessere langfristige Ergebnisse als traditionelles Agile?

Zunächst muss ich sagen, dass meine Erfahrung nicht mit der Aussage übereinstimmt und mir auch keine Studie bekannt ist, die das belegt. Wenn SAFe oder "reines" Agile gut angenommen werden, haben beide einen hervorragenden Durchsatz und eine hervorragende Qualität.

Wenn ich mir die Unterschiede ansehe, würde ich zuerst schauen, was es schwierig macht, sie gut zu übernehmen. Bei SAFe gibt es viele zu besetzende Positionen und es fühlt sich an wie die alten Positionen in Wasserfall, aber das sind sie nicht. Aus Sicht des Änderungsmanagements ist es verlockend zu sagen, dass Manager oder Teamleiter zu Release-Train-Ingenieuren usw. werden. Hier scheitern viele SAFe-Einführungen, weil die Leute ihren alten Job machen, nicht ihren neuen, und sie tragen viele der alten Funktionsstörungen, die das Unternehmen mit SAFe zusammen mit ihnen beheben wollte.

Bei einem „reinen“ agilen Ansatz ist das Problem genau umgekehrt (und paradoxerweise sehr ähnlich). Die Vereinfachung der Organisation und die Dezentralisierung der Entscheidungsfindung ist erschreckend, und so viele Organisationen tun dies einfach nicht. Sie veranstalten einige Meetings und nehmen ein paar Begriffe aus Scrum oder Kanban und nennen es einen Tag. Jeder im Änderungsmanagement wird Ihnen sagen, dass eine halbfertige Änderung eine Katastrophe ist.

Sie haben nach einem Nachteil gefragt, und ich möchte darauf hinweisen: Zu welcher Änderung ist Ihre Organisation tatsächlich bereit? Beides ist eine echte Verpflichtung und keines sollte halbfertig sein, sonst landen Sie wahrscheinlich an einem schlechteren Ort, als Sie begonnen haben.

Eine andere Sache, die Sie berücksichtigen sollten: Wofür optimieren Sie? SAFe wurde immer für unglaublich große Projekte entwickelt. Ich meine nicht 5 Teams, ich meine Dutzende oder mehr. Scrum ist für schnelle Problemlösung und Anpassungsfähigkeit optimiert (auf Skalierungsebene behalten LeSS und Scrum@Scale beide diesen Fokus bei). Kanban ist für den Arbeitsfluss durch einen Workflow optimiert. Wenn Sie Probleme lösen und sich an eine sich schnell ändernde Umgebung anpassen müssen, könnte SAFe "funktionieren", aber auf die gleiche Weise, wie Sie bei Bedarf einen Nagel mit einem Schraubenschlüssel einschlagen können. Ebenso würde ich nicht versuchen, riesige Projekte nur mit einem reinen Scrum-Ansatz zu verwalten.

Ich sehe nicht, dass SAFe und traditionelles Agile im Sinne von Apfel zu Apfel wirklich vergleichbar sind.

Traditionelle Agilität ist großartig, und im Zweifelsfall ist es eine großartige Idee, das agile Framework zu verdoppeln. Aber auf einer grundlegenden Ebene, wenn Sie 10 agile Teams haben müssen, die in die gleiche Richtung an einer im Wesentlichen gleichen Initiative arbeiten, brauchen Sie eine Möglichkeit, diese Aktivität zu koordinieren.

Ausgewachsenes SAFe ist mit Sicherheit entmutigend. Es könnte jedoch besser sein, nur den Programm-/Essential-Teil von SAFe als eine Möglichkeit zur Lösung von Agile in großem Maßstab zu betrachten.

Ich bin ein evidenzbasierter Manager, d. h. meine Praxis basiert auf einer laufenden Überprüfung der wissenschaftlichen Literatur, daher kann ich Daniels Aussage bestätigen: Es gibt keinen objektiven Beweis dafür, dass SAFe besser (oder schlechter) ist als andere Methoden zur Implementierung von Agile Management.

Ich empfehle, mit Begriffen vorsichtig zu sein, nur damit Sie die beste Beratung erhalten! Agile ist eine Philosophie oder ein Ansatz für das Arbeitsmanagement, keine Methode, also gibt es so etwas wie „traditionelles Agile“ nicht. SAFe ist nur einer von Dutzenden von Ansätzen zur Skalierung agiler Methoden für viele Teams, wobei SAFe auf der Methode namens „Scrum“ basiert. Daniel erwähnt ein paar andere, und ich habe mein eigenes erstellt, Full Stack Scrum. Wie er und Eric sagten, hängt es davon ab, wie viele Teams Sie zu koordinieren versuchen, ob Sie eines davon brauchen. Basic Scrum lässt sich tatsächlich recht gut über mehrere Teams hinweg skalieren, wenn Sie die Begriffe einfach nach oben übersetzen. Das heißt, behandeln:

• Ein Vertreter jedes Teams (häufig der Scrum Master) wie ein Teammitglied, in diesem Fall in einem Führungsteam auf Programmebene
• Features ("Epics") wie User Stories
• Release-Zeiträume (normalerweise vier Monate oder weniger) wie Sprints
• Ein Moderator auf Programmebene wie ein Scrum Master
• Ein wöchentliches „Scrum of Scrums“ mit allen SMs wie dem Daily Scrum

Oder lassen Sie alle an einer einzigen gemeinsamen Demonstrationszeremonie teilnehmen, und Sie brauchen nicht einmal das Scrum of Scrums!