如何視覺化處理跨單位團隊相依性?
一般有在運作Scrum的小型團隊，會遇到相依性問題大多是在任務(Task)層級，因為每個衝刺的需求(story)已經先被PO梳理過了，所以團隊成員透過每天15分鐘的站立會議就能解決多數的相依性問題。但是如果團隊規模往上增加，例如一次有數個scrum team或者是由各部門代表組成的專案辦公室，就會需要額外的工具來管理不同團隊的相依性，而八月份剛好有 Scrum創始人Ken Schwaber所成立機構(Scrum.Org)的專家來台演講正宗的規模化敏捷(The Nexus Framework for Scaling Scrum)該怎麼運作，而講者之一剛好就是作者本人，現場將帶來最原汁原味的實務分享，有興趣的讀者可以直接跳到文章最後(完全不用管傑瑞的感受)，立馬手刀搶票去喔。設計思考活動後才是戰鬥的開始
前陣子傑瑞剛輔導完一個銀行生態圈案例，產品單位想跟電商合作信用貸款業務，希望能提供賣家不同以往的產品設計以及申請流程，因此專案的前半段很自然就會跟設計思考做結合，後半段則專注在釐清不同單位的分工與之間的相依性，而通常後半段才是最需要花時間溝通(吵得最兇)的部分，建議可以透過以下三個步驟來有效梳理團隊意見。
第一步:製作產品服務藍圖讓團隊先聚焦
對傑瑞來說，服務藍圖(service blueprint)比較像是用戶旅程(customer journey map)的延伸，用戶旅程適合拿來盤點現況，而當團隊已經從眾多點子收斂並決定執行的優先順序後，則適合用服務藍圖來盤點產品代辦事項。
服務藍圖可以簡單區分成三大部分:
A:客戶的新旅程 →包含新的方案、新的流程
B:客戶與前台的接觸點 →包含客戶可以看到的實體證據與接觸到的服務人員
C:支援前台運作的後勤 →包含後台人員、內部系統、外部資源等
另外傑瑞還會請PO與團隊一起標示這張圖上的最大風險點(貼紅點點)，提醒團隊成員盡早去了解新流程的可行性。
第二步:利用各單位產出檢查表確認相依性
等服務藍圖完成之後，該出力的相關單位也一併確認了，下一步傑瑞會準備一張單位產出表，縱軸為各單位(與產品製作相關度愈高的排愈前面)，橫軸為客戶新流程的步驟(也就是服務藍圖最上面的部分)，然後就會請團隊成員(各單位代表)幫忙回答以下兩個問題:
A:為了配合服務藍圖的新流程，你們單位需要產出什麼? →寫完請貼到自己單位與步驟的交集點上(藍色便利貼)
B:為了上述產出，你們需要哪個單位幫忙什麼? →寫完請貼到對應單位與步驟的交集點上(紅色便利貼)，並與該對應單位窗口聊聊(這個動作很重要!)
換句話說，第二個問題就是在嘗試找出不同單位(以及產出)之間的相依性，從這張表也可以很快看出目前專案的瓶頸是卡在誰家?以及是什麼原因卡住?這樣PO就能清楚瞭解下一步應該優先處理什麼問題。
這邊很重要的一個關鍵是要讓"存有相依性的上下兩家有一定時間對話"，除了讓被要求做事的單位知道人是誰殺的以外，唯有透過面對面溝通，才是釐清相依性的不二法門。
第三步:以終為始決定交付順序
等各單位彼此的相依性都確認好了(畫押)，就可以來排交付順序了。傑瑞會請PO先決定他的第一條交付死線(deadline)是哪一天?以及需要拿到的交付物(概念類似sprint goal)為何?接著就請各單位自己去移動(或複刻)剛剛自己寫的產出到下面這張表上，而各單位就會根據剛剛畫押的相依性自動去調整彼此的先後順序了，透過相依性的串聯也可以反過來檢視PO在死線設定的目標是否合理(有可能相依性跟外部機構有關，存有必要作業時間)，最後傑瑞也會請各單位針對交付內容事先寫上驗收條件並與PO核對過，以確保雙方對於交付品質有一致的水平。
記住，安排交付時程固然重要，但是讓PO與團隊成員能充分溝通才是這張表的精神所在。
照過來，正宗規模化敏捷在這裡
這裡是Scrum.org網站針對規模化敏捷的說明:
其中Nexus Framework的書籍也已經有中譯本可以購買:
而最重要的是下個月Scrum.org首次來台灣舉辦活動啊，錯過這個檔期真的不知要再等多久了，而且上面那本書籍的作者之一也會來喔，不買一本書給作者簽名怎麼說得過去，大家走過路過千萬別錯過，我們就預約下個月會場上見囉~(保證不是傑瑞見面會，請安心購票^^//)
如果喜歡傑瑞的文章，歡迎追蹤(follow)傑瑞並分享(share)給你的朋友。
👉喜歡這種類型或主題的文章，也別忘了拍手給傑瑞鼓勵唷
