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

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

當時雖然不甚理解箇中用意,也覺得很不可思議,但我是好學生(嘻),一直把 "one-week sprint" 當成心嚮往之的標竿,日後也不時把所見所聞拿來對照思考。

後來,接觸到許多流程思維:由 Toyota 引領風潮的 Lean ProductionJIT、高德拉特的 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 層次則是類似的,而且,我也的確切得夠細了:

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 固然痛快,但我在《為什麼上班這麼累?其實是你心累》看到一則警語:「因急迫性所產生的高效率,其實也是一種心理上的成癮。」所以,要注意何時該踩剎車。


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