One-Week Sprint 的節奏

我曾在 iThome 的 2012 年度必看好書中，推薦 The Scrum Field Guide（當年還是第一版，現在則有第二版了）。當年看這本書時，還沒置身 Scrum 團隊的經驗，純粹是為了未來做準備，所以，對書中講的種種招數，只能默記在心，等待實務印證。

整本書非常精彩，但最讓我印象深刻的，就是駭人聽聞的 “one-week sprint" 論調：

儘管當時不甚理解箇中用意，但我是好學生，一直把 “one-week sprint” 當成心嚮往之的標竿，日後也不時把所見所聞拿來對照思考。

日後在職涯接觸了更多流程思維：由 Toyota 引領風潮的 Lean Production 及 JIT、高德拉特的 TOC，都強調從 “flow” 來分析系統。浸潤日久，就比較能理解 “one-week sprint” 的緣由。這也滿符合大多數地球人的時間感：

你應該建立工作節奏，好讓每個人都容易掌握自己在一段時間內能夠完成多少事，而最後的成果通常會讓他們自己感到訝異。

    — Quote: 《Scrum：用一半的時間做兩倍的事》

良善的立意，仍然要有充分的前提佈局及配套措施；不是嘴巴喊喊「我們要搞 one-week sprint」就真的能夠 one-week（天下哪有這麼簡單的事～～～）。

那麼，“one-week sprint” 能實現的前提是什麼？

從最近我第一次實踐 Scrum 的過程中，我發現，答案其實就在 The Scrum Field Guide 的那一頁。

Decomposition。

時機

先講講背景故事。

敝公司的大節奏是以季 (quarter) 為單位。十月份是 Q4 的開始，所以各產品、專案都於此刻開始提出本季的計畫。此為其一。

我所隸屬的某產品專案，十月中旬，有兩位新人報到並分配到此專案下，此為其二。

不巧的是，這產品專案，十一月一日，有一位工程師要請增產報國假，所以，要趁著十月份，將工作交接給那兩位新人，此為其三。

因此，單以十月份來說，在這種「1 位準備交接的舊人 + 2 新人」的高風險組合，要是我不儘早作出較周密的調度規劃，屆時一定慘兮兮。

以我本身較熟悉的 PMP 訓練、101 專案管理一日特訓班、102 流程設計與跨部門溝通、106 動態排程基礎等課程，都強調 WBS、work package、activity 的層次拆解，critical path 的辨識，以及 milestone 的設置。所以，我打算以自己較有把握的專案管理手法切入，先規劃為期 3 weeks 的 WBS + activities，並每隔一週設一個 milestone。

思之於此，突然靈機一動：這不正與 The Scrum Field Guide 的那一頁講的兩大要點「decomposition 與 one-week sprint」若合符節嗎？差別只在於，我原本是以專案管理圈慣用的 “deliverable” 字眼作為表述單位，而不是以敏捷圈慣用的 “user story” 字眼；但兩者在 task/activity 層次則是類似的，而且，我也的確將 task/activity 切得夠細了，細到符合 The Scrum Field Guide 的建議：

Follow the rule that tasks should be completed in no more than two days.

那麼，現在，我到底要用傳統的專案管理手法來執行這高風險任務，還是⋯⋯

進而一想：反正我本來就想找機會試行 Scrum 或 Kanban，那麼，擇日不如撞日，何不趁此機會，來一次個人的 Scrum (subset) 首航？

⋯⋯而且，就一口氣挑戰看看 one-week sprint 吧？

盤算

挑戰之前，還是要先秤秤自己以及團隊有幾兩重。

兩位新人是我面試的，一位是我研究所學弟，一位出自台灣某敏捷開發聖地的實驗室，對他們的背景及能力，有某種程度的信心。

至於我自己，要感謝稍早敏捷三叔公 David Ko 發起的這個活動，讓我蒐集到一些阻力清單：

• 當敏捷遇上引導：在領導團隊變革遭遇什麼困難

• 找出組織無法變敏捷的阻礙 – 團隊共創法實做

有了這份清單，配上 Project Management in the First Lane: Applying the Theory of Constraints 第五章的 CRT 圖，有助於我設想些應對措施，才比較敢挑選戰場來試驗。

接下來，就隨時抱著開放心態，見招拆招嘍～～～

工具

我用兩份專案管理工具。

第一份是只給自己看的 Microsoft Project 文件，用來掌握全貌。或許是受到 PMP 訓練的影響，即使現在是跑 (a subset of) Scrum，又是首航，還是覺得要有這種東西，看到 3 個 sprints 的 WBS、work package、activities、critical path 才安心。

另一份是給團隊成員看的 Google Spreadsheet，主要是在 daily Scrum 時，用 Kanban 之類易懂的視覺化媒介，讓團隊全體一起溝通工作進展及阻礙。

調整實驗了幾天，還是覺得秀出我在 101 專案管理一日特訓班學到的 “JB Big Table” 給團隊成員看，不僅比正統的 Kanban 更容易有全局觀，尤其是層次及時間感，就連 Kanban 素來講究的 WIP 也都內建其中。

“JB Big Table” 真的很管用，儘管這次我也只有用上一小部分。

反思

一週後，第一個 sprint 順利達標，儘管變數層出不窮。

萬萬沒想到第一次嘗試帶 Scrum，而且是「1 舊人 + 2 新人」的高風險組合，就很有機會實現。除了天時地利人和的配合，事先認真的 WBS 分析，應是重要因素。

The Scrum Field Guide 說的是真的！

Your problem isn’t your sprint length. You need to improve your task decomposition.

也順便速記幾則初步的檢討反思：

1. 理解精神真的很重要。理解了，才知道該如何遵守規則，或許更重要的是，知道為何及如何違反規則。

2. One-week sprint 對於「聚焦」的要求更高，真的更該集中鎖定在要徑上。

3. 儘管只有 one-week sprint，但已經出現《關鍵鏈》點出的「資源爭奪」問題了。在第一個 sprint 中我沒有處理得很好，但在第二個 sprint 中，我採用 TOC 聚焦五步驟中的第二步 “exploit” 及第三步 “subordinate” 來處理。

4. 身處專案導向的矩陣型組織，初步的觀察體會：

   • 資源主管，如果有敏捷的正知見，滿適合當照顧小羊的 Scrum master。
   • PO 的確不適合身兼 Scrum master，會有難以排解的利害衝突。

5. 某個層次來說，選擇了 Scrum、選擇了 DevOps，甚至廣義一點來說，選擇了 lean、選擇了 TOC，就要有心理準備：這些流程或方法論，都有「持續改善」的機制在裡面，都要求你的 commitment。沒有這種心理準備，往往就是無法移除障礙的原因。

6. One-week sprint 固然痛快，但我在《為什麼上班這麼累？其實是你心累》看到一則警語：「因急迫性所產生的高效率，其實也是一種心理上的成癮。」所以，要注意何時該踩剎車。

許多議題，我也還沒有答案。但是，抱持開放心態，與團隊一同探索，應是一大樂事吧！