SAFe 案例研究:來自現場的轉型筆記

已發表: 2022-08-23

本文是 Toptal 的敏捷擴展系列的第三部分,旨在指導項目經理進行團隊擴展工作。 請務必閱讀第一部分,“5 個敏捷擴展框架比較:您應該使用哪一個?” 第二部分,“敏捷擴展:Scrum Master 的 SAFe 最佳實踐”。

根據第15 屆年度敏捷狀態報告,94% 的公司以某種方式實施敏捷。 但研究還表明,90% 的組織在企業範圍內的敏捷實施中遇到了困難。 通常,由敏捷教練、Scrum 大師和其他項目管理專業人員來領導和組織這些工作。 通常,他們在難以理解的公司文化中與抵制變革的團隊或部門合作。

在本次圓桌會議中,三位 Toptal 項目經理討論了領導敏捷轉型的挑戰。 因為他們的解決方案符合 Scaled Agile Framework (SAFe),我們還與 SAFe 的創建者 Dean Leffingwell 進行了交談。 他們的集體見解表明,SAFe 從業者需要對敏捷是什麼有一個清晰的認識,並製定一個可以讓頑固的團隊參與進來的領導計劃。

與框架的創建者交談 SAFe

SAFe 是由 Scaled Agile 正式化的一個框架,它的歷史可以追溯到 2014 年。但對於 Leffingwell 來說,這項工作始於他在 2000 年代初第一次遇到敏捷團隊時。 作為一名軟件開發方法學家,他對敏捷實踐在開發團隊中的成果印象深刻,並立即開始探索如何將這種思維方式應用於整個公司。 如果一個敏捷團隊可以產生結果,那麼一個由敏捷團隊組成的團隊可以產生什麼? 敏捷實踐如何用於國內或國際公司的全面轉型項目? 正如 Leffingwell 所說,“我熱愛軟件開發。 我愛敏捷。 我只是想要它一點。”

標題為“最受歡迎的擴展框架”的條形圖。有 10 個條形圖,分別標有“規模化敏捷框架 (SAFe)”、“Scrum@Scale/Scrum of Scrums”、“企業 Scrum”、“Spotify 模型”、“敏捷投資組合管理 (APM)”、“有紀律的敏捷 (DA) 、“大規模 Scrum (LeSS)”、“Nexus”、“精益管理”和“企業敏捷治理秘訣 (RAGE)”。每個條形還標有代表使用該框架的組織比例的百分比:分別為 37%、9%、6%、5%、3%、3%、3%、3%、2% 和 1%。圖表底部的一條線表示,“來源:第 15 屆年度敏捷狀態報告”。
SAFe 是使用最廣泛的規模化框架,在第15 屆年度敏捷狀態報告中受到 37% 的受訪者青睞。

從那以後的幾年裡,公司已經認識到 SAFe 的好處,包括更短的交付時間、更高的產品質量、更高的效率和更敬業的員工。 截至 2021 年,全球超過三分之一的組織使用 SAFe,其中最重要的方面是它提供的共享流程和統一語言。 例如,如果一個團隊認為 sprint 需要兩週時間,而另一個團隊認為 sprint 需要 30 天,那麼它就會產生 Leffingwell 所描述的“巴別塔問題”。 如果團隊甚至無法就“功能”的含義達成一致,他們就很難討論要添加哪些功能。 “如果你想構建大型解決方案,你[需要]人們以共同的方式工作,”他說。 “在我們的行業中,沒有一個術語不超載,比如‘迭代’、‘衝刺’或‘積壓工作’。 如果您嘗試跨團隊和區域邊界工作,那將無濟於事。”

敏捷成功案例

即使在迫切需要變革的情況下,讓公司中的每個人都採用統一的方式來談論和工作也是一項艱鉅的任務。 在成熟的公司中,這可能更難。 Leffingwell 解釋說:“你看到的是世界上最大的公司,它們賺了很多錢,做得非常好,而且競爭激烈——他們必須改變。 好吧,他們的問題是他們為什麼要這麼做?” 這裡介紹的 Toptal 項目經理每個人在他們自己的擴展活動中都遇到了這樣的問題,並且每個人都找到了自己的方式來使用 SAFe 完成他們的敏捷轉換。

