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

#ScrumMasterWay

第一個層次 — 我的團隊

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

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

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

Scurm 的價值觀

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

第二個層次 — 關係

  • Scurm Team

    • 建立連貫、自信的團隊
    • 將 PO 整合進入團隊
    • 建立三個角色平衡的關係
  • 利害關係人

    • 客戶、用戶、經理、銷售人員、維運人員、客服、其它團隊

    • 將自組織用于參與的所有人員

      這需要 Scurm Master 對 Scurm 定義、理解與解釋的能力,
      不只是會議/角色或產出物,而是從文化、價值觀與思維方式對 Scurm 的內化。
      在這層次下,需要建立靈活的虛擬團隊擁有所有權,承擔某些責任,
      有些團隊在解決問題後就可以淡出,有的要維持一段時間。

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

第三個層次—整個系統

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

提示

  • 先觀察
  • 幫助團隊,讓團隊移除障礙
  • 引導不是讀一本書或上一次課
  • 教練法是提出問題的能力(你會問問題嗎?)
  • 不要停留在開發層次,融入工作生活之中
1
2
太高大上了,跟不上…
問個問題,如果障礙是組織內的要員或大主管呢 ?

Scrum Master 小組

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

Scrum Master 小組的目標

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

挑戰

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

組織即系統

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

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

Cynefin 框架

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

練習

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

回饋

1
2
3
4
5
6
7
8
9
10
11
1.
組織或團隊會抗拒改變;
又或者組識本身的價值觀與 Scurm 有所抵觸。
以這個層面來說 Scurm Master 能作得很有限,
所以又有 Agile Coach 的產生 ? → 說穿了就是顧問 ?
第一現場的工作者給的問題,如果不虛心接受
以現場角度思考,全盤歸疚於心態問題,是在逃避問題
抱著過往成功不放,不願具體改變或聆聽異議,
由上而下獨幹而非由下而上改變,喊喊口號「速度感起來了!」
敏捷淪為口號,實踐就成了宗教儀式。
不論是 Scurm Master 或是 Agile Coach 都是觀察者/顧問的角色,
1
2
3
4
5
轉型的路上我質疑一切
質疑主管、質疑公司、質疑理論、質疑作法;
甚至質疑我自已,然後我的心態還不能崩了,
真是有病…
要正心,保持陽光。
1
2
3
4
5
6
7
8
9
10
11
12
13
Unit Tests Team ?
為什麼有這樣的想法 ? 單元測試很重要,卻沒有人寫。
原因1. 沒有時間
原因2. 流程內未包含寫單元測試與執行單元測試,
Scurm 的 User Story 或 Task 也不會包含,驗收條件也不包含 Unit Tests。
原因3. 責任規屬不明? QA Team 專心作測試,RD Team 專心作開發
沒有一個團隊專門來處理單元測試
原因4. 導入失敗
- 跨領域 BeckEnd、F2E、IOS、Android 缺乏足夠知識
- 跨專案開發資源就不夠了,怎麼寫測試 ?
- 遺留代碼難以開發,技術水平不夠,缺乏領頭羊。
- 讀書會成為逆向宣傳。
- 沒有人專職導入,導入船過水無痕。

參考

Please enable JavaScript to view the LikeCoin.