在敏捷體系中,Scrum Master(SM)的存在是為了讓開發團隊把事情完成得更好;所以不是SM要求團隊完成事情,是團隊要求SM幫助他們進步。如果Scrum Master沒有要求團隊做什麼的權力,那事情該如何才能完成呢?
這是很常見的疑問,問題要分成三部分回答:
- 哪些事情需要被完成(Why and What)是產品負責人(Product Owner,PO)的決策和權限,跟SM沒有關係。
- 如何完成事情(How)是開發團隊的決策和權限。
- Scrum Master(SM)的存在,是為了讓開發團隊把事情完成得更好;所以不是SM要求團隊完成事情,是團隊要求SM幫助他們進步。
常見的SM怪味道,一般都跟這個疑問有關係,例如:
- 這些雜事都是我們SM做;
- SM要負責幫我們移除障礙,所以要寫Code<del>通馬桶</del>,讓Sprint Goal完成;
- 我們SM也是產品負責人;
- 我們的主管就是SM;
- 我們SM說……
這些「怪味道」對團隊會有什麼影響呢?
1. 這些雜事都是我們Scrum Master做
「這些雜事」包含(但不限於)叫大家開會、整理Sprint Items、更新Burn Down Chart、跟PO溝通、幫忙請假、跑跑公文、買便當送飲料;某些也許是團隊要做,有些更適合「
程序員鼓勵師」來做,但絕對不是SM的責任。
通常的原因是,SM要做的東西太抽象;而工業時代的思維,就是「看起來不忙等於沒有產值」。
而SM也不好意思整天就觀察大家,所以拖一些雜事來做;風險就是養了一個看起來很忙不務正業的SM,但對團隊的幫助比程序員鼓勵師還小(至少程序員鼓勵師看了大家賞心悅目)。
2. Scrum Master要負責幫我們移除所有障礙
所以要寫Code、通馬桶,讓Sprint Goal完成。
如
Scrum Guide裡所說的,SM要移除阻擋開發團隊「進步的障礙」,而非「所有障礙」;開發團隊無法完成Sprint Goal,然後去幫忙完成,跟團隊成長的關聯性不大,反而讓開發團隊更依賴SM。
SM應該針對無法完成的原因深入探討,如技術能力不足、需求不清晰、或是插件太多等等;然後幫忙從根本解決問題。馬桶塞了通馬桶,都比跳下去幫團隊完成Sprint Goal對團隊的成長幫助更大,至少通了馬桶讓大家身心舒暢。
3. 我們Scrum Master也是產品負責人
Scrum把SM和PO角色分開的目的,在於是減低權威的影響、創造有利於自組織團隊產生的環境。而SM+PO二合一(又稱Team Lead或PM),對自組織環境是不利的;因為等於是人(SM)和事(PO)的權利一手抓,是個大魔王過於權威的角色。
可惜這是實務上很常見的安排,不過既然跑Scrum,還是要遵循Scrum的規則讓SM和PO分開。其實Team Lead或PM也是可以跑敏捷開發的,不一定要Scrum才能敏捷,沒必要為了趕Scrum的流行詞讓PM名片上的頭銜重印成SM。
4. 我們的主管就是Scrum Master
SM是專門輔導和教練人,為了讓團隊發自內心的接受建議,所以用去除權威的方式輔導。而一個擁有人事權如薪資,升遷等權限的主管所「建議」的,很多團隊就算不願意也會接受。
這樣長期下來,會打擊團隊自組織的意願和能力。如果主管願意放下權威,相較於「PO+SM」,「主管+SM」的危害會小一些,因為產品(事)的威權已經被PO分擔了。
題外話,雖然Scrum原則也不建議「主管+PO」,但這在我們實作上比較順利;因為至少主管不會自己打自己(PO)的回票,所以PO的產品決策都會落實。
5. 我們Scrum Master說……
開口閉口都是「我們這樣做是因為某某說什麼」,這背後有兩個訊息:一是團隊把SM說的話當聖旨,二是團隊懶得思考原因;而兩者都代表團隊缺乏自組織的能力或意願。
所以,SM可能要少說一些,多讓團隊自己做決策和負起責任。
之前在〈
神一般存在的Scrum Master〉中,用了「輔導長」來比喻Scrum Master對開發團隊的角色定位;至於Scrum Master對團隊(包含PO)和組織的期待與心態,聽過最確切的比喻是Bas所提的「如同父母對子女」。
西方式的父母都會希望子女可以盡快獨立自主,最終擁有自己的一片天,不需要在父母的蔭蔽之下生活。
所以Scrum Master做決定的大前提,應該都是「我現在這個行動可以幫助團隊和組織盡快獨立自主嗎?」
本文已獲作者授權並經本站重新編輯,未經書面許可禁止轉載。本站文章提供付費授權轉載或出版,請參閱
授權說明、或來信
ask@tuna.to 洽詢。如果您喜歡這篇文章,請按「喜愛」圖像、也歡迎分享到社群網站上!