[活動筆記] 2020 SCRUM GUIDE UPDATE

前情提要

2020/11/18 將迎來 Scrum 25 周年與 Scrum Guide 的更新,
活動有一些大師對談,錄影放在文末連結之中,
另稍微比較一下 2017 與 2020 Scrum Guide 的差異(以中文為主),
特別感謝譯者這麼有效率的更新,我差不多在 19 號就可以在網站下載

排版與封面

2017 版本主要視覺的位置放了兩個大師的合照,首行字為「Scrum 指南™」
2020 版本主要視覺的位置為「Scrum 指南」,首行字為兩位大師的名字。
理想我會希望使用 2020 的版本,然後兩位大師的名字縮小到角落 :D

目錄

2020 將目的前移到目錄之前,我覺得這樣的調整很好。
讓人可以先讀取本指南的目的。

Scrum 指南的目的

篇幅相比 2017 更長了,並將 2017 版「Scrum 的運用」縮減並挪移至此處。
簡介了 Scrum 的起源,概述了 Scrum 的運用範圍與現況。

另外有兩句預防性的警語,是這個段落的重點

  • 改變 Scrum 的核心設計或 Scrum 的各種理念,遺漏其中任何元素,或是不遵照 Scrum 的規則,是在掩蓋問題,並限制了 Scrum 的各種好處,甚至可能使其變得毫無用處。
  • 這些使用 Scrum 框架內的戰術技巧有很大的變化,因此不在此描述。

這個篇幅簡述了 Scrum 已是被時間與不同產業實証有用的框架,
但擅自修改 Scrum 可能會導致 Scrum 效用打折甚至無用,
並具體說明 Scrum 的戰術實作不會在此指南描述。

Scrum 的定義

相比 2017 的版本,這裡直接提到了 Scrum 中所有的角色與其職責。
並明確的說明「原封不動地應用 Scrum」, 並強調這份指南是人之間的指引
而不是具體的流程、技術與方法。

這裡也是我覺得很好的地方,以前在首次與團隊成員說明 Scrum Guide 時,
如果按照 2017 的章節說明,我都要另外安排一個段落先簡述 Scrum 中的角色,
因為 2017 在角色出現的篇幅比角色的說明還要早。

Scrum 的理論

2020 的版本加上精實思維(Lean Thinking),
並具體說明了檢視、調適的事件( 2017 翻譯為活動)與三大支柱的關係。

透明性的段落強調了没有透明性的檢視會產生誤導和浪費(做出讓價值減少且風險增加的決策)
很有感觸,我在團隊導入 Scrum 的首要宗旨就是看見事實。
(有機會再談談如何定義事實與 Ruddy 老師說的「看見全貌」的差異之所在)

檢視性強調 Scrum 將以 5 個事件有節奏實踐檢視性(具體作法與事件在這個段落還沒提),

檢視性促成調適性。 沒有調適性的檢視是沒有意義的。Scrum 的事件旨在激發改變。

這句話作到了承先起後的作用,可以將檢視性視作三大支柱的樞鈕。

調適性的篇幅提到了授權與自我管理,這也許是導入常常碰到的地雷。
團隊不被授權或缺乏自我管理的能力或意識(有點像有沒有病識感)。

2020 的編排我很喜歡,除了一再預告事件如何產生三大支柱之外,不再僅僅以順序暗示三大支柱的關係。
而是明確的說明透明性促成檢視性。檢視性促成調適性。
(有點像真善美,沒有真後面就會變成假善、假美那就豪無意義了)

Scrum 的價值觀

對承諾、專注、開放、尊重、與勇氣的排版更明顯了,另外 Stakeholders 也明文納入其中了。

誒、不對啊,這些態度不是跟四維八德一樣,小朋友都知道嗎?
而且應該不論是你的老闆、雞巴主管、龜毛客戶、秋條前輩到所有人都應該要有相同的態度,不是嗎?
這就是知易行難吧… 說個滑坡的,最近在思考尊重與尊敬的差異,
朋友給了我一個例子:

  • 尊重:念在你是一代宗師,你自盡吧
  • 尊敬:我的戰鬥力只有六千,他起碼有一萬以上

聽說看得懂的都是老人。

Scrum Team

引言強調一位 Product Owner(2017 在後面的段落才提到),
強調了沒有子團隊與階級架構(具體實務上會影響到組織結構,實作起來並不容易,需要更多的經驗)。
這次沒有翻譯目標/目的了,直接使用 Product Goal 並在後面的段落具體指由 PO 開發、描述溝通。

然後強化了對當責的描述,調整了後面篇幅的介紹順序
2017:PO > Development Team > Scrum Master
2020:Developers > PO > Scrum Master
我認為順序都是有暗喻性的,但解讀方式是自由的,就不過多解釋了。

重點是責任的部份,我覺得比起 2017 更能簡單的用 Scrum Guide 說明現在角色的職責所在了。

Developers

● 打造一份 Sprint 的計畫,也就是 Sprint Backlog;
● 藉由遵循完成之定義,以灌輸品質;
● 每天調適其邁向 Sprint Goal 的計畫;和,
● 作為專業人士對彼此負責。

Product Owner

● 開發並明確的描述溝通 Product Goal;
● 創造並清楚的描述溝通 Product Backlog items;
● 對 Product Backlog items 進行排序;和,
● 確保 Product Backlog 是透明的、可見的與可理解的

