《Real-World Kanban》企業看板的實務運用案例
《Real-World Kanban》這本書收錄了四個使用看板的真實案例。我對於第二章的企業看板（Enterprise Kanban）案例特別有共鳴，因此將此章節的內容做了濃縮與整理。
公司背景
這間公司已經有 100 年的歷史，作為計算領域的早期先驅之一，該公司擁有沈重的技術包袱，超過 300 個在運作中的系統。這是一個很大的挑戰，因為該公司必須跟許多不具備技術包袱的新公司競爭。這些競爭的公司積極有效率，該公司必須提供效率並且讓產品現代化才能競爭。
如下圖所示，該公司的行銷部門有三個單位，每個團隊負責特定的細分市場。IT 部門也分成三個單位：開發、變更管理和維運。
該公司有員工 650 人，其中約 100 人參與新產品開發，所有員工都以某種方式直接或間接地受到 Kanban 影響。
那麼，該公司主要面臨的挑戰是什麼呢？它們需要更快的交付吸引顧客的現代化產品，以保持市場競爭力。
為什麼改變是必要的
該公司在初期採用敏捷取得了初步的成功，但是大型專案還是拖延了太長的時間。該公司剛剛中止一個早期的專案，該專案是為了更新產品平台，該專案已經逾期超過 18 個月，而且離完成還很遙遠。即時團隊敏捷也不代表公司也敏捷。
似乎沒有人知道正在開發的產品想法的確切狀態。這些想法存在於幾個 Scrum 團隊的產品待辦清單中。在某些情況下，這些想法處於不同的開發測試階段。
新增 Enterprise Kanban 來查看產品想法的真正進展就成了一個自然的步驟，這將使我們能夠了解產品想法目前處於哪個階段。讓我們來看看如何使用看板解決這個問題。
我們是如何開始
我們邀請相關的人員和團隊，並介紹了我們的發現和原因以及我們想要嘗試的四到五個改變。然後我們徵求回饋，看看他們可能會考慮嘗試哪些。
我們透過 thumb voting (拇指投票) 來收集大家的想法，thumb voting 是一種非常簡單的決策技術，可以幫助團隊立即採取行動。
- Thumb up 表示「我們來試試看。」
- Thumb to the side 表示「我不確定，但是我願意試試看。」
- Thumb down 表示「不可能，這太瘋狂了。」
經過大家的投票以後，我們提出的五項變更中有四項獲得了同意，我們就先從大家都認同的改變開始做嘗試。
建立 Kanban Board
我們必須先決定在看板上放什麼。因為每個部門都有自己習慣的做事方法，因此，我們決定僅在看板上包含產品想法和功能。產品想法代表具有客戶價值的事情，功能代表產品裡的功能改變。
當決定好看板上呈現的資訊後，我們將各團隊正在進行的產品想法，映射到看板上。至此，我們已經看到了看板的好處。我們可以更輕鬆的了解進行中的產品創意的數量和真實的開發狀態。
將看板放在哪裡是另一個重要的決定。這個看板將四個部門連結在一起：行銷、開發、變更管理和維運。最後決定將實體看板放在開發團隊所在的走廊位置，因為開發團隊會最常與這個看板互動。我們每週有兩次的站立會議，也可以確保其他部門的代表每週會看到兩次。
聚焦在 Flow，而不是 Sprint
看板就位以後，我們要求開發人員考慮「flow」，而不是不斷的運行「sprint」。這個措施會減少等待的時間，將會允許開發人員致力於完成產品想法，直到想法完成並達到正確的質量，而不是僅僅因為 sprint 已經到了最後一天。這意味著從「date-driven」轉換成「quality-driven」。
流程是如何運作的
為了讓流程有用，使用該流程的人員必須擁有所有權。因此，流程必須簡單。下圖顯示 Enterprise Kanban 的工作流程：
關於協同設計（Collaborative Design）
這個活動有三個主要目的：
- 減少等待時間：通過多樣的思維方式來獲取多種觀點，有助於加速設計和決策過程。
- 消除團隊成員中「小齒輪」的感覺：每個團隊都有一名成員參與，他會將對解決問題的過程與資訊帶回給團隊。
- 獲得高度創意：我們避免將問題分解成將產品想法融入到現有架構的蹩腳練習，我們的目標是為任何問題提供兩種解決方案。
引導者通常由開發團隊裡的 SM 召開與主持會議。每個團隊都有一名開發人員參加會議，必要時還會有專家參與。會議期間，會針對產品想法做深入的發想與討論。
這個活動是希望有各種不同角度的意見，並鼓勵參與者學習彼此的想法。必要時，也可以嘗試讓各團隊的開發人員論流參加。
看板的設計
在這個案例裡 concept 是一個特殊的用語，我們暫時可以把 concept 當成是一個產品想法，這個想法會在看板上流動。
- Product Ideas：每個行銷單位負責在這裡準備兩個產品想法。
- Next：團隊接下來會進行的三個產品想法，這也是我們開始測量 lead time 的地方。行銷部門和開發部門的主管每 14 天會在看板前開會一次，審查接下來的優先產品想法。
- Ready for Dev：評估不同的解決方案，並瞭解哪些團隊將受到影響。正如同前面提到的協作設計會議中看到的那樣，每個團隊至少有一名成員參加了會議。
- Dev：產品想法在多個團隊中進入開發階段。在產品想法進入 System Test 之前，團隊和產品想法所有者必須驗證可用性與用途。
- System Test：從系統角度檢視產品想法是否能通過基本的驗證，例如可維護性、穩定性等等。
- Production：該 release 部署到生產環境。如果有必要，會設定對應的配置（configuration）。
- Acc. Test：產品想法所有者對最終的體驗做驗收。
- Ready to Use：準備好讓顧客使用。
- Customer Usage：這階段代表客戶的回饋。如果他們喜歡它並使用它，那麼它就被認為是 Popular； 如果沒有成功，就被認為是 Oh Crap！
確保每個行銷單位都得到公平的資源
每個行銷單位都專注於找到下一個最有可能在市場上取得成功的產品創意。單位負責人每 14 天看板前開會一次，審查優先事項。 這保證了透明度。
每個行銷單位都獲得同樣的開發資源 (各 1/3)。如果每個單位的負責人都認為某個產品想法或改進對公司更有價值，可以調整該規則。
開發團隊如何決定做什麼工作
關於開發團隊工作類型的比例，我們制定了簡單的規則：
- 50% 的工作以產品想法為導向，也就是來自於企業看板。
- 20% 的工作是關於改進（improvement）。
- 20% 的工作用於修復錯誤（bug fixing）。
- 10% 的工作用於快速修復、回答問題等。
如果以上這些資訊都呈現在「企業看板」上，會讓看板的資訊量超載，失去原本跨部門溝通的用途。因此，我們鼓勵團隊建立各自的「團隊看板」，視覺化工作項目，更直覺得觀察團隊目前的進展。
因此，「企業看板」呈現的是產品想法的進展，「團隊看板」則是呈現在開發細節上的進展，例如我們經常會將一個比較大的產品想法，垂直切割成數個比較小的工作項目，這會使得團隊能夠更輕鬆地取得進展，並且帶來靈活性。
每週兩次的站立會議
每週我們會舉辦兩次的站立會議，每次的會議時間為 15 分鐘。
首先，我們希望每個單位都有代表人參加。因此至少有三位行銷人員（因為有三個行銷單位）、六名開發人員（每個團隊一名加上工程主管）、一名變更管理人員和一名維運人員，根據實際需要邀請專家參與會議。
一段時間以後，維運人員表示，這個企業看板上很少需要他們的意見，因此我們將出席規則簡化為：如果企業看板上有一些感興趣的內容，你就來參加站立會議。我們發現這樣的效果更好。
這個會議主要在找出是否存在阻礙進展的障礙，為了確保會議的順利進行，我們從看板的後面往前走。如果發現障礙，我們會問誰來解決這個問題。我們將分配一個負責人處理該障礙，我們會避免在會議中深入討論該問題，因為那應該在之後進行。
在結束會議之前，我們回顧重點，例如誰負責追蹤某個障礙。我們以「謝謝大家，今天就到此為止」正式結束了會議。
使用 Company Demo 取代 Sprint Demo
當開發團隊使用 Scrum 時，他們會進行 Sprint Demo。但是這種演示方式帶有開發偏見，而不是著重在用戶價值。
因此，我們將 Sprint Demo 替換成 Company Demo。發布間隔為四週，我們會在發布前一天進行一整天的演示。在這個活動中，團隊展示了新產品想法，讓整個公司的人員都能看正在發生的事情。
另外，我們在演示的議程中加入一個步驟。基於上一個版本，行銷部門將演示產品是怎麼被使用者使用的，以及分享使用者回饋和評論。這個方式受到開發團隊的高度讚賞，並讓開發人員有機會了解使用者如何使用產品。
更有效地使用指標
測量不是為了測量完美程度，它們是關於獲得基於事實的回饋來判斷你是否有所進步。
我們追蹤了兩個指標：「Lead Time」、「Popular 階段和 Oh Crap 階段的比例」，這些指標顯示團隊在交付價值方面的表現。
Lead Time 的計算從產品想法進入 Next 階段開始，直到 Ready to Use 結束。之所以選擇這兩個邊界的原因是因為在我們的控制之下。
每月一次，開發部門主管會從每一個開發單位召集一名代表，在看板前進行「改進脈動」（improvement pulse）或「快速回顧」（quick retrospective）。
這個會議非常簡單，主管審查指標（Lead Time 和使用者回饋）、審查看板（是否清晰、易於查看且有用？），並對看板進行必要的更改。 會議通常非常快，大約 15 分鐘，有需要的話立即針對看板使用方式做修改。
開發團隊在各種工作類型花費的比例
我們估算了每個團隊花費多少精力在各種工作類型上，並將這些資訊顯示在實體看板頂部的區域中。
統計結果顯示，前端團隊和後端團隊在各類型工作所花費的精力，大致符合下圖左邊的目標規則，例如 50% 的工作用於產品想法上、20% 的工作在於工程的改進項目等。
如何知道產品想法上市的時間
我們要怎麼回答「我什麼時候可以拿到我的東西？』針對這個經典的問題，我們將過去完成的產品想法進行採樣，並找出 95% 的位置，我們稱它為 upper control limit (UCL)。
下圖顯示產品創意交付時間的一個樣本，每個直條圖代表一個以交付的產品想法，垂直刻度顯示該產品想法所需的天數（lead time）。UCL 為 105 意味著 95% 的產品想法將在 105 天內交付。
這有助於管理客戶的期望，並知道如果他們想要達到特定的時間範圍或季節，何時開始準備新產品。
過去我們也嘗試使用以下的估算方式：small (兩到三天)、medium (一到三週)、large (超過一個月)。然後，我們將估算與交付時間做關聯。
猜猜看，估算是否可以很好的預測你何時可以收到你的東西呢？
在這個案例中，令人驚訝的是估算與交付時間沒有什麼關係。Small 的項目不見得花費比較少天，large 的項目也不見得花費比較多天。
如果估算不是影響交付時間的主要因素，那什麼才是呢？在這個案例中，有兩個因素：等待發布的時間、獲得專業技能協助的時間。
後來，在我們成功減少等待時間後，我們發現估算和交付時間之間存在某種相關性。 但在我們先解決等待時間問題之前，我們無法看到這一點。
如果您團隊的工作僅佔總價值流的一小部分，那麼你的估算可能無法準確地表明何時可以獲得產品。
我們如何找到第一個可以改進的機會
看板讓辨識瓶頸變得非常容易。在我們的看板系統中，因為有 WIP 的限制機制，所以不會發生某個階段有一大堆的工作在排隊。
所以，我們更近一步分析交付時間（lead time）的關鍵組成部分，看看是否可以找到改進的機會。我們來看看下圖能告訴我們什麼資訊。
從這張圖所示，我們傾向於「Test to Production」作為改善的起點，但是數據很少，感覺不是太有說服力。我們走到變更管理團隊（負責系統測試和生產更新的團隊），詢問他們對情況的看法。
變更管理團隊是一個由 9 人組成的團隊，負責在 70 多個系統中實施變更，他們有很多事情要做。
經過與他們的討論之後，他們決定從三個方面解決這個問題：
- 在變更管理團隊中引入團隊看板，以幫助他們確定工作負載的優先順序、贏得時間來確保品質、減輕壓力並促進團隊合作。
- 們停止對版本進行後期更改（late changes）。 我們在開發、變更管理和行銷之間就版本變更的截止時間達成了協議，並確保每個人都遵守協議。
- 我們邀請開發人員將自動化測試場景新增到我們的系統測試環境中。 這簡化了測試，更重要的是，測試獲得了回饋。
經過這些改善之後，我們的成果如何？
我們有進步嗎？這是最重要的問題。 如果我們沒有可以指出的改進，那麼所有這些變化都毫無意義。我們從已發布產品想法的交付時間開始。
正如你在圖表中看到的那樣，交付時間隨著時間的推移呈下降趨勢，因此縮短上市時間的努力似乎得到了回報。 我們可以從下圖中感受出這一點。
2013 年第一季發布的產品想法的交付速度大約是 2012 年第三季的兩倍。
正如我們希望確保我們確實在改進一樣，我們希望確保我們運送的東西對客戶有價值 — — 實際上可以出售的東西。 圓餅圖顯示了我們在這方面的表現。
我們透過在發布後詢問客戶和最終用戶是否對交付感到滿意來了解價值。你或許還記得，我們在看板末端的兩個部分來記錄結果：「Popular」和「Oh Crap」。實際上有兩種不同的方式讓某些東西變成「Oh Crap」。
第一種類別是客戶拒絕了我們的交付（customer rework）；另一種類別是我們自己因為不滿意而中止交付程序（dev rework）。
無論是哪一種類別，佔整體的比例都非常的低，這意味著我們做得還不錯。
改善前後溝通方式的差異
下圖顯示該公司在引入企業看板之前，溝通方式被拆解成好幾個獨立的片段，強調的是個部門之間所需的流程工件。
整體的回饋很晚才會獲得，sprint 的承諾是針對局部的變更，對於最終產品想法的進度很難掌握。
下圖顯示這些改善導致截然不同的成果。 今天，在與開發人員分享產品想法之前，我們獲得了關於客戶價值的第一個回饋（如果我們理解並能夠溝通的話）。 產品適合性的驗證（了解解決方案是否滿足最優先的期望）持續發生。
在 18 個月的時間內，我們成功地將交付時間縮短了 2 倍。看板幫助我們做的是讓事情的實際運作方式變得可見，以便我們的流程可以即時調整。
注意到我們沒有做的事情也很有趣。 我們並沒有根據某種流程方法（例如，「你有多敏捷？」）或組織模型來決定改進的方向。
我們檢視流程中端到端的觀察結果，以決定下一步需要改進的內容，我們堅持下去直到完成。
你也可以做出自己的改進
你可能會發現自己處於類似的情況，你希望可以端到端改進工作流程。這裡有一些建議可以幫助你克服這些挑戰：
- 可視化整個價值流： 讓管理階層參與端到端的改進，而不僅僅是一小部分。 只有當我們看到整個客戶旅程時，我們才能釋放最大的潛力。
- 嘗試透過小實驗來做出改變：一切都是第一次。 如果你的第一個想法失敗了，可以嘗試一些更小的想法，但不要推遲旅程。 進行一些小實驗來了解它們是否有效。
- 談論改變： 聆聽並且交談。 將人們視為有思想的人並提出更好的選擇。 如果你堅持談論足夠長的時間，即使跨越組織邊界，也有可能改變舊的慣例和習慣。
如果你喜歡我的文章，歡迎「拍手」給我支持，或是「Follow」我，讓我提供更多的優質文章給你。
