ScrumMaster的角色衝突




從擔任ScrumMaster九個月以來,經歷了三個時期的轉變,

猶如禪宗《指月錄》裡,「見山是山,見山不是山,見山還是山」 的三重境界。

我是以R&D team leader的角色轉職ScrumMaster,
是團隊成員的直屬主管,擁有人事的管理權(招募、解雇及績效考核等…)。

在Scrum的相關介紹裡,都會建議讓ScrumMaster單純化,不要擁有管理權,
這會讓團隊成員對他頭上戴的帽子是ScrumMaster或是主管感到困惑,
甚至妨礙自組織團隊的形成。

往好處想,由於有主管的職權,在推動一些政策或改變時會比較容易,
前提是你必須確保自己要推行的事情是正確的。
既然這是無法避免的問題,我告訴自己要學會竭盡所能解決任何潛在的利益衝突,
尤其是要保持開放的心態鼓勵溝通,避免以威權領導團隊的情況發生。

即使有了心理準備,工程師畢竟是一種過於樂觀的生物,
執行時仍是遭遇了合併角色時可能會犯的那些錯誤。
首先遇到的是我們在doing agile而不是being agile,
我們遵照Scrum的規則執行必要的活動,但活動的進行卻不夠符合其背後的精神。
從Scrum第一天的planning meeting開始,我主導了如何將sprint backlog item拆成task的過程。
daily meeting時我站得太前面,像是傳統的那些會議,
部分團隊成員習慣直接對我報告,而不是其他成員。

當進度落後時,我會主動提出「建議」改變工作的進行方式,
理智上知道sprint是可以失敗的,仍然將sprint是否成功作為我的職責,
想方設法的讓團隊可以在時間內完成。

retrospective meeting時我會幫團隊寫下會議紀錄,作為下次retrospective meeting時的依據,
檢視列為action plan的項目是否有被執行,讓自己變為一個秘書或監督者的角色。

接著是第二階段,我參加了呂毅老師CSM的課程。
在兩天的課程中我學到最多的不是ScrumMaster該做什麼,而是ScrumMaster「不該做」什麼。
課程結束後我期許自己往教練的角色前進,以引導來取代教導;
列出了ScrumMaster該有的特質貼在螢幕前常常提醒自己,尤其是要有耐心,
不要認為自己比集體智慧還要聰明,給團隊足夠的時間,讓他們自己找到答案。
我開始站在團隊成員背後,不再參加planning meeting part.2,
daily時看到問題不會急著指正,只是記下來作為retrospective meeting的準備。
不再由我負責retrospective meeting的紀錄,由團隊自行決定到底要不要寫,
兩個團隊討論後各有各的作法,但都決定不再像之前一樣記在OneNote上。
團隊在這階段有更多的自主性,更符合自組織團隊的定義;
作為交換我們付出了一些代價,例如sprint失敗的機率增加,
在產品開發有些欠缺考慮的地方,造成品質下降。

來到今年,由於新人陸續的加入(佔了1/3),兩個團隊重新分組。
Scrum的核心在於隨時檢驗與調適,依據上階段的成果和團隊目前的情況,
我又調整了自己的工作模式。

扮演理想ScrumMaster的前提在於你有理想的團隊成員,Scrum對此沒有明確定義;
就我的認識,我會以《Google模式》裡的智慧創做者(smart creatives)作為標準,
具有深厚的技術或專業能力,還有創造力與實踐執行的能力,
而且充滿好奇、質疑現狀,以不一樣的方法來應付問題與挑戰。

新人比例偏高加上重新分組,讓團隊的發展回到第一階段的成形期,
除了教練的身份外,我更需要的是老師的角色,傳承我的能力和經驗。
我又開始全程參與planning meeting part.2,只是我不再主導而是提醒,
在團隊的討論中丟出問題,提醒他們沒考慮的地方。
重點不在於討論出什麼樣的解決方案,而在於提問以引發討論,
藉由一個一個問題去淬鍊出越來越好的作法;

必要時我會補充技術上的專業,只有我具備而其他人不知道的資訊來協助討論。
在daily meeting和retrospective meeting時,我依循相同的精神和團隊互動,
依據要處理的課題切換我頭上戴的帽子,可能是ScrumMaster或是資深工程師。

Scrum沒有標準作法,在不同的環境(context)中會有不同的應變,
一切都是trade off,只要想清楚每一個決定的得失,是否合乎敏捷的精神?
最忌諱憑直覺作出反應,讓自己習慣於過往的工作模式。

0 comments