[閱讀筆記] The Great Scrum Master 第三章

#ScrumMasterWay

第一個層次 — 我的團隊

Scrum Master 只對開發團隊負責，
「如何讓自已每天都發揮作用?」
建立具有敏捷思維與 Scrum 價值觀的自組織團隊是個長期活動。
第一步是觀察，並抑制親力親為的衝動(具體建議/親自排解障礙)，

可能的問題在於，團隊缺乏理解、所有權、責任感與經驗;
或是團隊的抵制。

1
2
3

回饋:
沒有主管並不會讓團隊自組織！給團隊解決不能只靠再想想
https://www.facebook.com/91agile/posts/986977734810178

Scrum 的價值觀

承諾、專注、開放、尊重、勇氣
— ScrumAlliance 《Scaling Lean & Agile Development》
誠實、開放、勇氣、尊重、專注、信任、授權和合作
—Kenneth S.Rubin《Essential Scrum》
謙虛、尊重、信任
— 《Debugging Teams: Better Productivity through Collaboration》

第二個層次 — 關係

Scrum Team
- 建立連貫、自信的團隊
- 將 PO 整合進入團隊
- 建立三個角色平衡的關係
利害關係人
- 客戶、用戶、經理、銷售人員、維運人員、客服、其它團隊
- 將自組織用于參與的所有人員
這需要 Scrum Master 對 Scrum 定義、理解與解釋的能力，
不只是會議/角色或產出物，而是從文化、價值觀與思維方式對 Scrum 的內化。
在這層次下，需要建立靈活的虛擬團隊擁有所有權，承擔某些責任，
有些團隊在解決問題後就可以淡出，有的要維持一段時間。

開發團隊與 Scrum 團隊不是組織中唯一的團隊 ?
持續存在的團隊 ? 專案團隊 ? DevOps ?
短暫存在的團隊 ? 救火團 ? 跨專案團隊 ?
這些團隊的資源從何而來 ?
持續存在又特殊的團隊? 維運?
花很多時間釐清問題，卻沒有辦法解決問題?
受限於什麼原因 ?
技術不足 ? 沒有人領導 ? 沒有所有權 ? 風險導向 ? 不受重視 ?

第三個層次—整個系統

Scrum 是「一種生活方式」，成為生活哲學的一部份，改造整個系統(世界)。

提示

先觀察
幫助團隊，讓團隊移除障礙
引導不是讀一本書或上一次課
教練法是提出問題的能力(你會問問題嗎?)
不要停留在開發層次，融入工作生活之中

1
2
3

太高大上了，跟不上…
問個問題，如果障礙是組織內的要員或大主管呢 ?

Scrum Master 小組

如果要讓組織敏捷，核心是一個強大的 Scrum Master 小組。
如果組織在「第一個層次 — 我的團隊」中擁有一個強大的 Scrum Master 小組，
那麼 Scrum Master 只需要完善團隊就好了;
比起單獨創立完善一個 Scrum Team 或是依賴 Agile Couch，
Scrum Master 小組是改變組織最好的起點。

Scrum Master 小組的目標

替其它人作好系統層次的準備
關注整個系統
建立虛擬組織讓人參與並擁有所有權

挑戰

Scrum Master 否定 Scrum Master 小組的價值
防衛心理:
- 缺乏同理心，從別的團隊角度觀察事情
- 缺乏系統觀點與思維
- 缺乏管理變革經驗

組織即系統

將組織視為系統而非階層架構。

系統思考，了解彼此的關系與動態
觀注 impact mapping

Cynefin 框架

簡單明確(Simple / Obvious)
- 你只需要分類，選擇最佳解即可
人為/物理複雜(Complicated)
- 像是組裝模型，你需要先分析計劃，
- 當事情變得簡單明確即可。
- 沒有最佳解，只有最適合的選擇
抽象/化學複雜(Complex)
- 重複實驗評估，直到事情逐漸明確可以進行下一步，
- 通常要大量的試錯才能有解答
混亂(Chaotic)
- 你只能依賴直覺，先逃離危險，分析情況後再決定下一步
無序(Disorder / Confusion)
- 如果你無法分辨情況，就是處理無序的狀態
- 先搜集資訊，分析再前進

練習

Obvious : 多語抽換字串
Complicated : 整個 sprint 範圍多個頁面抽換;
RD 彼此衝突 / Merge Before Build 造成的衝突與浪費
Complex : 風險控管多種理由不準上線
Chaotic : 上線後引發 SQL 問題當下是混亂的

回饋

1.
組織或團隊會抗拒改變;
又或者組識本身的價值觀與 Scrum 有所抵觸。
以這個層面來說 Scrum Master 能作得很有限，
所以又有 Agile Coach 的產生 ? → 說穿了就是顧問 ?
第一現場的工作者給的問題，如果不虛心接受
以現場角度思考，全盤歸疚於心態問題，是在逃避問題
抱著過往成功不放，不願具體改變或聆聽異議，
由上而下獨幹而非由下而上改變，喊喊口號「速度感起來了!」
敏捷淪為口號，實踐就成了宗教儀式。
不論是 Scrum Master 或是 Agile Coach 都是觀察者/顧問的角色，

轉型的路上我質疑一切
質疑主管、質疑公司、質疑理論、質疑作法;
甚至質疑我自已，然後我的心態還不能崩了，
真是有病…
要正心，保持陽光。

Unit Tests Team ?
為什麼有這樣的想法 ? 單元測試很重要，卻沒有人寫。
原因1. 沒有時間
原因2. 流程內未包含寫單元測試與執行單元測試，
Scrum 的 User Story 或 Task 也不會包含，驗收條件也不包含 Unit Tests。
原因3. 責任規屬不明? QA Team 專心作測試，RD Team 專心作開發
沒有一個團隊專門來處理單元測試
原因4. 導入失敗
 - 跨領域 BeckEnd、F2E、IOS、Android 缺乏足夠知識
 - 跨專案開發資源就不夠了，怎麼寫測試 ?
 - 遺留代碼難以開發，技術水平不夠，缺乏領頭羊。
 - 讀書會成為逆向宣傳。
 - 沒有人專職導入，導入船過水無痕。

Unit Tests Team ?

參考

(fin)

Marsen's Blog

#StandWithUkraine