當你要開啟一個 LeSS 活動. 你需要進行 LeSS 啟動會議 (Kick off meeting), 讓團隊知道我們為什麼需要做這件事情, 目標是什麼, 團隊成員有誰, 以及我們怎麼合作來完成工作. 這些事情對於大多數人來說是很重要的.

那何時需要召開 LeSS 啟動會議, 基本上可能有三種時機

(1) 正要開始大型和複雜的新計畫

如果你的計畫十分龐大和複雜, 是很有需要再開始就把大家聚在一起, 跟大家說明清楚目標和現在狀況是什麼.

(2) 大部分的團隊成員是新來的

如果成員大多是新召募或是從其他團隊過來的, 這時候也需要有個會議, 重新介紹這個計畫在做什麼, 團隊的文化, 和團隊是如何協作的.

(3) 一段時間(一年)

當團隊執行計畫一段時間後, 需要再次召開這種會議, 讓大家重新再對焦一次, 展望未來, 讓團隊可以更凝聚.

那誰需要來參加這個啟動會議呢? 基本上, 團隊所有相關人員都參加. 產品負責人, ScrumMaster, 團隊, 利害關係人, 以及可能需要支援的其他團隊的成員. 我知道這些人要聚在一起不容易, 但是為了讓大家知道我們是在同一條船, 我們要往哪邊去, 這樣的成本是值得的.

那 LeSS 啟動會議的議程會包含哪些呢? 可以包含以下部分, 但是不限於這些範圍, 可以根據你的需求加以調整

(1) 團隊組成

LeSS 一開始需要建立團隊, 團隊建立後很多事情才能開始談, 像是團隊成員的熟悉, 工作要如何協作等等. 因此, 啟動會議第一件大事, 就是要組成新的 LeSS 團隊, 藉由前面所提到的團隊組成流程, 讓大家自己決定要誰一起打拼, 大家要怎麼樣一起合作.

這樣做的一個目的, 是讓團隊成員一開始就要自組織, 讓他們知道很多事情需要自己決策, 不該是讓其他的人幫你想. 另外, 這個活動是高度雙向溝通, 讓團隊成員一開始就要有參與感. 不該在啟動會議時就讓大家覺得都是上面說了算, 都是單向佈達, 我們只是來做事和背書, 這樣不是 LeSS 想要的.

(2) 計畫範圍

當團隊組成之後, 接下來就是要介紹這個計畫相關資訊. 以下是常見的需要跟大家介紹的項目. 我們是從商業的角度, 客戶的痛點和需求來說明. 通常是由產品負責人來介紹, 或者有些部分可以由部門主管或高層來開場.

a. 計畫的願景
b. 計畫的範圍
c. 市場現狀
d. 計畫的展示: 並非所有計畫都是從頭開始, 如果已經有東西已經存在, 這時候可以展示已經有的東西給大家看看, 並且所有人都知道所有東西, 這時候也是一個學習的機會.

這邊也是可以以雙向的方式來進行, 給團隊成員一些資訊, 讓他們分析哪些比較重要, 或者是給於回饋, 這樣的交流會讓團隊成員對於計畫的願景或是市場現狀, 可以有更深入的體會.

(3) 團隊現狀

這個部分聚焦於計畫所要處理的技術部分. 他會介紹系統和技術相關的做事方式. 因為團隊成員可能來自不同地方, 原先的開發方法不同, 需要先對齊一下.

a. 系統簡介

有計劃是有之前的系統, 或者是有些雛型在. 這時候可以跟大家介紹. 可以從系統功能, 或者是系統架構開始. 讓圖隊成員對現存系統有個全貌.

b. 開發流程

因為大家一起進行工作, 對於技術上的協作要如何進行, 工程師都會很想知道, 所以你要先說明大家可能的開發流程是什麼. Build 會如何產生, 開發環境是如何建置出來的, 單元測試會怎麼做, 我們會用什麼工具管理開發流程等等. 這些需要讓大家同步和交流.

同時這個時間點, 也是一個跟大家分享好作法的時機. 你可以將某些好的作法介紹給團隊知道, 尤其這些好的作法是來自內部團隊時, 一方面可以讓這些團隊有舞台可以表現, 另一方面也讓其他團隊有危機感, 讓內部有相互學習相互競爭的氛圍

c. 工程實踐練習

因為 LeSS 不會光說不練, 單向溝通, 所以需要保留一點時間讓團隊成員一些做些事情. 這時候可以通過搭擋編程 (pair programming) 的方式, 實際來練習一些工程實踐, 一方面是推廣, 一方面也讓團隊開始學習. 至少搭擋編程這個時間點就可以開始練習.

