必爭之地 — Scrum 詮釋權

由於 Scrum 並不是每個人都研究過,所以也存在著詮釋權的政治運作空間,Scrum 規則往往並非如書上所說,是由Scrum Master 去監督,擔負教練的角色,而是由掌握Scrum 詮釋權的人,去指揮Scrum Master 做調整,在接下來的案例中,掌握Scrum 詮釋權的角色是位擅於奉承並私下攻訐同事的 DP ,顯赫的戰功中包括鬥走三位資深PM及一位Scrum Master,獨攬大權。(隨後昇為 Director of Product, 後簡稱為 DP)

手上晃著沒什麼人研究過的東西,還是挺容易唬到人的。 掌握一個制度的詮釋權,就好比掌握了一部任你解釋的憲法,任何規則與之牴觸都宣告無效,這無與倫比的權力,請盡快掌握!!

Daily Standup Meeting:
DP 不想參與(因為怕被工程師問做了什麼),又想凌駕於眾人之上,便要求Scrum Master 得提供團隊成員每天在做什麼的報告,Scrum Master 變成 DP Secretary。

Planning Meeting 時程預估:
在Planning Meeting 前,DP 私下問某個工程師大概的估時,但只透漏部分需要實作的功能,並用這估時,去答覆其他部門主管、上司。Planning 時DP 也有參與,但完全不提及此事。(這是慣用的資訊不對稱手法,用於鬥爭再好不過,將誘使同事走向錯誤的路,再私下於上司面前攻擊同事)

很理所當然地會超過DP 私下問的估時,因為要實作的功能遠超過當初提的需求(還在不斷地增加中)。
但為什麼增加功能,卻沒有增加實作功能的時間? 因為這是DP 的Scrum,DP 已經先答應其他部門主管、上司了,所以工程師就必須做出來,超時的責任全落在實作的工程師身上。

而且DP 不斷地在修改同張 Story Requirement,工程師稍不注意就會做錯。針對這情況,DP 及他的好朋友 CTO 所決定的改善方式是叫 Scrum Master 去做系統分析、畫流程圖、寫細部的需求,而寫程式則是原先就在做的事,反正做這些事能幫助團隊嘛!! 不正是 Scrum Master 的宗旨嗎?
有人會問,那DP 在做什麼?? 不得不說,這也是本世紀的大謎團之一,唯一可見的是寫出「做一台法拉利」這樣的需求。

再度很理所當然地產生一堆 Bug,因為開發時間根本不夠,長期累積下來,欠下的技術債可不是這麼好相處。稱職的QA 會在開出的BUG 單上寫出可能的處理方式,這對團隊是件好事,但在DP 的Scrum 中,便不是這麼回事,因為處理方式可能是額外做個新功能的等級,DP 常以這樣的方式避過 Planning 的估分,工程師就這麼被無限制地壓榨。
或是事前說好會提供時間讓工程師 Refactor,團隊成員在短時間內完成功能後,DP 隨即翻臉不認人,要開始進行新功能的開發,還記得上一段提到文件全丟給 Scrum Master 寫了對嗎? 沒錯,Scrum Master 這時候沒辦法完成與團隊成員之間的承諾(Refactor),文件也還沒開始寫,儼然成為一個行PO之實,卻無PO之權的 Scrum Master。

因為沒有掌握 Scrum 的詮釋權,Scrum Master 將變成一個無法保護團隊的角色,甚至被當成DP 的小弟,即使在 Retrospective 會議中指出DP 的惡意行為也於事無補,其他時候更早已戰過無數回,只會被DP 當成 ”解決提出問題的人” 的最佳人選。若開發團隊的成員們不全力支持 Scrum Master 去爭奪 Scrum 的詮釋權,那麼

「只有追進度時,很敏捷的 Scrum」

就此完成。