從 Scrum 到 LeSS — 角色

最近上完了一門 LeSS in Action 的課程
雖然在 Scrum Team 少說也四五年了
這期間也考過了 CSM, PMP 認證

但這次的課程後對 Scrum 又有了新的認識
同時也回顧一下自己在執行了將近五年的 Scrum 開發經驗
所以這篇文章不會只是單純的課程心得或筆記
更多的會是自己上完課後對於過去經驗的回顧

0x00 回顧

原本在一個團隊的狀況下
執行 Scrum 並沒有遇到太大的問題

照著 Scrum 的角色分工
PO 做價值排序
Team 負責把 Story 交付出來
Scrum Master 協助 Scrum 中的各式 Event 
以及協助團隊做回顧以及持續成長

但隨著產品越做越大
Backlog 的消化速度不夠快
因此開始招募新人擴編團隊
（有沒有一種《人月神話》的既視感 😏）

接著隨著產品的發展
除了主線任務外開始有了支線任務
例如：活動頁面、Banner 管理後台 … 
諸如此類的輔助系統

這時候 backlog 開始有些變化
大概會像這樣
🟥
🟧
🟥
🟥
🟧
🟩
(相同顏色代表可以大致上被歸類在同一個類型的 Story)

依照 Scrum 應該要照著 Priority 拿
一開始沒有什麼問題
但有時候會發現
登愣！
第一張好像要做完才能做第二張耶！
因為第一張是 Create, 第二張是 Delete
沒有 Create 怎麼做 Delete … 
（諸如此類的對話）

接著 Backlog 就開始變形了
🟥｜🟧｜🟩
🟥｜🟧｜
🟥｜

這樣團隊分著拿就不會有互相依賴
執行下來確實好像比較不容易有問題
但是總覺得哪裡怪怪的
Scrum 不是要價值優先嗎？
這樣還算是 Scrum 嗎？

雖然看似主線任務有在被推進
但如果真的可以讓所有團隊都集中產能
在最高優先序的那些 Story 理論上這樣才是對產品最有價值的吧？

此外也會有一個問題
因為產品越來越大
利害關係人也越來越複雜
有時候 PO 無法解答所有的需求細節
導致 PO 逐漸的開始變成 Post Officer
成為開發團隊與需求提供者之間的訊息傳遞者

而原本 PO 應該關注的價值排序變成了權力排序
原本應該要講 Story 的 Value 
漸漸的變成了 Spec …

如果你也有遇到以上問題
也許這篇小小的心得可以得到一點點解答

但如果想要懶人包的話
可以先劇透一下
沒錯！就是應該要按照優先序拿 Story
而在多人團隊的時候更應該的去讓團隊互相依賴
因此不應該擔憂或害怕 Story 間的關係
講師在課堂上說了一句
「拿 Story 時反而應該要最大化團隊拿 Story 間的依賴」

聽到的時候有那麼一點震驚
也有一點熟悉

為什麼會覺得熟悉呢？
剛好最近在閱讀《與成功有約》
書中講到的高效能人士是從獨立到互賴
如果換成『團隊』是否也適用呢？
高效能團隊是否也會是從獨立到互賴呢？

0x01 從 Scrum 的三個面向與四個角色

三個角色的職責在上圖已經寫得很完整
網路上也很多資料就不在此贅述
以下是自己在過去經驗中的一些回顧

註：
以下文字會用到「需求貢獻者」一詞
因為 Story 的需求可能來自各方
甚至團隊自己也有可能產出一些需求而被放入 Backlog
使用這個詞彙可以避免直接將 Story 的來源直接指向 PO 或 Stakeholder

Product Owner: Product Vision & Direction

從圖上來看 PO 最重要的就是要提供 Product Vision & Direction
但在過去經驗中如果只講 Feature 不講 Vision
由於 Teams 的職責就是 Product Creation & Delivery
在釐清需求的時候常常圍繞著「What」
我想對於 PO 來說講「What」也是件容易的事
久而久之變成在討論以及釐清的時候越來越少的「Why」

《與成功有約》也提到了「以終為始」
重點不在於做了什麼或過程是什麼
而是想要什麼結果 (Vision)

缺少了 Vision 傳遞
很有可能就會導致 Item 全部 completed 卻無法帶來價值

久而久之 Scrum 著重的 Deliver Value 開始變得像是 Deliver Spec
逐漸的開始有一點點 mini waterfall 的味道
討論的過程也越來越糾結在 Spec
而不是針對想要交付的價值上做討論雙方共同找到一個可行的做法

