SAFe不是敏捷 - Jeff Gothelf

自從Scaled Agile Framework（簡稱SAFe）在4.5版中採用Lean UX以來，我就收到了源源不斷的入門問題，這些問題是關於這兩種方法應該如何協同工作的。   

簡短的答案是，我不知道。 

稍長一點的答案是，我們在Lean UX中內建的所有原理似乎都不存在於SAFe中。 

SAFe對話顯然缺乏持續學習和改進，以客戶為中心，謙虛，跨部門協作，基於證據的決策，實驗，設計和課程更正的功能。

取而代之的是，採用這種工作方式的組織將重點放在僵化的團隊結構，嚴格的儀式和事件以及行為改變要求的不均勻分佈上，具體取決於組織中的高層人員。 

簡而言之，SAFe並不敏捷。 

考慮到訓練有素的訓練團隊必須經過“ SAFe認證”，因此他們抵制變革也就不足為奇了。他們已經過訓練，可以以一種非常特定的方式工作-一種只專注於可預測的交付方式，而不是學習方式，對學習過的課程不進行修正，當然也不是敏捷性。

使團隊真正敏捷的活動需要靈活的計劃。他們要求與客戶成功保持一致，而不是預先確定的功能。他們需要一個連續的發現過程，這不可避免地導致計劃外的路線修正。這些更正將立即“終止”釋出訓練。

尋求敏捷性的大型組織意識到了隨之而來的不確定性，並堅持熟悉的瀑布流程。SAFe給人一種“採用敏捷”的幻想，同時使熟悉的管理流程保持完整。在瞬息萬變的世界中，不斷變化的消費者消費模式，地緣政治的不穩定性和指數級的技術進步，這種工作方式是不可持續的。 

如果您在已經採用SAFe或正在實施SAFe的大型組織中工作，請問自己在此過渡期間發生了什麼變化。您離客戶更近嗎？瞭解您是否已交付有價值的東西需要花費多長時間？更好的是，您如何衡量“價值”？問自己，基於新發現實施一項舉措有多容易？然後，在開始使用“大房間規劃”，“ PI”和“釋出培訓工程師”之類的術語之前，將這些答案與情況進行比較。 

在大型組織中擴充套件任何工作方式都是棘手且不平衡的。試圖將整個過程應用到整個公司中，該過程完全專注於交付，而不是持續發現和糾正過程，只會強化傳統的工作方式。

心理上安全感是吸引人的，因為它似乎提供了一個尺寸適合所有配方大規模的敏捷性。實際上，它獎勵可預測性，合規性和合規性，同時為高管提供掩蓋“我們如何變得更加敏捷？”這一問題的掩護。

您對SAFe的經驗是什麼？你成功了嗎？我很想聽聽你的故事。

網友評論：

幾乎沒有爭議，SAFE確實是PMO /執行官管理組織的答案。它與典型的階段驅動的PMO流程沒有什麼不同，只是術語和角色不同。它會像牛奶一樣老化，並在幾年內被其他東西取代。

我在一家足夠大的公司工作，可以讓我目睹應用SAFe的多種方式（跨不同業務部門的多種釋出方式），我可以告訴你它們不是相同的。我的直覺告訴我，其中90％的差異來自關鍵職位人員的文化背景。作為RTE，我虔誠重複的一句話是“我們為什麼要這樣做？什麼目的？我們怎樣才能減少膨脹就達到相同的目標？”例如：兩年前，20個同事參加的每兩週一次的ART Sync會議耗時3-4個小時，而所有需要參加的人都感到恐懼。如今，同一個ART Sync通常只需不到60分鐘的時間，並且向利益相關者提供了該系統的簡短演示。在兩種情況下都使用SAFe…。

他顯然對SAFe一無所知，或者沒有對SAFe進行對話，因為SAFe代表了所有這些事情（不確定他是如何錯過的）。我確實同意大型組織喜歡假裝他們正在實施SAFe，實際上，他們只是在給豬塗口紅。除了新增一些PI計劃並將其稱為SAFe，其他就沒有太大變化。領導力永遠是成功實施SAFe的問題/障礙。

我同意你的觀點，但是我認為這是組織最好的方法之一：即組織必須採用一些敏捷的實踐和框架（例如Scrum）來保持一定的形式化。

SAFE是組織嘗試使管理控制變得敏捷的一種嘗試。本質上，敏捷的管理參與度非常有限，敏捷團隊的分佈非管理結構非常扁平。大型組織採用SAFE作為使結構敏捷的一種方式，因此SAFE並非敏捷，而是瀑布般的輪迴。

