高效率Scrum團隊的九個模式

June 02 08:40~11:42

九個模式

今天介紹發表於2014 47th Hawaii International Conference on System Science的論文 〈Teams that Finish Early Accelerate Faster: A Pattern Language for High Performing Scrum Teams〉（提早完成的團隊加速更快：一個高效率Scrum團隊模式語言）。雖說是論文不過讀起來很輕鬆，這篇文章的第一作者是Jeff Sutherland，也就是兩位Scrum創始者之一。文章介紹在高效率Scrum團隊身上經常可以觀察到的九個模式（pattern），依據模式所要達到的目的分成三大類：

1. 幫助團隊做好準備
• Stable Teams（穩定的團隊）
2. 協助完成Sprint
• Yesterday’s Weather（昨天的天氣）
• Swarming（蜂擁）
• Interrupt （中斷）
• Daily Clean Code（每日乾淨的代碼）
• Emergency Procedure（緊急程序）
3. 邁向高效團隊
• Scrumming the Scrum
• Happiness Metric（快樂指標）
• Teams that Finish Early Accelerate Faster（提早完成的團隊加速更快）

***

幫助團隊做好準備

第一個分類只有一個模式—Stable Teams，用來幫助團隊做好準備。Scrum開發團隊有三點要求，自組織、跨職能以及持續產品開發模式，第三點也就是Stable Teams所要特別強調的，維持團隊的穩定性，不要過於頻繁更動團隊成員。維持Stable Teams的理由很簡單，一個頻繁異動的團隊，成員之間不易養成默契，對於團隊也比較沒有認同感，團隊士氣與戰鬥力自然較差。

Stable Teams看起來好像很簡單，但實務上有不少Scrum團隊連這一點都做不到，常見原因有公司人員自然且頻繁地離職、因為業務需要調動團隊成員或改組團隊（合併或拆分），以及公司文化原本就喜歡任意調動員工（習慣性救火）。這個模式是高效率Scrum團隊的「起手式」，是基礎中的基礎，如果連這一點都做不到，後續跑Scrum不管再如何努力，可能只會事倍功半。

Stable Teams並不是說團隊成員都不要做任何調整，文章提到每6~12個月調整（少數）團隊成員可以幫團隊帶來新的觀點。

***

協助完成Sprint

第二個分類有五個模式：

• Yesterday’s Weather：利用上一個sprint完成的story point做為下一個sprint能夠完成多少功能的參考依據。人類是樂觀的動物，很多團隊在sprint planning meeting時會過度樂觀承諾太多工作，最後導致sprint結束時留下未完成的工作甚至造成sprint失敗。因此參考上個sprint團隊完成工作量作為下個sprint預估的參考，是一個相對來說比較實際也安全的做法。

一旦Stable Teams依據Yesterday’s Weather得到一個合理的sprint backlog（這個sprint所要完成的工作）之後，團隊在sprint進行中還是可能遭遇問題導致sprint失敗。接下來四個模式可以協助團隊避免常見的錯誤。

• Swarming：讓團隊聚焦在單一工作上，儘速完成該工作。原本工作負責人（認領該工作的人）成為團隊的「艦長（Captain）」，其他人全力協助艦長完成工作，一直到該工作完成為止。此時下一個高優先權的工作負責人變成新的艦長，團隊成員繼續協助新艦長完成新的工作。

在最極端的情況下，Swarming形成「單件工作流」，也就是同時間全部團隊共同完成一件工作。當然實際上可能整個團隊分成若干個小組，每個小組自身採用Swarming的方式完成工作。把全部的人聚焦於一件工作，乍聽之下好像有點浪費人力，但實際上可以縮短工作完成的時間，也就是降低交期（lead time），並且提升工作的品質。

• Interrupt：這個模式協助團隊應付臨時性、中斷性的工作。Scrum要求（強烈建議）sprint開始之後不要異動sprint backlog的內容，讓團隊可以專心開發。這種設計原本是好意，但實務上世事瞬息萬變，很難保證一個sprint都不會有突發狀況或是緊急的插件需要處理。Interrupt模式建議設定三條簡單的規則來對應中斷性工作：
1. 設置中斷緩衝區，依據歷史資料保留處理中斷性工作的彈性，例如保留30%的產能來處理不預期的工作。假設團隊一個sprint可以完成60 story points，為了應付中斷性工作，保留20 story points的產能，在sprint planning meeting時只拿40 story points的工作量。
2. 所有插件都需要經過Product Owner來分流，只有真正重要的工作才會放入中斷緩衝區。
3. 如果Product Owner放入過多的工作到中斷緩衝區，例如中斷緩衝區最大只允許20 story points但是Product Owner放了21 story points工作，則sprint自動終止、重新規劃、並且通知管理階層交付日期將會延誤。