雖然上面提到 waterfall 的字眼
但實際上在去年考 PMP 證照的時候發現
執行專案也需要講出願景 (Shared Vision) 而不是單純的 Spec

Without vision and the criteria that will be used to judge the success of the project, the team will have no guidance and no ultimate target. Without clear understanding of the vision of an organization or project, it is difficult to keep team members enthusiastic about accomplishing the project. And without goals, an outstanding team has no objective, no sense of cause, and will soon degrade into just another group of individuals.
Shared vision creates strong project teams

因此
無論是 Scrum 或 PMP 
無論是 Project 或是 Sprint
Vision 都是很重要的開始

若少了 Vision
Teams 就只是單純的 Code Generator
產出了一堆 PO 想要的程式碼而不一定是真正能帶來價值的程式碼
以及著重在 What 的討論的時候
寫出來的 Code 也很容易有 Code Smell
因為少了 domain knowledge 就會少了 intention
開發過程都在處理資料而不是在處裡商業邏輯
少了意圖的程式碼就容易出現 
e.g. magic number, long method, data clump … etc.

除了 Vision 以外
課堂中也提到 PO 除了途中的重要職責外
整合這些職責後有兩個很重要的角色需要扮演

1. Political Officer
   PO 應該多花時間跟 Manager, Stakeholder 處在一起
   而不是團隊
   PO 因為需要規劃上線時程、價值排序、調整 scope
   因此一定會需要在眾多 Stakeholder 之間角力
   此時 PO 就需要發揮作用去協調好這些政治問題
   若 PO 沒有處理好政治問題
   那麼就會向下延伸到團隊去
   （例如在 scope 不變的情況下直接壓 deadline）
   變成團隊也要跟著玩起 Political Games
   
   這一點其實也跟 PMP 不謀而合
   一個稱職的 PM 需要做好利害關係人管理
   而不是花時間管理團隊

It is important that project managers strike the right balance between stakeholder involvement and isolation of the project from external influence in order to achieve delivery on cost and time but also to maximise benefit for the client and his stakeholders.
ref: Stakeholder management

2. Police Officer

以往學習到的 Scrum 中會講到
PO 的目的應該是隔絕 Stakeholder 的干擾讓團隊專心開發
但實際執行的時候
漸漸的會覺得 PO 就是應該要和 Stakeholder 釐清需求
逐漸的 PO 變得像是 Post Officer 幫團隊傳話

因此 PO 應該避免成為 Post Officer 
而是應該幫團隊和需求貢獻者搭起橋樑
尤其當需求貢獻者同時又是 Stakeholder 的時候
PO 有沒有成為一個好的 Political Officer 就很重要了

讓團隊直接和需求貢獻者溝通
可以避免成為傳聲筒
但同時應該作為一名 Police Officer
限定討論及交付的 Story 僅僅在所劃定的 Scope 內
以避免需求貢獻者又剛好兼具 Stakeholder 的角色時
直接對團隊要求超出 Scope 範圍的東西

Teams: Product Creation & Delivery

Teams 是產品的生產者
在過去經驗中可能只聚焦在 Developer
但 Teams 應該是包含所有決定「How」的人在裡面
如 UI, UX 都應該被包含在 Teams 的角色內
這是比較容易被忽略的事情

那麼到底什麼樣的東西在能被 Delivery 呢？

1. Potentially Shippable Product Increment (潛在可交付產品增量)
簡單來說就是至少東西得在 Production Environment 但 Toggle Off
而 PO 隨時想要 Toggle On 都可以

2. DoD (Definition of Done)
過去的一些經驗裡會把 DoD 當作只是和 PO 的協議和資訊透明而已
用來定義這張 Item 到底能不能 Done
而這次的學習讓我重新認識了 DoD

DoD 定義同時也是作為一個工程師團隊
在能力範圍能做到的交付方式下
所交付產品的最低水準

什麼意思呢？
舉個極端的例子
如果一個超級菜鳥團隊不會寫自動化測試
那麼會交付什麼樣水準的產品呢？
估計就是養了一堆蟲還肥肥大大的
🐞🐞🐞🐞🐞🐞🐞🐞
那怎麼提高水準呢？
人工測試總能降低 Bug 發生的機會吧？
那麼這個團隊的 DoD 大概至少會有一條

所有的 Feature 都要手動測試所有 Critical Path 才能上 Production Env.