(4) 初始 PBR

當 LeSS 啟動時, 要到可以開始第一個迭代, 有件很重要的事情, 就是需要一份產品待辦列表. 這份列表不需要很完整, 但是至少要能讓團隊處理幾個迭代, 然後產品負責人再持續增加和梳理. 當有了這些內容後, 接著就要進行第一次梳理的活動, 在 LeSS 中我們稱為初始 PBR (initial product backlog refinement).

為什麼我們需要 初始 PBR 呢? 首先, 就如前面所說的, 可能很多成員不清楚這個計畫, 需要特別介紹和花時間釐清. 另外, 這份清單可能以前就存在了, 可能有些訊息沒有更新, 或者不清楚, 因此需要再次確認. 就算內容清楚, 團隊成員也需要再次進行估算, 當初的情境和現在不同, 之前的估算到現在可能不適用.

那誰需要參加這個活動呢? 基本上是全部的人. 產品負責人, ScrumMaster, 團隊, 領域專家, 用戶, 支援團隊, 高層等等. 讓大家可以一起來了解這個計畫的需求是什麼. 因此, 會需要一個比較大的場地, 才能讓這些人在一起討論.

那時間需要多長呢? 應該需要一天或一天半以上. 這個時間要怎麼估算出來呢? 假設一個 LeSS 計畫中有 5 個團隊, 每個團隊在一個迭代中需要處理 4 個故事, 這樣一個迭代就需要 20 個故事. 如果需要準備 2 至 3 個迭代的量, 可能就需要 40 到 60 個故事. 如果你一小時能梳理 2-4 個故事, 一個迭代的故事量你需要處理 5 到 10 個小時.

除了進一步釐清故事內容之外, 初始 PBR 也可能討論一下事情

a. 發佈計畫

有些組織高層還是希望在一開始時, 能給他一個規劃, 這個計畫大約何時可以做出來. 大多數的組織不會使等你做幾個迭代後, 有了一些資料再來進行推估. 為了能夠回答這個問題, 產品負責人和團隊可以藉由初始 PBR 這個討論, 一起共商出比較可能的時程出來.

圖片來源: https://www.scrumdesk.com/start/manual-for-scrumdesk-start/release-planning/

b. 故事地圖

如果是產品負責人直接和團隊解釋需求, 這樣可能比較無聊. 並且需求的數量可能也不少, 如果只是循序介紹, 無法看出全貌以及優先順序. 這時候可以利用故事地圖 (story mapping) 方式來介紹. 故事地圖的方式可以讓大家一下了解全貌, 並且讓大家知道哪些是先要完成的, 並且每一堆需求想要達成的目標是什麼, 以及要如何衡量是否有成功達到當初期待的結果.

c. 架構設計

有時候在一開始的時候需要知道 high level architecture, 這時候可以安排個 design workshop, 讓所有人一起來腦力激盪, 思考怎樣的架構設計是適合目前的計畫, 我們要怎樣來開始這個計畫的實作. 這對於有些複雜的系統, 或者是某些關鍵的技術來說, 一開始的 design workshop 是很有幫助的.

最後附上一個可能啟動會議議程供大家參考. 這個啟動會議總共需要兩天時間. 第一天早上會進行分團隊的活動, 所以一開始就要大家自組織, 就要參與其中. 第二天早上也有安排練習單元測試, 一方面強調測試的重要性, 另一方面讓大家開始寫程式前就練習怎麼測試. 初始 PBR 分成兩天下午來舉行, 避免同一類型玩一天, 大家會感到疲乏. 此外, 釐清需求時也需要給團隊成員時間去思考與沈澱, 尤其是複雜系統或是剛開工的系統, 更是需要多點思考的時間.

時間 議程
第一天
09:00-09:10 開場
第一天
09:10-12:00 團隊組成
分 feature team
制定 工作協議
制定 完成的定義
第一天
13:00-15:00 計畫範圍簡介
計畫願景與目標
市場現狀
第一天
15:20-17:30 初始 PBR – 第一部分
影響地圖
故事地圖
第一階段的目標和衡量方式

第二天
09:00-10:30 團隊現狀
系統架構簡介
開發工具和流程介紹
第二天
10:50-12:00 工程實踐
單元測試演練
第二天
13:00-15:00 15:30-17:30 初始 PBR – 第二部分
梳理需求項目