展示價值

智利聖地亞哥的 Toptal 項目經理 Alvaro Villena 最近為開發跨業務平台的投資組合完成了 SAFe 過渡。 “我轉型的第一個里程碑是舉辦價值流研討會,”他說。 簡單來說,價值流研討會是一個啟動會議,旨在確定從概念到交付的整個業務流程以及其間的所有步驟、用戶、系統和痛點。

讓整個企業的代表參加研討會有助於 Villena 了解公司文化以及他的障礙是什麼。 “在我們實施研討會之前,有一種結構,一個企業有他們的團隊,另一個企業有他們的團隊,下一個企業有他們的團隊——這三個人沒有互相交談。”

Villena 發現,儘管所有團隊都有相似的痛點,但在解決方案上沒有協作。 例如,儘管投資組合中的每個企業都發貨了產品,但只有一個企業開發了跟踪系統。 他們沒有理由不能全部使用它,只是沒有人分享知識。 一旦研討會讓他們開始討論,知識就開始在團隊、企業和產品所有者之間流動。 “這種對話對節目來說真的非常強大。 這是一個很好的起點,”Villena 說。 當 DevOps、設計和產品都知道其他團隊在做什麼時,他們會看到公司中有他們可以使用的解決方案。 “他們開始問,'我怎麼能擁有它?' 這就是你介入並說'遵循這個過程'的地方。

“在他們知道原因之前,沒有人想要改變。 所以你從一個原因開始,給他們一個更美好的未來。” SAFe 的創始人 Dean Leffingwell

Leffingwell 知道團隊有時會抗拒。 “在他們知道原因之前,沒有人想要改變,”他告訴 Toptal。 “所以你從一個原因開始,給他們一個更好的未來。” 讓團隊了解他們可以提高多少效率是變革領導力的有力工具。

即使每個人都熱情地加入,你仍然應該期待艱難的開始。 例如,習慣於傳統瀑布式開發和大型發布的團隊可能難以轉向更具迭代性和​​敏捷性的開發流程,即使他們看到了其中的價值。 “我們做的第一個項目增量對團隊來說是一場災難,”Villena 說。 “我們知道它會是; 我們告訴客戶,前三個月可能會很困難。” 為了彌補這一點,他在第一個程序增量 (PI) 結束時構建了一個為期一周的迭代,團隊可以在其中評估他們的進度。 他組織了一個衝刺,專門用於流程改進和評估,超越通常的檢查和適應。 他發現將敏捷思維不僅應用於產品,還應用於業務轉型,花時間退後一步,看看哪些有效,哪些無效,並做出相應的調整。

創造小胜利

為您採用 SAFe 過程中的意外障礙做好準備是很重要的。 幾年前,塞爾維亞貝爾格萊德的 Toptal 項目經理 Miroslav Anicin 正在將一家電信公司過渡到 SAFe。 該公司已將其所有軟件開發外包。 組建一個異地團隊並不是一項特別繁重的任務——所涉及的問題主要是後勤問題。 但這種努力給公司本身的轉型帶來了無法預料的挑戰。 “我正在尋找我們在發布培訓中需要的能力,”他說。 “而且我必須選擇的所有人都來自營銷、法律、產品、金融——完全缺乏敏捷思維,甚至沒有任何敏捷經驗。”

很明顯,管理層沒有處理敏捷團隊的經驗。 分佈式決策需要管理者放棄一些控制權,如果他們沒有敏捷框架的經驗,領導層可能會猶豫不決。 為了解決這個問題,Anicin 必須自下而上和自上而下進行培訓,指導領導者及其團隊。

轉向更加分散的決策制定需要“將工作方式從指揮和控制,通過僕人式領導,轉變為這種授權的學習文化和敏捷文化——以及容忍錯誤的能力,”Leffingwell 說。