這就是這個團隊能交付的最低水準
因此提升交付水準就是團隊的要務
這個菜鳥團隊就可以為自己訂下下一個 DoD 的目標
例如

所有 Feature 都有測試
所有測試在上 Production 前都有 CI 能自動化

可想而知 DoD 是可以不斷進化的
一直達到作為一個軟體開發團隊的極致理想以前都能持續的進步
例如

每次的 commit 都透過 CI/CD 直接到 Production Env.

回顧過去只把 DoD 作為和 PO 的協議
所以幾乎萬年不變
但換個角度把它當作交付產品的最低水準來看
能 《持續改善》 的東西實在太多了

從這個角度看的話
其實也滿接近 PMP 的 Quality Management

The original Quality Management Task Force accomplished the difficult task of developing an initial QM framework. As with the concept of quality itself, the QM framework is not a finished product, but a progressive step toward the asymptotic line of perfect quality.
ref: Quality Management

在多個團隊的情形下 DoD 會是基於所有團隊都能做到的程度作為最低水準
而每個不同團隊的 DoD 會因為能力不同而略有高低
當所有團隊的能力提升時
整個產品的 DoD （即產品交付水準）就會提升

《第五項修練》所提的建立學習型組織
第三項核心修煉「共同願景」
也許可以透過這項修煉來建立共同的 DoD 願景
(作為軟體工程師我相信大家心中對自己所交付的水準都有所期待的)

完成第三項核心修煉之後下一個修煉就是「團隊學習」
書中定義組織的最小單位就是團隊
我想這裡團隊除了聚焦在 (Dev) Teams
也可以稍微放大一點去思考整個 Scrum Team

順著第五項修煉的做法推下來
誰會是最在乎 DoD 的呢？
當然就是組織管理者(Manager)了
不過此時書中又寫了一句
「領導者的個人願景不等於組織願景」
因此為組織訂立 DoD 的願景也不是一聲令下那麼的容易
慶幸在 Scrum 中有 Scrum Master 的角色有又兼具 Facilitator 職能
剛好能派上用場協助 Manager 和 Scrum Team 之間找出 DoD 的願景

當 DoD 訂立了之後要怎麼讓他真正有用呢？
過去的一些經驗會發現 DoD 失去效用的其中一種情境

為了趕上線或是 PO 的催趕下
抑或是團隊不想面對 Undone 或 Sprint Fail
因此團隊捨棄了 DoD （例如：自動測試降級為手動測試）
而 PO 也想要趕快上線所以 PO 也妥協
後來東西都上線了 review 也做了
團隊想要把測試補完
但原本的 item 因為被視為已經上線所以 Done
（我想這也是為什麼 DoD 不該只是和 PO 的協議而已）
導致該被列為 Undone 的就成了 Never Done 了

在課堂中提到兩件事

Don’t try to be nice as a PO, but still can be nice as a person.

PO 應該對 DoD 踩著線，Undone 就是 Undone
否則就是做出一個 死松鼠肉漢堡

而團隊也必須勇於承認自己的能力不足
或是 Sprint Planning II 做的不夠全面 … 等等
有 Fail 的時候 Retrospective 才有意義
否則其實也是僥倖的心態不會真正的改進

而在團隊願意在維持 DoD 的狀態下承認自己的不足
PO 此時才應該 be a nice person 必須相信團隊是自組織團隊
且團隊會透過一次次的 sprint & retrospective 成長
讓 DoD （交付品質）越來越接近極致

Faster is Slower

快即是快、慢即是慢
想要更快？
那必定是捨棄了什麼
可以想像一下一個賽車團隊
在技術能力沒有提升的狀態下怎麼讓車更快？
大概就是能拆的就拆能輕量就輕量
而拆到最後
往往犧牲的就是安全性

從 DoD 的角度思考
DoD 即交付產品的最低水準
既然都是最低水準了
為了快一點而捨棄
整個產品的水準就是向下沉淪
蟲就開始越來越多 🐛🐛🐛🐛🐛🐛🐛🐛
惡性循環就開始

團隊怎麼樣做到真的快
那就是要提升團隊的能力
讓開發速度變快
例如團隊不熟悉測試就加強寫測試的能力
而不是為了求更快而捨棄應該加強的能力

若不給團隊空間提升能力
使得團對一直靠走捷徑或是加班來完成需求
那麼遲早會撞上人月神話的

這篇關於 Roles 的部分就寫到這邊
感謝大家有閱讀到最後