Scrum 的 5 個錯誤希望以及如何解決它們

像許多經典的、永無止境的衝突一樣，關於開發團隊應該如何組織和自治的爭論也很激烈。 目前，似乎批評者多於 Scrum 的粉絲。 最常見的三種抱怨是：

1. 這個過程可以成為工作的中心。
2. 它很容易被另一個名稱與微觀管理混淆。
3. 每日站會感覺就像是一個必須證明其存在合理性的會議。

在其他情況下，Scrum 的角色沒有得到適當的表示。 有時，產品負責人想要在 sprint 中做太多事情，或者想在 sprint 中期改變優先級——一個專注於保持速度和採用他們學到的每一個新的 Scrum 儀式的 Scrum master。 在使用框架一段時間後，似乎出現了一個常見問題：“是我們還是方法論？”

Scrum 的錯誤希望

雖然存在許多類似上述的功能障礙，但其中大多數的簡單根本原因是 Scrum 並非旨在通過僅僅遵循流程來解決組織內的潛在問題。 未能認識到這一點可能會使新團隊幾乎一開始就處於危險之中。

錯誤的希望#1：Scrum 讓團隊工作更快

Scrum 使用的術語在外人看來就像它會在不增加額外資源的情況下加速流程。 作為 Scrum 的新團隊，很容易陷入術語中（例如，什麼是 Scrum 主管？產品所有者和產品經理之間有什麼區別？什麼是故事點以及它們是如何分配的？）

更令人不安的是，許多人看到速度和衝刺等術語並認為是“速度”。 但是，包括 Scrum 在內的任何敏捷方法的目的都是交付成品。 最終，隨著您的團隊變得更有能力使用 Scrum，您將能夠更快地交付新功能。 然而，速度不一定是首要目標。 這種區別應該在您的 Scrum 團隊中明確表達，當您在公司內建立意識以支持 Scrum 方法時也應如此。

你賣的不是速度； 你賣的是完成。

錯誤的希望#2：嚴格遵守 Scrum 將解決公司文化問題

每個人都有不同的工作方式。 有些人喜歡開會。 其他人則使用諸如“努力工作，努力玩耍”之類的短語。 重要的是要認識到，無論您的公司重視哪種工作方式，您都接受了它的優點和缺點。 重視會議的公司可能會在日常站立會議上遇到困難。 積極進取且以速度為導向的團隊將在 sprint 中遇到範圍蔓延的問題。

有時很容易忽視大局，尤其是對於最近組建的團隊。 重要的是交付成品，而不是遵循流程的最後一點。 與其責備方法論，不如始終尋找改進工作方式以實現目標的方法。

錯誤的希望#3：關鍵貢獻者可以派代表參加會議

一旦你開始使用該方法，原始團隊的參與而不是委託是至關重要的。 如果我從開發人員那裡看到一個幾乎普遍的抱怨，那就是 Scrum 主管和產品負責人在需要時不可用，並且他們的代表沒有被授權。 沒有人喜歡參加會議，期待做出決定，卻被告知無法做出決定的人。

委派可能是一種常見的做法，但在 Scrum 中，您還必須授權參與者。

錯誤的希望#4：每日站立會迫使每個人更加專注

每日站立會議不應僅僅關注每個人在過去 24 小時內所做的事情。 優先考慮解決問題的障礙或新方法更為重要。

Scrum 需要某些角色，尤其是 Scrum 主管，要自信但又不能壓倒一切。 Scrum master 創造一個積極的環境來完成產品是很重要的。

錯誤的希望#5：我們將在第一次嘗試中成功

Scrum 涉及猜測、演繹思維和犯錯。 人們很少在第一次嘗試時就做對了。 Scrum 在所有方面都是迭代的：不僅在你如何達到成品方面，而且在你如何管理和操作流程方面。 Scrum 旨在降低團隊採用的進入門檻，但它也需要承諾迭代並不斷提高對框架的參與。

如何修復損壞的 Scrum 流程

Scrum 可以抵抗沉沒成本謬誤。 Scrum 的迭代特性為適應或丟棄無效流程創造了機會。 如果您的 Scrum 流程不如您預期的那麼有效，請考慮以下一些建議。