Interrupt模式的效用類似看板裡面的「緊急通道」，都是用來處理臨時性插件的方法。差別在於Scrum有sprint（iteration），因此如果一個sprint中出現超出預期的插件，則需要重新規劃並且讓公司高層知道這種狀況所可能造成的專案延誤。而看板沒有sprint，因此過多的插件可透過限制緊急通道的WIP上限從看板（Kanban Board）上面看到堆積的工作所呈現出來，以及從增加的lead time看出插件對於正常工作流所造成的不良影響。

• Daily Clean Code：在一天之內把所有的bugs都修復完成，目標是每天結束時都有一個乾淨的代碼庫（clean code base）。Daily Clean Code主要希望減少修復bug所浪費的時間，寫程式的人都知道，真正花在coding的時間其實不多，很多時間都浪費在debugging上面。有研究指出，今天所產生的bug如果沒有當天解決，三個禮拜後再去修復它則需要花費可能多達24倍的時間。

如果時間都花在debug上面，團隊的速度又怎麼可能快得起來呢。

• Emergency Procedure：就算前面幾個模式都已經套用了，團隊還是可能發生無法順利完成sprint目標的情況，此時請按下紅色按鈕執行Emergency Procedure（緊急逃生計畫XD）。當「壞事」發生的時候，Scrum Master必須確保團隊在sprint中間執行Emergency Procedure（下列幾點做越少越好）：
• 改變原本做事的方法，嘗試不同的做法。
• 尋求協助，或減少工作量。
• 減少工作的範圍。
• 終止sprint並且重新規畫新的sprint。

***

邁向高效團隊

最後一個分類有三個模式：

• Scrumming the Scrum：這個模式中文不知道怎麼翻譯所以就不翻譯了，它所要解決的問題是如何讓團隊可以持續改善。團隊套用前幾個模式之後，可以順利完成sprint的工作保持穩定的生產力。但是如果團隊無法持續改善，它的效率將一直維持在相同的水準，無法達到高效率團隊的標準。就算團隊每個sprint都舉辦retrospective，也列出改善項目，但實務上這些改善項目經常沒有被落實，原因之一可能是團隊忙於開發功能而沒有安排持續改善的時間。

Scrumming the Scrum 模式建議找出上一個sprint中最重要的一個阻礙（impediment），把它寫成user story加上驗收條件放入下一個sprint的sprint backlog，確保在下一個sprint結束前把這個阻礙移除。

如果團隊落實這個模式，每一個sprint都會排除一個阻礙，落實持續改善精神。如此一來，團隊的Velocity（每個sprint完成的story point）將會逐步提升，朝向高效率團隊邁進。

• Happiness Metric：快樂指標是一種有效預測未來的指標，如果團隊成員在工作上覺得快樂，通常代表他們預測這工作在未來帶給他們的感受。例如，今天寫出一堆爛代碼，因此對於未來要擦屁股感到不快樂。或是與Product Owner之間的溝通不順，對於開發中的需求感到困惑。

文章建議只要問團隊兩個問題即可：

1. 你在公司中有多快樂？(How happy are you with the company?)
2. 你對於自己所扮演的角色有多快樂？(How happy are you with your role?)

分數從0~5。藉由觀察快樂指標，通常可以看到當快樂指標下降時，日後Velocity也會更著下降。Scrum Master可以依據快樂指標的升降做出相對應的調整。

• Teams that Finish Early Accelerate Faster：套用Yesterday’s Weather模式之後可以避免團隊承諾太多工作而導致失敗，因而阻止團隊落實持續改善。因此，拿較少的工作到sprint backlog，落實協助排除阻礙的幾個模式，以協助團隊儘早完成工作。如果提前完成工作，可以從product backlog拉更多的工作，因此增加Yesterday’s Weather模式的參考值（也就是逐步提高Velocity）。

***

Teddy覺得這篇論文寫得很好，文章中所介紹的九個模式也都非常的實用。在Teddy自己落實Scrum的過程中，看到很多成功應用這九個模式的地方，也看到不少違背模式的地方。導入Scrum成效好壞因素很多，但光從這九個模式就可以簡單的避免一些常見的問題，非常值得Scrum團隊花點時間仔細的思考一下這九個模式。

這篇論文中還有一段話是Teddy覺得特別棒的，這段話使引用自Generative Pattern：

Generative patterns work indirectly; they work on the underlying structure of a problem rather than attacking the problem directly. Good design patterns are similar: they encode the deep structure of a solution and its associated forces, rather than cataloging a solution.

這段話的涵義留給鄉民們去思考，想通了也就知道模式的真正價值。

***

友藏內心獨白：聽那聽不到的聲音。