大規模敏捷框架比較－David Ko的學習之旅

對於多團隊如何使用敏捷方法來開發, 有很多人提出不同的框架來解決. 除了 LeSS 之外, 還有 Scaled Agile Framework(SAFe), Scrum@Scale, Spotify 模型, Nexus, Disciplined Agile(DA), Scrum of Scrums 等等. 讓我們來看看之間有什麼差異吧.

1 大規模敏捷框架的市佔率

提到敏捷的調查, 最有名的是 State of Agile Report, 根據最近兩年的調查[1][2], 數據如下:

框架	2022	2023
Scaled Agile Framework(SAFe)	53%	26%
Scrum@Scale/Scrum of Scrums	28%	19%
Spotify Model	7%	2%
Nexus	3%	1%
LeSS	6%	2%
Disciplined Agile(DA)	3%	3%
我們客制自己的大規模框架	沒有資料	12%
在企業層級我們沒有遵從任何大規模框架	沒有資料	22%
不確定	15%	3%

你可以發現到從 2022 年到 2023 年, SAFe 減少了 50%, 而 Scrum@Scale 少了 9%. 為什麼會這樣呢? 應該是在 2023 年, 這份調查增加了”我們客制自己的大規模框架”和“在企業層級我們沒有遵從任何大規模框架”, 導致他們改變選擇.

所以從以上資訊, 個人的解讀是這樣的

大家不懂這些框架是什麼

只是多了”我們客制自己的大規模框架”和“在企業層級我們沒有遵從任何大規模框架”兩個選項, 就可以讓比例掉這麼多, 代表大家不太清楚自己用的是什麼, 所以當有一個比較合自己心意, 便讓大家改變心意.

Scrum@Scale 和 Scrum of Scrums 不能算相同事情

如果大家對於這些框架不太熟悉, Scrum@Scale 和 Scrum of Scrums 合再一起調查, 似乎有誤導之嫌. Scrum of Scrums 早在 2001 年就推出, Scrum@Scale 最近在推出, Scrum@Scale 是架構在 Scrum of Scrum 做延伸, 但兩者不能算同一個東西, 所以這樣調查, 個人會覺得大多數人知道 Scrum of Scrums, 但不一定知道 Scrum@Scale 是什麼. 所以 Scrum@Scale 是否這麼多人用, 似乎有待商議.

客製化很普遍

”我們客制自己的大規模框架”和“在企業層級我們沒有遵從任何大規模框架”兩個選項就佔了 34%, 可以目前各家的解法, 沒有一個可以解決所有問題, 需要依造自己的狀況, 做些實驗, 看看結果如何在作出合適的調整. LeSS 一開始就有數百個實驗, 我想這些才會是企業所需要的. 流程框架只是起點, 後續你需要不斷實驗, 找出較好的作法.

另外我找到另一片文章：Beyond SAFe – Trends in Agile Scaling Approaches[3], 也證實了我的想法. 作者整理了以下調查的文章：

2017 Status Quo Agile Survey
2017 cPrime Scaling Agile Report
2018 Collabnet/VersionOne 12th Annual State of Agile Report
2019 cPrime Scaling Agile Report
2019 KPMG Survey of Agile
2019 Collabnet/VersionOne 13th Annual State of Agile Report
2020 Status Quo Agile
2020 Digital.ai Collabnet/VersionOne 14th Annual State of Agile Report

SAFe 當然還是市占率最高, 不過同調查來源起伏稍微有點大

大規模敏捷框架比較

Scrum@Scale 和 Scrum of Scrums 分開後, 所收集到市佔率就有點慘

大規模敏捷框架比較

至於 LeSS 也是起伏很大的

大規模敏捷框架比較

如果是自己客製化的, 感覺需求一直都很大

大規模敏捷框架比較

從這麼多份調查報告中, 個人有幾點感想

保險牌優先

