SCRUM 團隊的七個問題徵兆

Scrum 或其他敏捷實踐在過去的 10 到 20 年中非常流行。越來越多的組織選擇「敏捷轉型」。這在現實中意味著什麼呢？在許多情況下，這僅僅意味著組織使用的語言改變了，但心態仍然相同。

幸運的是，有些公司真的希望產生影響並改變他們的思考方式、工作方式和產品交付方式。當然，改變是一個過程，他們無法在不犯錯的情況下實施 Scrum 或任何敏捷實踐。

今天，我想列出 Scrum 團隊中的七個問題徵兆。如果您在 Scrum 團隊中注意到這些徵兆，請小心。這可能意味著在實施過程中 Scrum 的某些元素已經遺失。但不用擔心！您始終可以使用經驗主義來檢查與調適。

 

1. 產品負責人或 Scrum Master 分配工作

傳統的瀑布式產品交付和 Scrum 之間的巨大差異是 Scrum 團隊的自我管理或自組織。

當您注意到產品負責人或 Scrum Master 將產品待辦事項分配給團隊成員時必須意識到這是個壞兆頭。這意味著團隊沒有自主權決定他們將如何工作，他們並非自我管理。

產品負責人只應該讓團隊知道需要完成什麼（WHAT），但具體如何完成（HOW）以及誰將負責特定工作項目（WHO），應由 Scrum 團隊內的成員如開發人員來決定。

Scrum Master 也不應該控制團隊並分配工作給任何人。他們應該是指導團隊與教導他們如何自我管理的人。我知道這麼說很容易，但是對於許多曾經是專案經理的 Scrum Master 來說在放下控制這部分是困難的。不過如果您真的想幫助團隊，就別無他法了。

 

2. 透明度不足

這裡所說的「透明度不足」是什麼意思？天哪！人們可以隱藏很多事情！

如果 Scrum 團隊中的人在衝刺回顧會議（Sprint Retrospective）之外背地裡談論問題，而不是與整個團隊討論，這是一個不好的跡象。這可能意味著團隊彼此之間缺乏足夠的信任去真正地討論問題。

透明度問題也可能與與業務端（Business）的溝通有關，例如：Scrum 團隊隱瞞了與產品開發相關的問題，而業務端認為一切都很正常。

在這兩種情況下，問題終將暴露，隱藏事實不會對團隊有任何好處。我絕對推薦誠實並討論團隊正在掙扎的問題。即使這對人們來說可能不舒服！

 

3. 缺乏衝刺目標－一切都是最高優先級

每當我問產品負責人或 Scrum 團隊：「最高優先順序是什麼？」他們回答：「一切（Everything）」，這總是個壞兆頭。但這還沒結束。即使他們這樣回答，但如果他們有一個衝刺目標（Sprint Goal），並且最終能選出最重要的產品待辦項目（Product Backlog Items），他們應該還是沒問題的。

問題在於，Scrum 團隊在衝刺期間沒有任何衝刺目標，他們認為衝刺待辦項目（Sprint Backlog Items）中的每件事都是最高優先級。

這會導致什麼結果呢？在衝刺期間會出現多任務處理與注意力不集中。衝刺目標是一個很棒的工具，因為它幫助團隊成員集中注意力，並指引他們在衝刺期間做出的任何決策。

 

4. Scrum 團隊規模過大

根據最新版的 Scrum 指南，Scrum 團隊的人數應該最多不超過 10 人。為什麼呢？

一般來說，我們發現較小的團隊溝通更順暢，生產力也更高。

擁有超過 10 人的 Scrum 團隊是個壞兆頭。大多數情況下，這意味著團隊成員之間的溝通不順暢。有時候表面上看似一切正常，但實際上當團隊人數過多時，很容易忽視團隊成員的需求，並且沒有足夠的空間／時間讓每個人分享他們的想法。

 

5. 在進行衝刺計劃會議時，產品待辦清單永遠沒有準備好

這個問題非常常見，絕對是麻煩的徵兆。如果產品待辦清單沒有為衝刺計劃會議（Sprint Planning Meeting）做好準備，團隊會不知道接下來需要集中精力做什麼，衝刺可能會相當混亂。

當我說「產品待辦清單已準備好」時，並不意味著它已被定義完全。我只是指待辦清單的頂部已經被定義足夠（Defined Enough），讓團隊可以開始工作。

這也意味著產品負責人對產品有個清晰的願景，這將驅動所有後續行動。我們應盡可能避免混亂的產品待辦清單，這對 Scrum 團隊沒有幫助。

 

6. 將故事點轉換為時數

讓我說清楚－故事點（Story Points）不是 Scrum 的一部分。但是，Scrum 團隊可以使用故事點來估算與計劃他們的工作。因此，如果 Scrum 團隊決定使用故事點，他們絕對不應該將故事點轉換為時數（Hours）。為什麼？原因非常簡單。時數是絕對估算（Absolute Estimation），而故事點是相對估算（Relative Estimation）。

這意味著什麼？

絕對估算反映在絕對值中，例如小時。身為人類，我們真的不擅長用小時來估算複雜的任務（Complex Tasks）。

說到相對估算，估算不僅基於付出的努力（Effort），所以我們不能將它們轉換為時數。我們還需要考量到風險（Risk）、不確定性（Uncertainty）、技術（Technology）和量體（Volume）。

想象一下，你決定一個故事點代表若干小時。在這種情況下，實際上你沒有使用相對估算，它是以小時為單位的固定估算。

當我們使用故事點來估算時，這些估算會根據團隊、他們的知識、技能以及他們對任務或故事了解的程度而有所不同。

他們在考慮到所有團隊成員的情況下進行估算。舉個例子：一個人可能需要 8 小時來完成這個故事，因為他們是新手，需要時間去學習這項技術。而另一位團隊成員可能只需僅僅 3 小時，因為他們有經驗而且該技術對他們來說很簡單。

這只是展示估算方式的一個例子。估算也是團隊成員討論具體產品待辦項目和釐清項目內容的絕佳機會。

將故事點轉換為時數事實上並無法提供任何價值，同時增加了微管理（Micro-management）的風險與驗證特定項目是否在計劃時程內完成的風險。

 

7. 衝刺回顧會議沒有任何結果

這是另一個常見的問題，我想在這裡強調它，因為它確實阻礙了 Scrum 團隊的改善。所以最常用的情景是，我們進行一次回顧會議，談論一切進行得好的事情、不好的事情以及可以改善的地方。問題在於，我們只是談論問題與改善的想法，但最終我們沒有任何明確的行動方案。

根據 Scrum 指南：

Scrum 團隊辨識出最有用的改變以提升其效能。最具衝擊力的改善行動將儘速執行。甚至可以納入到下一個衝刺的衝刺待辦清單中。

我們應該試圖具體化需要實施的改變並執行它們。如果沒有這些，整個討論都是浪費大家的時間，衝刺回顧會議沒有提供它應該提供的價值。

當然，如果我們不將行動方案具體化，這是某種徵兆的表現。背後是什麼？我們是否真的有空間在衝刺中進行改善？公司是否支持我們進行所需的改變？我們是否感到自己是團隊的一部分，並有動力把事情做更好？

如果我們意識到這個問題，就需要解決這些問題。

 

結語

本文旨在總結 Scrum 團隊中的問題徵兆，幫助您識別並嘗試解決它們。

這是文章的結尾，但絕不是問題徵兆的終點。您有沒有遇到本文列出的問題？您是如何處理它們的？您會列出哪些其他問題作為 Scrum 團隊中可能的問題徵兆？

 

原文作者：Renata Blicharz｜敏捷領域專家（E）

作者檔案