Scrum 團隊成員不合作，怎麼辦？

DALL.E 3: Visualize a wide panoramic high-resolution scene on the lower two-thirds of the image, depicting team members cooperating on an American football field. Capture a dynamic moment during a game or practice session, with players in football gear engaging in strategic plays, passing the ball, and offering physical and emotional support to one another.

Scrum 之所以名為 Scrum，追求的還是團隊互助合作自管理的部分，這也是為什麼相較於「專案管理」、「產品發展」兩個元素來說，這種框架對我來說更著眼於團隊發展。也因此，如果遇到團隊成員不能好好合作，那整個效益就會大打折扣。

定義上來說一位已經盡可能善盡職責的 Scrum Master 很難「不合作」 — 他的本職就在讓大家好好合作；而 Product Owner 的不合作（比方說硬是要違反 Scrum Guide 去做一些過於著重控制的事情）會需要靠 Scrum Master 多加<del>洗腦</del>努力。這邊我先純粹討論 Developer 的狀況。

對於職責與目標的認知是否相同？

會不會這些不合作是因為某些地方的認知不同呢？比方說：

• 仍然認為 Developer 的目標是「將 PM 規劃出來的東西如期交付」，而不是「完成 Sprint Goal 以便更接近 Product Goal、讓產品提供價值」：也許此時 Scrum Master 需要多闡述一下在 Scrum 這個框架裡大家分工的方式以及其好處。
• 無法將 DoD、Sprint Goal 視為承諾：也許這是源自於跟上一點非常類似的心態，如果自己不認為自己有能力影響 DoD 及 Sprint Goal，那麼也很可能將那些東西認知為 Product Owner（或其他團隊成員）發誓給別人死的東西。Scrum Master 也許需要協助、鼓勵他在 Planning 時描述對於 DoD 及 Sprint Goal 的意見，藉以加強其 Ownership。
• 或者如果更單純是對於 Sprint/Product Goal 等認知有誤差，再重申一次？

如果一個團隊很習於「把沒做完的事情就延到下一個 Sprint 解決」，我個人會建議這點要盡力想辦法拉回來。重新考慮 Sprint Goal 怎麼立、減少單一 Sprint 承諾的內容、甚至先暫時拉長 Sprint 總時長也許都是可以討論的方法。在 Timebox 內完成大家承諾的事情對節奏感、團隊 ownership 以及組織整體的信任度等等都挺重要的，應盡可能追求。

是否在能力上有需要加強？

面對能力不足的問題，團隊應該採取建設性的態度來進行討論。每個人都有自己擅長和不擅長的領域，這是團隊多樣性的一部分，也是團隊合作中可以互補的機會。

排定研習時間與內容等等自然是一個方法，團隊也許可以有固定的分享與讀書會，共同提升某些部分的技能。

鼓勵 Pair Programming 也是一個想法。雖然可能在短時間內降低整體團隊在週期內的開發能量，但從長遠來看則有促使知識分享、培養團隊默契等等好處。比較資深的開發者也許更能從中協助辨識出資淺開發者真正缺乏的東西，並指引補強方向。

也許 Scrum Master 會擔心這不太容易取信於 Product Owner，不過請相信我：至少 Product Owner 一定也不希望因為某人因故要請假一個月，他熟悉的那塊程式就要全部停擺。我們應該還是可以討論出一個平衡點。

（相對於 Code Review 的形式，我自己覺得 Pair Programming 會比較好一點，但實際上也許真正的開發者有不同看法，就也請留言指教了。）

即時回饋

那些「不合作」的部分，也許是沒有遵照 DoD 就隨意地改狀態、也許是不願意出席 Daily Scrum 來分享當前狀況、也許是無法完成承諾的事項… 無論是哪種，既然透明性和開放是 Scrum 運作的支柱及核心價值之一，當團隊成員的行為偏離了團隊的共同目標和約定的規範，就需要及時地進行溝通和調整。

對於不遵守團隊規範（例如 DoD、Coding Style、Git flow…）的情況，Scrum Master 可以提醒他團隊規範重要性和目的。這不僅僅是為了確保產品達成目標，更是為了保持團隊之間的信任和互相依賴。即時回饋能幫助成員意識到自己的行為如何影響到團隊和產品，以鼓勵他們在未來更加注意遵守約定的規範。

對於不願意按照 Scrum 框架參與開發、做好職責的成員，Scrum Master 需要明確地解釋框架裡各項原則的目的 — 以 Daily Scrum 來說，它不僅是一個報告進度的場合，更是團隊協作和問題解決的重要時刻。缺席會議意味著放棄了與團隊同步和尋求幫助的機會，這對個人和團隊都是不利的。

當面對無法完成承諾的事項時，團隊需要一個包容失敗的環境。這意味著，當任務未能如期完成時，應該鼓勵開放討論其原因，而不是進行指責。Scrum 團隊可以共同探討如何提供支援，以幫助成員克服困難，並防止類似情況再次發生。

在這個注意力缺稀的時代，與其把一切留到 Retropective，有時即時回饋會更加有效。透過建立開放、誠實的溝通管道，團隊可以及時識別和解決問題，從而維持團隊的凝聚力和提升整體表現。

請上級介入

如果什麼招數都試過後，發現是在價值觀上有些根本的差異，那麼請求上級（無論是該員的直屬主管，或者是這個 Scrum Team 的上層主管）介入可能就是解決問題的最後手段。在某些情況下，如果價值觀的差異經過努力仍無法調和，可能需要上級協助調整團隊。這種決策應謹慎考慮，以團隊和項目的最佳利益為出發點。

然而，在請求上級介入之前，更重要的是確定上級願意持續支持 Scrum 團隊當前的運作模式。如果上級實際上並不支持，甚至反對這樣運作方式，那麼問題就大條了… 團隊內應該或多或少有期待以此方式運作的人，就看你們的各種手腕了。

這個題目應該大家都有不少經驗，如果有不錯的處理方式，歡迎分享一下。