ScrumMaster的十大錯誤

敏捷進入中國有18年了，現在各個行業都在說敏捷，每個ScrumMaster都在說scrum。本身這是個好事，可是出現了很多“敏捷大仙”。用各種預定義的流程、工具、文檔替代了敏捷，這已經背離了敏捷的精髓，敏捷的本質。

1. 因為敏捷而敏捷

其實大家并不關心敏捷，而是關心敏捷背后的那個“快”。（我有一篇文章專門描述，敏捷不是快）。除去“快”，敏捷更應該關注目標及個人成長。

ScrumMaster的口頭掛著“敏捷、Scrum、看板”，經常會說敏捷要求我們做這個，敏捷要求我們做那個，blah,blah…… 這個不是答案，敏捷也不僅是項目管理工具或流程。敏捷更多是一種心態的改變。

敏捷應該幫助企業和個人實現目標（即價值）。

團隊成員不想開每日站會，討厭計劃會，回顧會。為什么？因為團隊認為敏捷是另一套流程，我已經996了，還要加這么多會議，不如去寫代碼。

在敏捷轉型的過程中，“拒談敏捷”，認真思考如下問題：

你的目標是什么？

為了達到目標，你需要什么？

達到目標的阻力是什么？

你怎么知道達到目標了？

敏捷里面有非常多的實踐了，比如Scrum的5個會議，看板，用戶故事，等等。但是用每個實踐之前，嘗試回答上面的問題，并且和團隊一起來回答。

2. 管理心態

ScrumMaster不用管人，而是幫助改進系統，提升公司和個人價值以及移除障礙。ScrumMaster并不是角色，也不是頭銜。 作為ScrumMaster，是與團隊在一起幫助團隊完成工作。提供團隊的需要，解決團隊的問題。

良好的ScrumMaster觀察團隊工作，使之透明并識別改進機會。

3. 推敏捷

不要向團隊推敏捷，推工程實踐。而是讓團隊主動用敏捷方法。 參考我之前的文章，推還是拉敏捷

讓團隊決定他們要如何解決問題。團隊需要時間成長。

4. 4W1H（Who, What, When, WHere, How）

ScrumMaster主動的什么也不做。表面上什么也不做。產品開發是客戶、產品負責人及團隊的工作。作為ScrumMaster是幫助團隊成長，改進系統。

下面這些對于ScrumMaster很常見：

分配任務

編寫用戶故事

提前規劃迭代列表

估算

更新任務板

認為對所有問題負責

選擇配置scrum工具

決定什么是團隊的障礙

計算團隊成員的能力（容量）

認真思考一下，作為ScrumMaster你有沒有做過類似的事情。如果做過，請認真反思。

5. 定義團隊協議及DoD

ScrumMaster和團隊一起共同制定團隊協議、DoD，而不是代替團隊，一個人制定好。詢問團隊他們想要什么樣子的協議，DoD。 這是團隊的事情，作為ScrumMaster，是幫助團隊制定協議和DoD。 讓團隊理解協議和DoD的好處，并制定出來。

6. 定義需求或任務

ScrumMaster是幫助產品負責人和團隊的，但產品負責人和團隊要做他們自己的工作。

產品負責人不準備產品路線圖，不提前準備需求，不去和干系人或真實客戶探討，不梳理產品列表。 作為ScrumMaster，需要幫助產品負責人認識到這些問題，并提供相應的工具，輔助產品負責人。

7. 定義優先級及計劃

不要成為產品負責人的代理，永遠不要。 產品列表的優先級（順序）是產品負責人的職責，ScrumMaster可以幫助產品負責人認識到：

如何排序

排序的參考因素

什么時間排序

什么時間準備好產品列表

產品負責人是產品列表的唯一負責人。（參見Scrum指南）

8. 定義度量指標

讓團隊自我定義目標和障礙，幫助團隊認識到如何改進以及度量改進。 作為ScrumMaster，不應該代替團隊制定指標。

團隊來決定，如何衡量他們的進步（改進效果）

9. 沒有足夠的勇氣

作為服務型領導、保護團隊，保持冷靜！ Scrum轉型過程中，會涌現出很多未知的問題，ScrumMaster是團隊第一溝通的成員。 但作為ScrumMaster，不要成為團隊的瓶頸。

作為ScrumMaster，需要有足夠的勇氣，讓團隊嘗試、失敗，最重要的是從中進行學習。

10. 缺失系統思考

閉環思維，客戶思維，端到端的思考方式。和其他ScrumMaster交流，建立社區，改進流程。

以終為始，一直考慮的是客戶價值。

尋找系統問題。和管理層以及其他ScrumMaster一起，梳理價值流（信息流）。度量改進。

make everything transparent! 準備迎接挑戰！ KAIZEN!

敏捷開發

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。