SAFe不是敏捷 - Jeff Gothelf

簡而言之，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 –您不再遵循行業標準的敏捷方法。您現在擁有自己的定製方法，可以透過可持續方法來實現最大價值。您交付的東西更少。您瞭解您的客戶，價值是什麼，您可以將價值直接連線回資產負債表。您唯一的護欄是敏捷，精益，設計思想原則和組織的願景。