資料來源：Scrum.org
每週開始前，團隊把工作排得整整齊齊；每天早上，所有人輪流報告進度；隔一段時間，再展示成果、檢討問題。白板上貼滿任務，會議一場也沒少，主管看起來也隨時掌握進度。
奇怪的是，產品依舊延遲交付，使用者反映的問題仍然沒解決；遇到意外，團隊第一個反應仍是等待主管指示。
這正是《殭屍Scrum生存指南》所描述的情境：一套原本要讓團隊先做一小步、取得回饋，再自行修正方向的工作方法，最後只剩下會議、表格與固定動作。外表還在活動，內部的學習能力卻已奄奄一息。
當開會變成「證明有做事」
流程原本是為了讓問題早點浮現，最後卻被用來證明大家都有做事。
每天的短會，本來應該協調障礙、互相支援，後來變成逐一向主管報告；成果展示，本來應該邀請使用者檢驗方向，後來只剩製作精美的進度簡報；檢討會本來應該追問工作方式哪裡出了問題，最後卻只敢討論「下次準時一點」之類無傷大雅的小事。
每場會議都如期開完了，真正困難的問題卻沒有進入決策。
組織想要敏捷，管理者卻想要確定
所謂敏捷，不是把人催得更快，而是發現方向錯誤時，能更快改變決定。
但許多組織導入新方法時，仍捨不得放下舊有的控制習慣：工作最好事先全部排定，進度最好能精確預測，重要判斷仍由上級牢牢掌握。團隊可以自行決定先做甲或先做乙，卻不能質疑甲乙是否都不值得做；可以討論如何如期交差，卻不能追問交出去的東西，究竟解決了誰的問題。
組織接受了敏捷的外表，卻拒絕它真正的要求：承認原先的判斷可能錯誤，讓第一線根據新證據調整方向，容許小規模試錯。
流程愈完整，問題反而愈安全
殭屍化最危險之處，不是大家看不見問題，而是組織擁有一套完整流程，可以不斷證明「問題已經處理過了」。會議開過、紀錄留下、責任分派，於是所有人都能安心回到原來的做法。
判斷一個團隊是否敏捷，不必先盤點開了多少會。只要問三件事：最近一次使用者回饋，改變了哪個決定？第一線發現問題時，有多少事情不必等待批准？上次檢討之後，究竟試了哪一項不同的做法？
如果答案都是「沒有」，流程再完整，也只是把僵化管理包裝得更現代。
真正的敏捷，是縮短「發現錯誤」到「改變決定」之間的距離。流程若不能讓壞消息進入決策，就不再是修正工具，而是拒絕修正的保護殼。