很多企業在推行敏捷開發時，經常面臨團隊反彈、效率低落，甚至淪為徒具形式的「殭屍敏捷」。回頭檢視這些團隊的運作模式，往往會發現一個有趣的現象：他們所遵循的，其實是 2010 年版本的 Scrum。每天早上死板地回答三個問題、將 Sprint Review 當作對長官的火力展示（Demo）、嚴格劃分 Product Owner 與開發團隊的界線。
仔細觀察 Scrum Guide 從 2010 年到 2020 年的演進軌跡，我們可以看出敏捷框架本身經歷了一場深刻的自我批判與重構。我認為，這個演化過程揭示了一個核心論點：早期的 Scrum 想法比較偏向將人視為一種可以效率執行的「程式碼元件」。為了管理這些元件，框架給予了極多形式上的規範，企圖藉由高頻率、格式化的資訊交換，強制大家在同一個節奏下產生成果。然而，隨著時間推移與實務驗證，Scrum 逐步褪去了形式主義的外衣，只保留最核心的資訊交換邏輯。這反映了在現代組織運作中，我們真正需要專注的是「關鍵資訊」的對齊，而不是用僵化的條條框框來規訓人性。早期 Scrum 的隱蔽本質：將人視為可執行的「元件」
回顧 2010 年到 2013 年的 Scrum 規範，字裡行間充滿了對「控制」與「可預測性」的渴望。在那個時期，Scrum 試圖用管理機器的邏輯來管理知識工作者。
最明顯的例子就是 Daily Scrum 引入的「三個問題」格式：你昨天做了什麼？你今天要做什麼？你遇到什麼阻礙？這種設計的出發點，是將原本複雜、隱性的軟體開發過程，拆解成每天可以量測的輸入與輸出。它預設了團隊成員就像是一個個運算單元，只要每天準時回報狀態，系統就能順利運轉。然而，這種高頻率且格式化的資訊交換，在實務上往往退化成一種「向上報告」的儀式。團隊成員為了應付這三個問題，容易陷入交代流水的窘境，失去了檢視整體目標的意義。
同理，早期的 Sprint Planning 明確將會議分為兩段，第一段決定「做什麼」（WHAT），第二段強制要求將工作分解為具體的任務（HOW）。這種做法背後的假設是，所有的工作都可以事先被精準拆解與預估。這將開發人員推向了純粹的「執行端」，彷彿只要有明確的工單（Task），人就可以像機器一樣照圖施工。此外，當時將 Scrum Team 嚴格劃分為 Product Owner、Scrum Master 與 Development Team，在無形中製造了「發包方」與「承包方」的對立結構，進一步強化了將開發人員視為生產線元件的傾向。
形式主義的極限與人性反撲
這種高度依賴「形式」與「規範」的架構，在推行幾年後必然會遇到瓶頸。最大的問題在於，人類並不是機器，也不是每個人都能適應這種高壓、透明且需要頻繁表態的工作環境。
早期的 Sprint Review 被強烈暗示為一種「展示（present）」或「Demo」。這導致團隊在每個 Sprint 結束前，耗費大量心力準備簡報和完美的展演，以取悅利益關係人。這種形式主義不僅沒有促進真實的回饋，反而讓團隊學會了隱藏問題。當 Increment（增量）只被要求「Potentially Shippable」（潛在可發布），而未強制綁定「Usable」（可用）和 Definition of Done（完成定義）時，團隊很容易為了滿足表面的進度而犧牲內部品質。
知識工作本質上充滿了高度的不確定性與反覆運算。當框架要求每天按照固定格式發言、要求每個工作都必須拆解成精細的任務時，其實是在消耗團隊處理真正複雜問題的認知資源。很多工程師或設計師的思考模式是跳躍的、沉浸式的，強迫他們將工作狀態切割成符合 Daily Scrum 格式的語言，不僅違反人性，也無法真正萃取出對專案有價值的「關鍵資訊」。
2020 年的重構：剝除外殼，直擊關鍵資訊
2020 年 Scrum Guide 的大幅度改版，可以視為對過去十年形式主義的一次全面修正。這次改版的重點非常明確：要求「形式」的部分越來越少，專注於「關鍵資訊」與「目標」的對齊。
首先，Daily Scrum 正式移除了僵化的「三個問題」。這是一個極具象徵意義的改變。它承認了團隊的自我管理能力，將會議的目的回歸到「檢視 Sprint Goal 的進展並調整計畫」。只要能達成這個目的，團隊要怎麼溝通、用什麼形式開會，都不再受限。
其次，Sprint Review 完全移除了「展示」的字眼，嚴格要求這是 Scrum Team 與 Stakeholders「共同檢視」Increment 的工作會議。這打破了過往台上台下的從屬關係，將焦點從「精美的 Demo」轉移到「真實的產品狀態」這項關鍵資訊上。
最關鍵的結構改變，是徹底移除了 Development Team 這個子團隊的概念。整個團隊就只有 Scrum Team，沒有負責想需求的人與負責寫程式的人的對立。這不僅消除了組織內的穀倉效應，也讓所有成員共同為一個大目標負責。
同時，2020 版正式確立了三個層級的承諾（Commitment）：Product Goal、Sprint Goal 與 Definition of Done。過去被視為承諾的 Sprint Backlog Items（具體工作項目）退居二線，成為可以隨時調整的計畫。這完美體現了現代管理的邏輯：我們鎖定的是「為什麼要做（WHY）」以及「要達到什麼業務目標」，至於中間的細節和執行方式，只要不偏離核心目標，團隊有絕對的自由去應變。
科技進步與資訊交換成本的降低
Scrum 能夠敢於捨棄這些形式規範，除了對人性的重新理解，現代技術的進步也是背後的重要推手。
在 2010 年代初期，專案管理工具、協作平台與持續交付（Continuous Delivery）的基礎設施還不夠完善。當時，團隊確實需要依賴高頻率的實體會議來同步狀態、解決衝突。面對面的口頭報告，是當時獲取資訊最可靠的管道。
時至今日，DevOps 文化的普及、自動化測試、CI/CD 流程的成熟，以及各類非同步協作工具（甚至是 AI 輔助開發工具）的廣泛應用，已經大幅降低了資訊交換的交易成本。程式碼的品質、系統的部署狀態、任務的流轉進度，都可以透過儀表板與系統通知即時透明地展現。
當「你昨天做了什麼」這種流水帳資訊已經可以由系統自動記錄與呈現時，Daily Scrum 再去盤點這些細節就顯得多此一舉。技術的進步接管了那些機械性、狀態同步的資訊傳遞工作，讓人與人相聚的寶貴時間，得以專注在那些機器無法處理的領域：例如目標的辯論、架構的抉擇、跨部門的政治協調，以及應對突發市場變化的策略調整。這正是為什麼 2020 版 Scrum 明確寫入支援 Continuous Delivery，並將焦點全面轉向 Goal（目標）的原因。
重新定義管理者的視角
Scrum 十年來的演化，是一部從「行為控制」走向「目標對齊」的組織發展史。它告訴我們，將人當作可以被格式化輸入輸出的「元件」，在複雜多變的商業環境中是行不通的。
我們必須認清，條條框框的流程與格式，往往只是管理者為了緩解自身對專案失控的焦慮，而強加於團隊的安慰劑。真正的敏捷，在於識別並聚焦於「關鍵資訊」：我們的長期目標是什麼（Product Goal）？這個階段的價值在哪裡（Sprint Goal）？我們對品質的底線是什麼（Definition of Done）？
只要這些核心資訊是透明、對齊且被共同承諾的，團隊內部要用什麼樣的架構來運作，其實應該保留極大的彈性。畢竟，強迫所有性格互異的專業人士適應同一套僵化的會議流程，只會扼殺他們的創造力。重新檢視你的 Scrum 實踐，如果它依然充滿著 2010 年代的表單、三問與僵化的階級感，或許是時候放下對「元件」的控制欲，回到資訊與價值的本質了。
葛大元的整理：
好久沒聊聊 Scrum
我把我對於 Scrum 的研究、理解、與實踐
整理一下，分享給大家 Scrum 的演化歷史
——
看看你的Scrum實踐不是隨著時間進展而演化，還是停留在過往雲煙中的舊時代？
2010 — Scrum Guide 首版
Daily Scrum
- 引入「三個問題」格式（昨天、今天、阻礙）
Sprint Review
- 使用「展示（present）」語言
→ 容易被解讀為 Demo
Scrum Team 結構
- PO / SM / Development Team 三分法
Sprint Backlog
- SBI（Sprint Backlog Items）被視為承諾
→ Sprint Goal 不是承諾
Sprint Goal
- 已存在，但僅為「指引」
→ 非承諾、非核心
Increment
- 用語：Potentially Shippable Product Increment
- 未強調 usable
- 未強調 releasable
- 未與 DoD 強綁定
Sprint Planning
- 明確分成兩段：
- Part 1（WHAT）：選工作項
- Part 2（HOW）：分解成 Tasks（明確要求）
Refinement
- 未正式命名（僅以 grooming 概念存在）
Retrospective
- 提到改善，但未強調 Action Items 必須進入下一 Sprint
Definition of Done
- 已存在，但描述簡短、未強調其作為品質基準
2011 — 語言微調，結構未變
Daily Scrum
- 三問仍然存在
Review
- 仍保留「展示」語氣
Increment
- 仍使用「potentially shippable」語言
Sprint Planning
- Part 1 / Part 2 結構維持
- Task 分解仍然要求
Refinement
- 開始使用「Backlog Grooming」字眼
→ 但仍未正式定義
Retro Action Items
- 未強調必須進入下一 Sprint
Definition of Done
- 語言微調，但未強化其地位
2013 — 第一次重大強化（Increment 與 Review）
Increment
首次明確寫出：必須 usable（可用）
- 移除「shippable」語言
- DoD 與 Increment 的關係開始被強化（但仍未完全綁定）
Review
- 語言開始轉向「檢視 Increment」
→ Demo 色彩開始淡化
Sprint Goal
- 描述更清楚，但仍非承諾
Sprint Planning
- 仍是 Part 1（WHAT）+ Part 2（HOW）
- Task 分解語氣變得較不強制
Refinement
- 正式命名為 Backlog Refinement
- 定義為「持續進行的活動」
- 仍非正式事件（event）
Retro Action Items
- 開始提到「改善事項應該被納入下一個 Sprint」
→ 但語氣仍非強制
Definition of Done
- 更清楚描述 DoD 與透明性的關係
2016 / 2017 — 強化透明性與協作，但保留舊結構
Review
- 強調「Scrum Team 與 Stakeholders 一起檢視 Increment」
→ 但仍未明確禁止 slide show
Daily Scrum
- 三問仍然存在（仍為建議格式）
Scrum Team 結構
- 仍有 Development Team 子團隊
→ PO 與 Dev Team 分離仍存在
Sprint Backlog
- SBI 承諾仍然存在
→ Sprint Goal 仍非承諾
Sprint Goal
- 被描述為「單一目標」
→ 但仍非承諾、非 Planning 核心
Increment
- 強調 usable
- 仍未提 releasable
- 仍未提多 Increment
- 仍未提 Continuous Delivery
Sprint Planning
- 仍是 Part 1（WHAT）+ Part 2（HOW）
- Task 分解不再強制，但仍被視為常見做法
- 無 WHY
Refinement
- 建議佔用 Sprint 時間不超過 10%
- 仍非正式事件（event）
Retro Action Items
- 明確寫出：改善事項應該進入下一 Sprint Backlog
→ 但仍非強制語氣
Definition of Done
- 更強調 DoD 與透明性
- 但仍未與 Increment 建立「承諾」關係
2020 — Scrum Guide 最大幅度改版（全面重構語言與結構）
- Daily Scrum：三問正式移除
- 不再建議三問
- 不再建議逐一報告
- 不再建議任何固定格式
- 目的改為「檢視 Sprint Goal 的進展並調整計畫」
- Sprint Review：正式脫離 Demo 模式
- 完全移除「展示（present）」字眼
- 強調「實際檢視 Increment」
- 強調「Scrum Team 與 Stakeholders 共同檢視」
→ 明確否定 slide show / Demo 式 Review
- Scrum Team 結構重寫：移除 Development Team
- Scrum Team = PO + SM + Developers
- 不再有子團隊
- 不再有 PO vs Dev Team 的語言結構
- Self organizing 被 self managing所取代
- Sprint Backlog 承諾：從 SBI → Sprint Goal
- Sprint Backlog 的承諾改為 Sprint Goal
- SBI 不再是承諾，只是計畫
- Sprint Goal：正式成為核心元素
- 成為 Sprint Backlog 的承諾
- 成為 Sprint Planning 的起點
- 成為 Daily Scrum 的檢視基準
- Sprint 中不可變更（但 Sprint Backlog 可調整）
- Increment 定義全面強化
- usable（延續 2013）
- releasable（首次加入）
- 與 DoD 正式綁定（DoD 成為 Increment 的承諾）
- 一個 Sprint 可以有多個 Increment
- 支援 Continuous Delivery
- Scrum 正式支援 Continuous Delivery
- 首次寫出：Scrum 支援 Continuous Delivery
→ 不再限制「每 Sprint 才能交付一次」
- Sprint Planning：兩段式被移除 → 三大主題
移除：Part 1 / Part 2（WHAT / HOW）
新增：三大主題
- WHY：Sprint Goal（首次成為起點）
- WHAT：選擇 Product Backlog Items
- HOW：討論如何完成（不再要求 Task 分解）
- Refinement：定位更清晰，但仍非事件
- 持續進行的活動
- 非正式事件（event）
- 不再提 10% 時間建議
- Scrum Team 全員可參與
- Developers 負責梳理
- PO 負責確保 Product Backlog 清晰
- Retrospective Action Items
- 2020 版語言更強，但仍非強制
- 建議改善事項在下一 Sprint 中被處理
- Lean：首次被正式提及
- Scrum Guide 2020 明確寫出：
Scrum 是基於 Lean Thinking
- Definition of Done：地位提升
- DoD 成為 Increment 的正式承諾（Commitment）
- Increment 必須符合 DoD 才能被視為完成
- DoD 與透明性、品質、可交付性正式綁定
- Product Goal：首次出現，產品定位的北極星，也是 Scrum Guide 的第三個承諾（Commitment）：
- Product Backlog 的承諾：Product Goal
- Sprint Backlog 的承諾：Sprint Goal
- Increment 的承諾：Definition of Done
- Product Goal 的定位為：產品的長期目標
- 所有 Product Backlog Items 都必須指向 Product Goal
- 一次只能有一個 Product Goal
- 完成一個 Product Goal 後，才能設定下一個
您遵循的 Scrum 是停留在西元哪一年？也許可以分享一下駐足的緣由與困處？