SAFe 正如他名稱所示, 帶給各位高層或是管理層安全, 因為他們的角色繼續存在, 所以最收歡迎. Scrum of Scrums 學習和採用的成本最低, 所以也幾乎盤據在第二名中

不知道或客製化常被~~技術性~~排除

因為很多人對大規模的框架還是不太清楚, 照理說應該要有“不知道”和“客製化”的選項, 否則就會變成強迫大家選一種. 可是不是每次的調查都有這個選項, 導致逐年結果落差有點大.

2 各個框架方法的特性比較

關於 SAFe, LeSS, Nexus, SoS/Scrum@Scale, DA 我整理了相關的資料[4][5][6], 把他們綜合如下. 這裡我並沒有花篇幅介紹各個規模化框架, 有興趣的朋友可以參考我下面所附的資料, 自行去研究.

(註: 我沒有把 Spotify Model 放上來, 主要是Spotify Model 基本上不算大規模框架, 它只提了組織模式, 但是沒有配套任何流程, 並且 Spotify 自己人也說他們沒有使用 Spotify Model[6]. 這個東西會流行, 個人覺得是管顧公司的推廣, 並且整個故事很漂亮, 還有現成的影片可以看, 導致它流傳很快.)

考量面向\框架	SAFe	LeSS	Nexus	SoS/ Scrum@Scale	DA (以前叫 DAD)
適用的規模	大型企業, 超大型企業	中型企業	中型企業	多個團隊/無限制	中大型企業, 超大型企業
人數	每個 Agile Release Train 至多 125 人	8 個(含) Scrum 團隊以內/LeSS 8 個 Scrum 團隊以上/LeSS Huge	3-9 Scrum 團隊	5-10團隊/無限制	200 人或以上
基於	敏捷價值(Agile Values)	Scrum	Scrum	Scrum	各種敏捷技術 (Agile Techniques), 包含 Scrum, XP, SAFe, agile modeling, Unified Process, Kanban, Spotify 等等, 是個敏捷工具包
實施的代價	高需要調整流程	低基於 Scrum 在多點調整	低基於 Scrum 在多點調整	最低只是多個團隊一起開會	中等需要調整流程
發明者	Dean Leffingwell	Craig Larman, Bas Vodde	Ken Schwaber	Jeff Sutherland	Scott Ambler, Mark Line
溝通範圍	全面性到 CXO 等級	多團隊和管理層之間	多團隊間	多團隊間	多團隊和多部門間
溝通機制	PI Planning	多團隊PBR, 多團隊Sprint Planning, Sprint Review, Overall Retrospective	Cross-Team Refinement, Nexus Sprint Planning, Nexus Daily, Nexus Review, Nexus Retrospective	一起開會	沒以特別說明,看你如何客製化
框架的複雜度	高	中低	中低	中低	高
合適的組織型態	傳統企業	大型企業	傳統和敏捷企業	傳統和敏捷企業	多個組織和企業 (multiple organizations & enterprises)
擴展的對象	Team 層: Scrum 團隊, Kanban 團隊 Program層: RTE, System Arch, Product Mgmt Solution層: SVSE, Solution Arch, Solution Mgmt Portfolio層: Epic Owner, Enterprise Arch, PPM	開發團隊, Area Product Owner (APO)	開發團隊, Nexus Integration Team	擴展 ScrumMaster: Scrum of Scrums Master(SoSM) 擴展 Product Owner: Chief Product Owner: (CPO)	沒以特別說明,看你如何客製化

SAFe

優點

原先每個角色都保留, 大家不用擔心工作不見

可以不同層級的組織去做規模化

一直在改變, 不斷調整框架以適合實際使用

市占率高, 較多案例可以參考, 市面上也比較顧問和書籍可以參考

缺點

整個框架很複雜, 並且一直在改版, 不易了解和學習

整個框架很複雜, 其實不太敏捷

整個框架很複雜, 需要高層支持

