關於Scrum Master的一些怪味道與常見誤區/Yves Lin

在敏捷體系中,Scrum Master(SM)的存在是為了讓開發團隊把事情完成得更好;所以不是SM要求團隊完成事情,是團隊要求SM幫助他們進步。如果Scrum Master沒有要求團隊做什麼的權力,那事情該如何才能完成呢?

這是很常見的疑問,問題要分成三部分回答:

  1. 哪些事情需要被完成(Why and What)是產品負責人(Product Owner,PO)的決策和權限,跟SM沒有關係。

  2. 如何完成事情(How)是開發團隊的決策和權限。

  3. Scrum Master(SM)的存在,是為了讓開發團隊把事情完成得更好;所以不是SM要求團隊完成事情,是團隊要求SM幫助他們進步。

常見的SM怪味道,一般都跟這個疑問有關係,例如:

  1. 這些雜事都是我們SM做;

  2. SM要負責幫我們移除障礙,所以要寫Code通馬桶,讓Sprint Goal完成;

  3. 我們SM也是產品負責人;

  4. 我們的主管就是SM;

  5. 我們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應該針對無法完成的原因深入探討,如技術能力不足、需求不清晰、或是插件太多等等;然後幫忙從根本解決問題。馬桶塞了通馬桶,都比跳下去幫Team完成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做決定的大前提,應該都是「我現在這個行動可以幫助團隊和組織盡快獨立自主嗎?」