我不是SAFe的粉絲或從業者。最終，我覺得SAFe可以替代瀑布。它是不敏捷！但是，我確實在某種形式的全面規劃中發現了巨大的好處，正是因為您指出了精益使用者體驗/敏捷的好處：以客戶為中心，發現，學習和課程修正，而且我覺得它增加了兩個組成部分幫助高管放手，使團隊可以自治-透明和協作。它可以幫助我們專注於為客戶和企業帶來最大價值的計劃，而不是被某個特定產品或特定團隊所孤立。在沒有全力以赴的計劃的情況下，大型組織會淪為特色工廠的獵物。

我們主要使用Scrum和一些看板來實踐雙軌敏捷，並且在它們帶來最大價值時立即利用設計思想和精益方法。我們的公開路線圖是主題化的，其舉措可推動客戶取得成果，並與長期和近期的OKR保持一致。我們內部的四個月交付計劃是全面計劃的輸出，利用了一些新的“遠端：敏捷性框架”（r:af）。該計劃始終是交付和發現的結合。如果您有幾個以上的團隊（在我們的示例中是12個Scrum團隊），那麼全能計劃就是救命稻草。它使跨職能的團隊和利益相關者相互交流，分享見解並促進健康的辯論，從而使他們能夠共同解決問題，並獲得其他所有人的支援。

我最經常看到的是團隊需要更多的培訓和發現方面的幫助。因此，我說跳過敏捷框架培訓，併為團隊配備發現工具和培訓。許多團隊收集了一些定性的客戶聲音並進行了一些簡單的草繪後，便停止了發現迴圈。他們傾向於跳過假設，風險評估和實驗。而且，大多數團隊都將發現視為他們已經計劃交付的工作的驗證。

您可能不會記得我，但是我們在幾次會議上見了面，在那裡我很幸運地採訪了您與我合作的雜誌。順便說一句，我發現你的文章很真實。SAFe與敏捷無關。SAFe涉及組織的適應性，一致的結構以及多個團隊之間的協調與配合。事實證明，這是許多大公司採用它的巨大增值原因。

但是，我可以根據經驗告訴您，正如我們在我工作的公司中實施SAFe已有多年的歷史一樣，SAFe儘管流程嚴格，但它提供了創新，測試，學習和調整的手段。它只是在它們周圍放置了更嚴格的控制元件或護欄，因此我們不會失去對要實現的戰略目標的跟蹤。

我認為重要的是要記住這是針對大型組織的。中小型企業應該避免使用SAFe，因為它們不會受到大型企業的官僚主義和複雜性的影響，因此應該針對速度進行設計。

亞馬遜出色地做到了敏捷。拒絕敏捷的企業（這是一種選擇）必須希望並祈禱亞馬遜不會與他們競爭。

我看到SAFe試圖提供支援和指導的地方很多，而我也看到了很多失敗的地方。但這只是他執行的錯。無法有效地管理可以執行的積壓工作無濟於事，缺乏對執行力的評估，回顧無法幫助您不斷學習和適應。對我來說，SAFe是一個框架，甚至在名稱中都包含了這個框架。因此，我以此為指導，使您可以適應自己的業務需求。不管您使用哪種方法或框架，都需要包括Jeff所包含的一些關鍵實踐。就像當今大多數事情一樣，關鍵是人（員工和客戶）。確保他們參與支援和指導這些過程。

我來自一個敏捷的規模組織，該組織採用了SAFe的一些原則，並建立了自己的格式，文化和儀式及其某些組成部分。如今，我正在使用完整的SAFe設定，“ SAFe系統”的主要缺陷是應用於規模化敏捷的“流程優化”，因此將所有內容分解為計劃和組織結構。如果以可持續的，以客戶為中心的方式來改變事物，那麼我認為SAFe不會造成傷害。我仍在搜尋的是一個行業示例，其中一家公司採用SAFe並隨後根據通過漏斗的產品獲得了成功。

從我的閱讀中，您實際上是在說組織變革既困難又複雜，而不是爭辯“SAFE不是敏捷”的觀點。沒有任何一種“一刀切”的解決方案可以使更改變得容易。

如果將Scrum與看板進行比較，您可以輕易地認為Scrum與看板相比根本不敏捷，因為Scrum相當形式，流程，儀式和基於角色。雖然歡迎變化，但嚴格的時間限制（衝刺）和固定的範圍限制了變化。相比之下，看板對流程的要求極低，幾乎沒有角色，沒有時間表，而且您可以按小時進行更改變化，而不僅僅是外部衝刺。