完善您的期望

無論是縮短上市時間、創造引人注目的產品，還是幫助團隊協作，成功都需要投入和時間。 對於新團隊來說，一個合理的里程碑是在每個 sprint 之後，您是否可以將工作的、可測試的代碼引入您的生產環境。

高級團隊可以通過按需構建、測試和部署的能力來衡量成功。 您是否能夠檢測和量化用戶對新功能的反應？ 更廣泛的組織是否準備好支持團隊對產品所做的更改？

授權您的參與者

重要的是要離線指導團隊成員如何增加他們對團隊的價值。 如果他們被要求做出決定，請通過指導他們何時以及如何讓其他團隊成員參與來增強他們的信心。 經理需要準備好清除障礙並在需要時支持團隊。

主動解決問題

Scrum 的設計初衷不是讓您的公司煥然一新。 如果您沒有解決問題，那麼您很可能會在產品開發過程中發現這些問題。 Scrum 主管可以引入旨在為團隊成員創建積極的方式來構建他們的反饋以減少衝突感的框架。

一個這樣的例子是“我希望，我想知道，如果”框架。 在團隊討論或回顧期間，團隊成員可以通過使用這三個短語之一打開他們的陳述來提供反饋。 例如，他們可以說：“我希望站立會議能夠更多地關注我那天可能需要注意的障礙。” 您也可以使用自己的開場白，例如“我喜歡……”。

另一個在會議期間有用的結構化反饋解決方案是來自 Holocracy 的 Triage 方法，由 Brian Robertson 創建並被 Zappos 等公司使用。 例如，參與者建立一個“緊張”議程來討論。 每個參與者都通過說“我有壓力”來描述他們的問題，然後列出解決問題所需的人員和資源。 通過鼓勵參與者直接將問題視為“緊張局勢”，Holocracy 使參與者能夠自由交流，而不會造成衝突氣氛。

使用回顧來解決問題並迭代過程

在許多公司，回顧沒有得到應有的重視。 這主要是因為許多人擔心回顧會是舊爭論、衝突和不滿的場所。 團隊制定反映團隊價值觀和公司文化的基本規則至關重要。

同樣重要的是需要避免投資於靜態流程。 曾經有效的東西可能不會永遠有效。 許多團隊都在為參與者的流失而苦苦掙扎。 這在許多公司中很常見，因為參與者被重新分配到其他團隊、獲得晉升或完全離開公司。 隨著團隊組成的演變，重要的是不要一直致力於 Scrum 中的一切都是迭代的。 錯誤會發生，但希望它們在您迭代時會是短暫的。

當校長在場時，Scrum 工作得最好

作為團隊中的一員，您必須承諾在場並隨時待命。 產品開發可能是貴公司為改善其長期增長而可以採取的最關鍵的過程。 因此，作為新產品開發的主要途徑，Scrum 過程得到應有的重視是很重要的。 在許多環境中，開發團隊的工作通常與推動公司目標的決策和討論脫節。 Scrum 是不同的。 Scrum 是決策、方向和開發作為一個單一過程結合在一起的地方。 在 Scrum 方法論中舉行的會議中，派遣代表或將團隊成員排除在外是非常重要的過程。

摘要：您可以修復損壞的 Scrum 流程

由於它的迭代性質，Scrum 有助於保護業務不至於走得太遠，並致力於最終可能成為一個壞主意或實施不善的流程。 堅持這一原則有助於從過去的錯誤中解脫出來，並迭代改進 Scrum 流程。

重要的是要關注您擁有的個人和團隊。 團隊成員發生變化。 所有項目都不一樣。 嚴格遵守流程並不總能產生最佳結果。 您在流程之外對團隊成員的投資與您在流程中的行為方式同樣重要。

Scrum 可以很靈活。 如果某些東西不起作用，請考慮在敏捷內部和外部合併來自其他框架的元素。 識別並採用對抗性討論的結構化溝通方式。

Scrum 通過使團隊能夠構建完整的產品來響應不斷變化的客戶需求，從而有利於長期投資回報。 Scrum 可能是最好的方法，它可以讓你避免過度致力於糟糕的想法，同時為偉大的想法提供一些進一步發展的空間。