黃國瑜&黃意鈞2020-05-29
引言
這幾年在敏捷（Agile）圈子吹起了一股學習引導的風潮，也讓我因此結交了很多敏捷圈子的朋友。 在這些朋友當中，Vince是最讓我感到印象深刻的一位。 Vince長期活躍於敏捷圈，目前是KKTV產品研發中心總監。 如果要用一個關鍵詞來形容他，我會說他是「推坑王」！ 因為他不僅自己開始學引導，也介紹了一大群敏捷圈子的朋友來學引導，而且除了在不同領域學習，他也不藏私地與他人分享他的學習以及實踐中的體會。
因為結交到越來越多敏捷圈子的朋友，有一天我再也忍不住，想要以一個外行人的角色，瞭解敏捷到底在做什麼，以及引導在敏捷的實踐到底扮演了什麼角色，所以我就對Vince發起了邀約，Vince也豪爽地一口答應，也因此催生了這篇文章。
在這篇文章中，Vince分別談到了敏捷的本質，以及Scrum的幾個核心概念—Sprint、三大角色、五大會議。 此外，Vince也談到了他在運用Scrum帶領團隊的具體實踐與心得，還有引導在Scrum所扮演的角色。 全篇內容主要為Vince的口述，然後再由我整理成本文。
關於黃國瑜 Vince
Vince是視頻串流平臺KKTV的產品研發中心總監，同時也是臺灣元智大學資工系的兼任教授。 他在攻讀博士學位時，研究的是高效能數據探勘演演算法（High Performance Data MiningAlgorithm），取得學位後歷任研究機構研究員、科技公司工程師與Scrum Master。 他自許成為一位「持續改善者」（Kaizener），希望持續學習並且與團隊成員共同成長，實踐聖雄甘地所說的「成為你想要在世界看到的正向改變」（Be the change you want to see in the world）。
關於黃意鈞 Ivan
Ivan是Open Quest的核心引導師，也是國際引導者協會IAF認證的專業引導師（CPF），並且擁有生態學、系統動力學及管理學等三個碩士學位。 他長期為各式組織提供組織發展的引導服務，並且也引導跨領域利益相關人之間的對話與協作。 除了引導，Ivan也熱衷於研究及實踐系統思考、行動科學及調適性領導，希望可以結合不同領域的方法與夥伴，致力於人類社會的可持續發展。
敏捷的本質是一個思維模式
每個人對於敏捷的詮釋不一樣，所以就形成不同的派別。 回到源頭，敏捷就是一個mindset （思維模式）：在面對世界多變的情況下，如何快速調適自己和團隊的腳步，去因應不同的變化。 以專案管理為例，傳統專案管理會需要押上時程、資源與步驟，但是對於敏捷而言，這些東西都是死的，難以因應外在環境的改變。 即使你押了時程與資源，事情還是可能會變，資源還是可能會不夠。 敏捷是一個大的想法，大約是起源自1980年代，隨後從這個想法衍生出不同的作法，而Scrum 是目前其中一個比較流行的作法。 一般來說，在談到Agile都會談到Toyota，他們雖然沒有定義敏捷這個詞，卻貢獻了很多想法，其中一個就是在業界常提到的PDCA （Plan-Do-Check-Action）。 這個PDCA的迴圈如果一年才做完一輪，反覆運算學習的週期就會太長，因次Toyota在他們工廠做了很多事情縮短週期、加快PDCA的迴圈。 雖然敏捷被運用在許多領域，但是這種快速反覆運算的思維與作法特別符合軟體開發的需要。 相較於軟體開發，傳統製造業的開發成本很高，可能一個硬體開發失敗就會損失上千萬，因此比較不太容易接受失敗。 相反地，軟體開發比較需要的是人工以及人力的調控。 在寫程式的過程中，如果發現問題就可以馬上修一修，或是客戶有什麼問題也可以馬上修，因此成本相對低。 此外，硬體是上市前的成本就已經很高，因此較無法接受失敗，而軟體是上市前的成本不高，但是上市后的成本很高，所以敏捷的應用比較多是在軟體的開發。 Scrum是為了敏捷而設計的一套方法。 為了不要讓這個方法變得太難、讓大家比較容易接受，所以Scrum一開始就仿效英式橄欖球。 英式橄欖球會有爭球的動作，每一個策略的運用都是希望可以往前推進幾碼，這個持續的推進就是敏捷的精神，而基於這個精神，Scrum就設計了一套框架性的方法。
Sprint—一個反覆運算週期
Scrum的一次反覆運算叫做「衝刺」（Sprint），這是來自英式橄欖球的衝刺。 每一次的衝刺就是要做一輪PDCA，通常一次衝刺是一到四周，我自已喜歡的是一周，市面上比較多人喜歡的是二到三周。 雖然每一個團隊的衝刺週期會有不同，但是一個團隊的衝刺週期是固定的，這樣就會有節奏感出來，久而久之習慣這個模式之後就會比較順暢。
Scrum的三個角色
- 產品負責人（Product Owner）：敏捷是以產品為主，而不是以項目為主。 因為專案的週期比較短，團隊是為了這個專案而不是為了產品在做事情。 「以產品為主」指的是要把產品做好，「以項目為主」指的是只要把事情及時做完就好。 所以在以產品為主的敏捷團隊中，會有一個角色負責產品的走向，而我現在在公司的角色就是產品負責人。
- 開發團隊（Development）：開發團隊通常是一群人，而Scrum希望這群人能夠很頻繁地溝通，所以人不能太多。 一開始建議的人數是六加減三，也就是三到九人，後來改版為五加減二，這似乎是基於魔術數位「七」，超過七個人溝通複雜度會變高，反覆運算速度也會因此變慢。 但是，並不是所有的軟體開發都只要七個人就做得起來，有時候會需要更大的團隊，所以後來就有人提出Large Scale Scrum，主要是用在上百人的團隊。
- Scrum Master：負責觀察會議的進展與動態，讓大家覺察並且決定是否需要調整，不是去要求大家改變，而是讓大家覺察並做決定。 一開始如果大家對於Scrum不熟，Scrum Master就會教大家Scrum要怎麼走。 當大家熟悉了以後，他的角色就會變成觀察整個團隊或組織有什麼可以調整的地方。 Scrum Master注重流程並且也扮演引導者（Facilitator）的角色;他服務團隊、產品負責人，還有上面的利益相關人，並且讓團隊變得更好。 雖然Scrum Master可以被視為一個領導流程的領導者，但是他不是用命令控制（command and control）的方式。 我覺得要扮演好Scrum Master很靠個人特質，不同人帶起來的風格會不一樣。 我的做法是，當團隊碰到一些問題，有人可能會在團隊回顧的時候提出來，一開始其他人可能會不以為意，所以我會再觀察一陣子，讓子彈飛一下，等到有很多人開始覺察到問題的存在，我才會提議可以如何調整。 所以有人把Scrum Master比喻為保母，有些保母是小孩子一怎樣就去照顧，有的保母會傾向只是看著，只要沒有出大事就會放著小孩去學習，也就是所謂的「actively doing noting」，很自主式地知道自己不做事情：我知道這件事可能有問題，我也注意到，但是我先按兵不動。 有人則是一有風吹草動就會去干預，變成「actively doing everything」。 我去上課時老師有提到，如果一個小孩坐在椅子上，椅子離地面只有五公分，小孩子摔下來不會有事，有些保母就會衝過去扶，但是這樣一來，小孩就失去了學習的機會。
Scrum的五大會議
- 計劃會議（planning meeting）：在這個會議里，團隊會討論這次的衝刺要做什麼。 會議目的有兩個，一個是讓產品負責人跟團隊說這一次衝刺要做什麼、目標在哪裡，接著團隊夥伴會討論如何做到。 每個週期的第一天會開這個會議，會議時間的長短會因為衝刺週期長短而有不同，如果週期是兩周，計劃會議大概是兩小時。
- 每日站立會議（Daily Stand Up Meeting）：團隊會在每天固定的時間花最多15分鐘聚在一起，討論三個問題 ：昨天做了什麼？ 今天打算做什麼？ 遇到什麼阻礙需要別人幫忙？ 站著開會的原因是坐下來時間會拉長。 在會議中，每個人會輪流用兩分鐘回答上面三個問題，這樣團隊即使有七個人也不會超過15分鐘。 如果有些議題只需要跟某幾個人討論，就可以會後再聊，不需要佔用大家的時間。 這個會議的目的是讓大家每天有一個快速同步的時間。 有人說這個會議的目的是盯進度，我覺得不是，因為最重要的不是「你做了什麼」，而是「為什麼你要做這件事情」。 因為在圍圈的時候會有一個板子，上面會有大家正在做的事情。 雖然說不要超過15分鐘，我還是有看過有團隊超過30分鐘。
- 檢視會議（Review Meeting）：這個會議會發生在週期的最後一天，讓大家分享這一個週期的成果並進行討論，也可以邀請客戶參加，討論這個週期所做的東西是否與目標相符，時長大概一小時。
- 回顧會議（Retrospective Meeting）：在這個會議，大家會坐下來溝通，反思這個周期團隊的工作狀態與變化，時長大約一小時。 通常我們會用ORID的方法，討論發生了什麼事情、大家有什麼感受、哪些東西其實下次可以做得更好或是有不同的作法，話題可能涵蓋產品、開發、對外協調及內部運作。 在回顧會議最後列出行動的時候，有些人可能會列很多項行動，但是我會要大家不要那麼貪心，因為列得越多做得越少。 如果有很多行動，我會希望盡量聚焦在一、兩個比較優先的，其他只是作為參考，有空再做。 把前一、兩個行動做好，比列了很多行動卻都做不好還重要。 雖然有些人會說在回顧會議一定要產出行動，但是我認為更重要的是讓團隊有一個好好溝通的時間。
- 精煉會議（Refinement Meeting）：如果回過頭看看我們目前為止提到的會議，有計劃會議、檢視會議、回顧會議，看起來好像夠了，但是有時候事情的發生不會那麼準確。 有時候下一次的衝刺可能會需要新的東西（例如新的技術），做這些研究會需要時間，所以如果等到計劃會議才開始做，可能就來不及了，所以精鍊會議的目的是要能夠預知下一個衝刺的可能需求以及需要先做的準備，時長大概一小時。 我的心得是，精煉會議的精神是要「把模糊變清晰」，有些事情可能很模糊，透過討論就是要把大事變小事（例如一件很大的工作要如何分解），把模糊變清晰。 如果一次衝刺是兩周，精鍊會議通常是在第一周結尾或第二周開頭，例如第一周的第四或第五天。 之所以說「第一周的第幾天」而不是「星期幾」，是因為並不是所有的Scrum都是從週一開始，像我們團隊喜歡從周三開始。
有人說跑了Scrum會讓會議變多，但是如果細細去拆分時間的利用，你可能會發現沒跑Scrum的時候會議更多。 因為沒跑Scrum的時候，別人有事要找你，工作會隨時被這種非正式會議打斷，但是你不會仔細去算這些非正式會議的時間有多少。 我之前有算過，在跑了Scrum之後，一個衝刺花在會議上的時間大概是13%，可是如果沒跑Scrum，會議時間可能會佔20%以上。
Vince 運用 Scrum 帶團隊的具體實踐
我在安排團隊的工作時有幾個原則，第一個是隨時動態調整，第二是把工作依照重要性排序，第三是不要把時間塞太滿 。 在一般的專案管理，排了三件事情如果做不完就會加班，而Scrum的希望是，如果你每天都知道工作的狀況，就不會到了最後一天才在加班，做不完的時候可以提前讓產品負責人知道。 況且，如果那三件事原本就有依照重要性排序，而且最重要的事情有做完，這樣即使其他兩件事情沒做完應該也不會出大問題，所以是只有真的需要把那兩件事做完的時候才會加班。 此外，傳統的作法是把時間用工作塞滿，但是我在帶團隊的時候，習慣排到60%。 讓大家有60%的時間專心做事情，因為過程中可能會有變數，會有其他事情需要做，所以我的經驗是六分飽（60%）就好，即使是八分飽（80%），也還是可能會出事。 如果真的沒有變數、一切都很順利地做完也沒關係，可以提前先做下一周要做的第一件事情。 我相信每個人都可以認真做事，但是有些人會擔心員工擺爛，所以才會想要把時間都填滿。 團隊做不出來，我不認為是失敗，每個人沒有認真做事情，我也不認為是失敗，重點是有沒有提前去覺察到。 如果每天都有回顧，最後一天卻還是會出問題，我就會覺得是我的失敗。 很多事情你可能會覺得錯的是別人，但是我覺得事情會失敗，主管要負80%的責任。 或許我們應該要停下來想自己做了什麼事，而不是團隊做了什麼事。 在考慮要不要使用Scrum的時候，要回到最終你想解決的問題是什麼，或許Scrum根本就不合適，那你為什麼要硬用？ 硬用可能就會爛掉。 如果思維方式就是命令控制，這樣用Scrum也是會爛掉。 所以一個是主事者心態，另一個是想達到的目的。 如果不適合用scrum就不要用，因為它不是萬靈丹。 此外，團隊的素質也會影響Scrum的使用成效。 如果是技術不足，這時會容許他犯錯，並且留一些時間讓他能夠在技術上成長，此時堅持Scrum的做法可能就沒那麼重要。 有些人是技術很行，但是心態不行，例如我找五位高手一起做事，這樣出事的機會通常很大，因為大家都想要自己來，所以雖然會議都有參加，有問題卻不會講出來，所以這時説明大家調整心態就會比較重要。
引導在Scrum所扮演的角色
我之所以會學Scrum的原因是希望團隊可以溝通，但是溝通不是一個人說了算。 每日站立會議因為只有15分鐘，需要討論的東西不多，但是在計劃會議、檢視會議與回顧會議，如何讓大家能夠敞開心胸就會很重要，因此就會需要引導方法，而精鍊會議是為了協助團隊大事化小、模糊變清晰，所以也會需要引導方法。
至於做敏捷的人需要學到多少引導方法，我覺得這要看個人與公司的狀況。
有一些方法是要大團體才可以做的，例如一個團隊20人，裡面又分成幾個小組。 我目前很少有機會讓整個團隊做一個大的決策，所以這種團體比較大的引導方法就會學少一點。 而ORID焦點討論法、深度匯談，不論是一對一或是三、五人一起討論都可以派上用場，所以我就會想學。 當然我們公司還是有大的、整個部門的會議，但是因為我現在已經是主管，所以就傾向讓其他人去帶。 剛開始我兼主管又帶人做這個東西，會覺得怪怪的，團隊成員也會覺得很累，因為他們預設我是主管，會變得有點像是討好你。 我覺得大家都學了方法，或許要先想想你的意圖，否則如果是為了用而用，就可能會出事。
訪談後記：用敏捷的方法做敏捷
在與Vince聊過之後，我有幾個心得。 首先，從Vince的分享當中，我深切感受到他對於學習、分享與實踐的熱情;他不僅積極學習各種方法，也會留心方法的使用邊界：什麼時候可以使用，什麼時候不該使用。 如果是引導圈子的朋友，也許也可以從Vince分享他帶領團隊的心得當中，看見引導的精神。 對於敏捷，如果要選取兩個關鍵詞，第一個我會選「動態調整」，也就是要隨機應變，有時候你可能會因為團隊的狀況而必須暫停使用敏捷的「手法」，但是這樣做才正是符合敏捷的「精神」;第二個詞是「覺察」，注意當下的情況，關注團隊需要什麼，這也是動態調整的基礎。
希望這篇文章有讓大家更認識敏捷。 未來引導在敏捷的實踐可以扮演的角色還有許多探索空間，而我也相信敏捷的理念與實踐也會有很多我們引導者可以借鑒學習的地方！
