回想一下你的組織的工作方式，是不是都會先做好所有規畫、工作細節，再分派成員按部就班地執行？結果卻總是無法按照計畫走，一個部門的延宕導致下一個環節卡住，整個計畫延期不說，趕在最後交出來的成品，卻還是錯誤百出？

到底這種工作方式，出現了哪些問題？我們以美國聯邦調查局（FBI）的例子來說明。

先擬定完整計畫再執行，容易導致工作時程拖長
由scrum發明人傑夫‧薩瑟蘭（Jeff Sutherland）撰寫的《SCRUM：用一半的時間做兩倍的事》一書提到，在美國發生九一一恐怖攻擊事件之前，聯邦調查局當時有一套自動化歸檔資料的系統，卻因為系統速度遲緩，多數人仍採用紙本歸檔，每項資訊需要經過層層主管簽核，導致效率低落。

九一一事件之後，這樣的資訊系統就遭到世人詬病，明明當時各方消息都指出有恐怖組織成員進入美國，卻因為資訊系統未能串接，導致無法提前利用有效情報。

因此，為了改善既有資訊系統的缺點，聯邦調查局於 2006 年啟動了名為「哨兵」（Sentinel）的系統開發計畫，預計要花 4.51 億美元，並於 2009 年正式上線。但直到 2010 年 3 月，該計畫已花了 4.05 億美元的經費，卻只完成一半的進度，至少得再進行 6 至 8 年才能完成，預算更需要追加 3.5 億美元。

當時接手這項計畫的聯邦調查局主管，發現無法如期上線的原因， 並非團隊成員不夠專業，而是這套系統的開發流程太緩慢 ：團隊成員先找出系統有哪些需求，接著決定這些需求要透過哪些功能滿足，並排定每一項功能的執行與完成時間。擬定非常完整的計畫之後，才能開始進入開發、測試階段。這種一定要先做好完善的流程規畫，再開始分頭執行工作稱做「瀑布式」（waterfall）工作法。

瀑布式的工作方法聽起來合理，也符合多數工作者與組織做事的邏輯，但它為什麼會成為失敗的主因？最大的問題，出在 我們並不能確定一開始擬定的計畫，百分之百符合未來使用者、市場需要的產品功能。

計畫表假設「完美進度」，無法應付突發狀況
過去設計一項產品，可能得花上好幾個月的時間，進行市場分析、調查，才得以規畫產品功能。這時候往往會用工作者熟悉的甘特圖（Gantt Chart），畫上每個階段的任務與完成時間。不過，甘特圖並不能告訴你，實際的工作流程出了哪些問題，多數時間它的功用，只會顯示「完美情況」下的進度表。

加上從計畫到實際推出產品的時間，通常存有一大段落差，當時的假設、預測是否仍有效力，沒有人可以準確預測。

再回到聯邦調查局的哨兵系統，2010 年他們更換了新的技術長與資訊長，還把專案參與成員從 400 人刪減至 40 人。不過，他們竟在一年之內，只花了 3000 萬美元，等於節省了 90% 原先預計要增加的預算，便完成剩餘一半的進度，更在 2012 年正式上線。

哨兵計畫能在短時間、低成本內完成的關鍵，在於他們導入 scrum 工作方法，以兩個禮拜為周期專注在開發，稱為「衝刺」（sprint）。每次衝刺結束之後，都要求團隊做出能替產品增加價值的功能或服務，也就是所謂的「增量」（increment），改善了過往走到最後一步，才能看見產品全貌的方法。

同時，他們會邀請未來實際使用的探員、其他政府單位的代表，每次衝刺期後就給予這些產出回饋，如此一來，就能避免瀑布式無法跟上使用者需求的缺陷。開發團隊接著便可以利用這些回饋，在下一次的衝刺中，即時調整開發方向。

完成、未完成進度都公開，促使團隊一起排除困難
瀑布式工作方式的另外一個缺點，則是它的工作銜接方式，由一個環節接著一個環節推進。換句話說，當上一個階段的人拖延進度時，接手的人也無法開始動作，導致計畫延誤。

要突破這些困境，擁抱「敏捷」精神（agile）是最有效的解決方法之一。2001 年，由 17 位軟體開發相關的學者、專家共同提出了《敏捷軟體開發宣言》，內容提到 4 個重點： 團隊互動重於流程與工具、創造可用的軟體重於詳盡的文件、與客戶合作重於合約協商，以及回應變化重於遵循計畫。 不難看出敏捷精神，圍繞在團隊溝通以及擁抱改變。

而在敏捷精神之下，更發展出各式各樣的工作方法，根據 scrum 的主要認證機構之一 Scrum Alliance 於 2016 年的調查，其超過 2000 間的企業會員，就採用了scrum、kanban（看板）、lean（精實）等不同的敏捷工作方法。

其中 scrum 可說是最為廣泛採用的工作方法，有超過 89% 的企業，選擇用它做為唯一或其中一種工作方法。

在 scrum 的流程中，團隊會增加彼此溝通、互動的頻率，規畫產品需求、排列任務優先順序的需求，也都是團隊互相討論的結果，成員還必須公開說明每個人的考量與工作內容。

衝刺期間利用「每日立會」（daily scrum）的方式，掌握彼此的進度，成員可以從中充分知道，哪些事情拖累速度，可即刻對彼此伸出援手。最後，便能在短時間內產出一定價值的產品，供市場、使用者提供回饋，再利用這些回饋，精進自身產品。

讓顧客感受提出的要求，能快速有效地被滿足
回到哨兵計畫的結果，scrum 可加速開發的進程，但這不僅是 scrum 的功用，重要的是它協助組織應對改變時，能更加靈活。由於 scrum 的每一次衝刺期之後，都需要和客戶或未來的使用者溝通，了解他們的需求或價值是什麼，這次衝刺的成品是否有切中他們的痛點，並在下一次修正。

所以，當團隊能夠靈活反應快速變動的需求時，前期開發的時間降低，因此才造成採用 scrum 之後，工作速度加快的感覺。而在 Scrum Alliance 的報告中也顯示，超過 7 成的企業認為，採用 scrum 之後，能把企業創造的價值有效傳遞給使用者。

或許你還有個疑惑，scrum是否只適用在科技、軟體開發領域？從國外企業採 用scrum 的實際案例來看，不只是 Goolge、Apple 等大型科技公司採用，包括銀行、數位行銷公司等都有採用 scrum。

Scrum Alliance 的報告中也提到，在一間接納scrum的企業中，平均已有 21% 非 IT 性質或部門的專案使用 scrum 完成。其中，又以製造、研究、行銷和人資部門為大宗，代表不只是開發部門，任何性質的團隊，都有可能透過 scrum，改善過去沒有效率的工作方法。

因此，想要打造出更具有團隊合作精神的組織，scrum 就是你最好的選擇。如果你也希望可以變得更加靈活，就跟著我們的腳步，一步步學會怎麼善用它。

瀑布式 vs SCRUM 工作法
瀑布式工作法與 scrum 有著非常不同的流程，前者透過事先完整的計畫，成為後續執行的依據，但由於執行時程較長，無法因應中間變化，完成品可能已與市場需求有落差。scrum 不要求第一次就把產品做到位，而是透過短時間內重覆「產出、檢視、改善」的循環，找到滿足使用者與市場需求的方向。

延伸閱讀 /
1. 精美的甘特圖，只是進度規畫的假象！管理專案，2 個更有效率的圖表
2. PM必看！做對 3 件事，大大提高專案和産品開發的成功率

（本文經授權轉載自《經理人月刊》2018年3月號，未經授權禁止轉載。）