這裡特別加上了

Product Owner 可以自己做上述工作,或者也可以將職責委託他人,然而,Product Owner 仍肩負最終責任。

這句話我視為對大型組織導入 Scrum 的困難之處的回應。
錯誤 Scrum (其實就不是 Scrum)會產生缺乏實際權限的 PO
或是有權無(卸)責的傳統型領導。

Scrum Master

明文Scrum Master 對 Scrum Team 的效能負責;職責更明確了,語句更洗鋉,贅字更少。
但我覺得「真正的領導者」這段文字將會產生轉型時的爭議,特別是將「僕人式領導」文字又被拿掉。
我會建議作為 Scrum Master 要把這件事放在心中,Title 只是浮雲啊。

Scrum 事件(原為 Scrum 活動)

Sprint

明文採用時間較短的 Sprint,可以建立更多學習周期,此外更加強調三大支柱與 Sprint 的關係。

特別提醒經驗主義的重要性,更勝於實際的做法(諸如:燃盡圖、燃起圖,或是累積流量圖等…)
這與我的經驗也是不謀而合,主管一開始就投入過多心力在要求製作圖表,
而忽略了在圖表之前,進行預估其實是需要訓練的,最後圖表變成作假帳…
失去透明度,檢視性與調適性將無法發揮功能,Scrum/Sprint 將會失敗(或是不知道成功或失敗)。

取消 Sprint 的章節被大幅縮減,僅以不合時宜一句代過。
反而釋放更多空間給 Product Owner。
我覺得 PO 當要取消 Sprint 時,要思考以下的問題,

  • 要如何與其它角色互動?
  • 要如何持續實現 Product Goal?

這樣的文字編排方式,我覺得是很大的改善,強調在 Scrum 之中,
我們的所有行為都是為了實現三大支柱,而我們相信這樣的方法可以領我們到達終點之地。
後面的事件也都有類似的描述,我就不再補充。

Sprint Planning

2017 版本
第一個討論題目:這次 Sprint 能做出什麼?
第二個討論題目:如何完成所選的工作?

2020 版本
主題一:為什麼這次 Sprint 有價值?
主題二:這次 Sprint 能完成(Done)什麼?
主題三:如何完成所挑選的工作?

明顯多了一個有關價值的主題,但是需要與 Stakeholders 在 Sprint Planning 結束前被確定下來,
就我實務的經驗 Stakeholders 與 PO 會比 Developers 提早決定未來的目標,
所以 Stakeholders 依然不是會議中必要的角色。

Daily Scrum

1
2
3
4
Developers 可以選擇他們想要的任何 Daily Scrum 的結構和技術,
只要他們的 Daily Scrum 專注於實現 Sprint Goal 的進展,
並且產生下一個工作天可執行的計畫。
這樣可以更專注並改進自我管理(self-management)。

把經典的三個問題拿掉了,這也符合我的經驗,不要流於形式,
而是更專注在實現 Sprint Goal,不流於形式則更能讓團隊自我管理。

Sprint Review 與 Sprint Retrospective

這兩個段落的篇幅都縮短了,但是我覺得更言簡意賅。
但投影片展示的描述,我還比較喜歡 2017 版本的描述 是為了引發意見的反饋和提升協同合作
但的確實務上往往會淪為簡報報告。

關於 Retrospective 這個會議對我的定義,
我目前的團隊沒有在跑 Scrum ,但是我直接引入 Retrospective。
Retrospective 是一個可以雕塑團隊的會議。
有趣的事,團隊現在調整的越來越像 Scrum (當然依然不是 Scrum)

Scrum Artifacts

明文: Artifacts 的設計是為了使關鍵資訊之透明性極大化。(其實 2017 年的版本也有提到)
2020 版本的文字組織更簡明之外,都加上了承諾的區塊,

  • Product Backlog 是為了實現 Product Goal 的承諾
  • Increment 是為了實現對完成之定義(Definition of Done) 的承諾
  • Sprint Backlog 是為了實現 Sprint Goal 的承諾

結語

結語的部份並沒有太大幅度的修改,
但是我想要再一次強調 「雖然實施部分的 Scrum 是可能的,但結果就不是 Scrum 了。」

小結

整體的文章的結構完整性更好了,三大支柱與活動的連結,產出與承諾的連結。
然後將實作(戰術)面與角色的行為(戰鬥)樣版移除,這樣給了更多空間讓團隊發揮。
也會促使團隊思考背後的原因(Why) ?

想起以前聽過「守、破、離」的演說,我想這次 Scrum Guide 有一點這樣的味道,
在 25 年前,什麼經驗都沒有情況,這樣的樣版帶來了相當大的幫助,
現在我們都有一些實作有一些失敗有一些成功,是時候把樣版移除了(或是回到問題的本質)。

  • 你真要的三個問題嗎 ? 背後想問到的是什麼 ?
  • 真的不取消 Sprint 嗎 ? 為什麼不行 ?
  • 不站立真的不能開 Daily Scrum 嗎 ?

20201125 補充:
Adrian 的分享相當清晰明瞭,補充連結如下:

校錯

  1. 的的
  2. 的的
  3. Artifacts

參考

(fin)

Please enable JavaScript to view the LikeCoin.