就是說，我是否建議傳統的，與流程相關的組織立即從瀑布式轉換為看板式，因為看板是方法中最靈活的方法？絕對不。僅僅因為在系統和人員層面上需要的變更如此之大，以至於只有一個已經很敏捷的組織（如初創企業）才能一次成功地實現該變更級別。

您的觀點是正確的，但這是我要質疑其上下文背景。如果組織及其人員已經敏捷，那麼有很多更合適的方法來擴充套件敏捷，例如LESS，Scrum of Scrums或使用精益變更管理來建立自己的方法。但是，如果您有一個更傳統的，矩陣化的，與流程相關的組織，並且沒有實施重大的組織範圍內的流程轉換和人員轉換的歷史，那麼在組織變革的背景下，循序漸進的方法可能會更成功。

當我考慮組織變革時，我總是會想到Shu Ha Ri的概念。

• Shu –首先，我們必須掌握我們的工藝基礎。Scrum適​​用於團隊，Safe適用於擴充套件。簡單，易於遵循且可能掌握。請記住，在這一點上，我們可能仍會受到整體架構，有限的釋出功能，手動測試，缺乏對組織範圍的瞭解，敏捷帶來了什麼以及解決了什麼問題的限制。
• Ha –我們正在掌握Scrum和Safe，從而在整個組織範圍內發展敏捷的思維定勢。我們瞭解敏捷可以為我們個人和組織做什麼。這些知識使我們能夠採用我們的方法。一些團隊或業務組將開始修改其流程，以適應其更敏捷的需求。敏捷仍然是正確的，但是他們的精通使他們能夠調整流程以適應他們的特定需求。新增精益概念，設計思想，更敏捷的交付方式，CI / CD。模組化架構。
• Ri –您不再遵循行業標準的敏捷方法。您現在擁有自己的定製方法，可以通過可持續方法來實現最大價值。您交付的東西更少。您瞭解您的客戶，價值是什麼，您可以將價值直接連線回資產負債表。您唯一的護欄是敏捷，精益，設計思想原則和組織的願景。

就像所有變化一樣，敏捷是一段旅程。首先要了解為什麼需要改變，然後是我們當前的現實，然後是需要改變的東西，致力於改變，克服改變的障礙，最後衡量我們的成功。

SAFe是有效交付軟體的一種方法，它不是敏捷的。有很多人不瞭解敏捷和Scrum，他們只是盲目地做其他人正在做的事情。還有一個誤解是，如果我有很多開發團隊，那麼我需要一個擴充套件框架。擴充套件框架旨在由支援相同產品的團隊來利用，而不是由擁有大量開發團隊的組織來利用。如果您有20、30、40個團隊支援同一產品，那麼您永遠不會真正敏捷。

我擁有成為LeSS Huge的豐富經驗，並在不同公司中多次嘗試SAFe，大多數（從來沒有！）人都認為這比以前更好。似乎朝著正確的方向前進。10人中有8人不會倒退回去。到目前為止，我沒有比在大型企業中更接近“學習型組織”的經歷。它可能存在，但我還沒有遇到。並且：敏捷沒有大腦，請使用自己的大腦。

我當然同意SAFe的實現方式不是敏捷的，並且會承認SAFe與其他規模化敏捷方法相比是嚴格的，但是我不同意SAFe並非敏捷。

如我所見，SAFe的問題在於如何實現。它應該是一個框架，一個工具包，但從業人員對它的結構是教條的。儘管公司正在對SAFe的櫥窗裝飾進行大量調查，但他們卻忽略了不那麼性感的基本做法。整合團隊，根據能力，接受標準，擦拭極限和結果驗證確定優先順序。

SAFe是通向敏捷性的門戶，但是我們都必須認識到僅複製結構是不夠的。

在企業環境中擴充套件敏捷性既困難又充滿挑戰。對我而言，這是記住我們正在努力實現的目標，而這的核心是能夠以與業務價值一致的小增量塊形式釋出工作軟體的能力。

SAFe並不全都是壞事-但它絕對也不全是好事！對我而言，公司需要研究其運營，研究各種框架，然後從知識的觀點出發，構建滿足其獨特和個性化需求的框架。遵循不斷改進的原則。

在Boots，我們絕對不是敏捷組織。但是我們現在還不是瀑布式組織–我們正在逐步改變運營方式和構建軟體的方式，以探索對其他公司有用的方法，然後進行內部反思，以瞭解在我們的情況下該方法如何適用。

我們確實使用SAFe的元素，也使用精益原則，並且還從大型Scrum，紀律敏捷，企業看板和Scrum @ Scale中獲得了有益的學習。一個尺寸不能完全適合所有人–對我而言，這是關於不斷學習/改進的心態，並接受它們的許多道路有望帶來敏捷性。