Anicin 開始了逐步擴展的過程——在單個團隊中執行小型敏捷項目,而不是在 SAFe 框架內——因此各個團隊可以開發一些實踐經驗。 這些項目必須是無關緊要的,並且足夠小,以至於如果第一次嘗試出現問題,公司不會受到傷害,但又足夠有用,可以向團隊展示該方法可以完成的工作。 例如,營銷團隊創建了一個內部營銷活動,在此期間,Anicin 向他們傳授了 Scrum 的基礎知識。 與 Villena 的研討會類似,這些較小的項目真實地展示了敏捷的價值,因此團隊成員和領導層可以在全面過渡之前看到短期發布和持續改進的好處。

滿足您的團隊的需求

當駐巴黎的 Toptal 項目經理 Imane Marouane 領導一家大型跨國金融機構的轉型時,她步入了一個混亂的環境,在這個環境中,各個團隊都做出了紮實的工作,但在公司範圍內沒有共同的願景。 “每個團隊都有自己的優先事項。 每個產品經理都希望他們的產品首先交付。”

SAFe 對這個問題的解決方案可以在加權最短作業優先 (WSJF) 模型中找到。 WSJF 提供了工作優先級的標準,因此當需要決定下一個任務應該是什麼時,第一步不會涉及如何對重要性進行排序的爭議。 在基於流程的敏捷系統中,您不必擔心一次性交付所有內容,因為正如 Leffingwell 所說,“最重要的是接下來要做什麼工作。 這是一個比什麼是最有價值的工作更容易回答的問題。” SAFe 提供了一種解決團隊之間依賴關係的方法——任務排序對於這一結果至關重要。

標題為“加權最短工作優先公式”的插圖。一個框包含一個公式,“WSJF 等於延遲成本除以作業持續時間(作業大小)”。底部有一行寫著“來源:Scaled Agile”。
Scaled Agile 的加權最短工作優先公式通過權衡延遲成本與所需工作的難度和持續時間來確定任務的優先級。

Marouane 解決依賴關係的途徑變得不確定:“經過兩次沖刺,在第一次檢查和調整之前,我們注意到一些團隊沒有遵循我們的 PI 計劃。” 未遵循 PI 計劃中定義的依賴關係,因此一個團隊的工作無法開始,因為另一個團隊的貢獻尚未準備好。

“由於這是第一次迭代,而且團隊不習慣這種工作,我們決定舉行一個額外的儀式——每週召開一次會議,討論依賴關係的進展,”Marouane 說。 “每個團隊都有一個人來更新他們貢獻的進展。” 這樣,如果 A 團隊說他們無法交付,B 團隊可以提前知道並做出相應的計劃,而不是等待在他們的 sprint 開始時不會實現的貢獻。

Leffingwell 在對 SAFe 進行此類調整時鼓吹謹慎:“SAFe 是一個責任體系。 ......你可以適應它,但你必須非常小心。” 儘管該框架旨在具有適應性,但如果不重新評估,更改往往會被納入。 Essential SAFe 配置的存在是為了確保任何更改都符合基本標準。

Marouane 的額外儀式再次包含在第二個 PI 中,到第三個它已被淘汰。 團隊沒有什麼可報告的尚未溝通的。 一點額外的靈活性讓 Marouane 讓團隊回到更傳統的流程軌道上。 她發現轉型本身需要敏捷的思維方式才能充分利用金融機構的團隊。 重要的是,她所做的改變,通過對持續改進的承諾,最終服務於作為 Essential SAFe 基礎的精益敏捷原則。 她的解決方案為公司提供了它所缺乏的統一願景,並允許團隊朝著相同的優先事項共同努力。

適應未來

任何大規模運行的框架都將面臨挑戰。 移動部件的數量和相互競爭的利益是巨大的。 但回報同樣巨大,一個執行良好的過渡將為團隊提供實現共同目標所需的工具。 您在如此大規模的實施中面臨的障礙將是不可預測的,而敏捷思維幫助 Villena、Anicin 和 Marouane 適應了意想不到的挑戰。 畢竟,這就是持續交付的目的:使用工具賦予您的流程以適應不可預見的情況。

Scaled Agile 還適應新技術和不斷發展的行業標準,並根據需要引入新工具和功能。 每個人都需要保持敏捷並為意外做好準備。 “我們沒有水晶球,”萊芬威爾說。 “我們只是跑得快,領導努力,跟隨努力——盡可能快地寫作。”