太多其他角色, 增加溝通的複雜度, 和依賴某個角色處理事情

需要由上往下來執行, 這和敏捷的精神有些衝突, 容易持續控制的文化

參考資訊

官網: https://scaledagileframework.com/
SAFe 5.0 Distilled: Achieving Business Agility with the Scaled Agile Framework, Richard Knaster 和 Dean Leffingwiell

LeSS

優點

基本上懂 Scrum, 就可以懂 LeSS

以產品為中心, 而非以專案為中心

強調系統思考, 全局優化

強調一份 Product Backlog 和一位 Product Owner, 避免各吹各的調, 導致 1+ 1 < 2 的狀況出現

有數百個實驗可以參考, 有超過 50 個指南輔助你落實 LeSS

缺點

如果 Scrum 實施的不好, 要使用 LeSS 來規模化會有困難

Product Owner 的負擔很重, 需要有 BA 或是其他人來幫忙梳理需求

需要組織變革, 以調整成願意學習和協作的文化

參考資訊

官網: https://less.works/
Large-Scale Scrum: More with LeSS, Bas Vodde, Craig Larman
Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-Scale Scrum, Bas Vodde, Craig Larman
Practices for Scaling Lean & Agile Development: Large, Multisite, and Offshore Product Development with Large-Scale Scrum, Bas Vodde, Craig Larman

Nexus

優點

和 Scrum 沒有太多差別. 很容易就可以開始使用, 這個框架的學習門檻低.

缺點

Nexus 只針對 3-9 個Scrum 團隊

沒有講組織如何規劃, 沒有談其他的角色, 只談迭代的開發流程

屬於比較新的框架，較少落地的案例

參考資訊

官網: https://www.scrum.org/resources/scaling-scrum

SoS/Scrum@Scale

優點

整個做法十分簡單, 只要找出代表來討論多團隊協作的問題即可.

讓規模化可以自己有機生長, 針對不同議題或需要, 建立 SoS 來處理.

SoS 的作法可以擴展到無限數量, 不只在團隊層級使用, 可以擴展到部門, 組織, 或是公司層級.

缺點

因為沒有額外的規範或是實驗可以參考. 除了一起開會似乎沒有了, 很多公司不知道接下來要怎麼辦

SoS 被用很久, 但是 Scrum@Scale 並沒有, 並沒有太多案例

參考資訊

官網: https://www.scrumatscale.com/
Scaling Done Right: How to Achieve Business Agility with Scrum@Scale and Make the Competition Irrelevant, Gereon Hermkes, Luiz Quintela

優點

團隊的許多挑戰超出了 Scrum 的範圍，團隊需要尋找其他方法. DAD 試圖透過採用以人為本、以學習為導向的混合方案, 來應對這些挑戰。

包含完整交付(Delivery) 生命週期, 可以支援 Agile, Lean, 持續交付等等生命週期.

缺點

沒有明確的組織結構和導入流程指南, 需要額外的專業服務, 可能需要不少顧問費用

參考資訊

官網: https://www.pmi.org/disciplined-agile/
Choose your WoW - Second Edition: A Disciplined Agile Approach to Optimizing Your Way of Working, Mark Lines, Scott Ambler
Introduction to Disciplined Agile Delivery - Second Edition, Scott Ambler, Mark Lines

12.3 大家對框架的特殊觀點

這邊我收集了一些比較特別的分析觀點, 或是個人覺得圖表畫的很漂亮, 值得大家欣賞一下.

這個是在 Facebook 上 EMT: Mobile Technologies[8] 在 2018的貼文, 在 X 軸是指框架的彈性, 左邊比較多規範限制, 右邊比較偏向演進形成. Y 軸是說明框架的涵蓋範圍, 從團隊到企業層次. SAFe 就是適用於企業層次, 但是規範多沒有彈性. SoS 就是另一個極端, 只是說要一起開會, 但是其他就沒說.

大規模敏捷框架比較