如何導入 LeSS
1 導入原則
基本上來說, 導入任何新東西, 都是一種變革管理. 重點都不在你想推廣的那項東西, 而是如何讓人們心裡願意接受, 會認為現在是有必要去做這樣的轉變. 在 LeSS 中認為導入有三個原則[1]
- 深入集中 優於 淺薄廣泛
很多公司為了想要趕快看到成果, 或者是為了虛名, 因此一開始就希望全公司能夠一起使用. 但是一方面大家對於 LeSS 那時候還不太了解, 在不知道怎麼做的情況下, 這很容易影響恐慌, 進而導致大家反彈或是集體作假. 另一方面, 初期你能支援 LeSS 導入的支援也不夠, 有經驗的顧問和內部專家都是不足的, 你無法每個地方都顧到, 甚至連大部分都顧到都很難.
因此, LeSS 希望先在一組 LeSS 的產品團隊中, 把 LeSS 給採用好, 遇到問題好好解決, 該落實的實務 (practice) 有做好. 而不是很多產品團隊都開始用, 但是大多只用一點點, 並且沒有深入檢討改進.
- 由下而上 且 由上而下
有些時候第一線的員工, 他們最接近問題, 他們想要改變的意願是最強的, 因此很容易由底層發起要實施 LeSS. 但是導入 LeSS 需要組織調整, 並且在分工合作的方式也要做轉變, 因此會一瞬間就讓下面的人就卡關.
也有些時候上面的主管, 覺得目前工作流程不夠有效, 想要導入 LeSS 來改變. 雖然他有權利去做組織調整, 以及分工方式的改變. 但如果底下不配合, 或是沒有意願, 容易變成你說一動, 他們才開始去做, 這樣也無法真的有用.
所以最好的方式是由下而上且由上而下, 讓動機強的員工願意來做, 然後上層也願意積極配合和支持. 這樣才能讓導入的工作能長久和有效.
- 讓志願者來
強扭的瓜不甜, 因此在導入時, 通常需要詢問哪些團隊有意願, 讓那些團隊變成 pilot run的團隊, 這樣成功機率才能提升.
2 導入流程
對於導入的流程, LeSS 有建議一個流程[2]
- 教育所有人
很多公司說要導入一個東西, 就只是口頭上, 說公司現在要求要做哪個, 但是大家對他什麼都不知道, 這樣就開始了. LeSS 認為這樣是不可行的. 事前要先上課幾天的 Scrum 和 LeSS 訓練課程. 不過有點要注意的, 不要只是基層來上課, 高層或是第一線主管更是需要來參加, 因為如果你對一個東西都不懂, 你怎麼敢放心支持, 或是當有遇到問題時, 你也不知道要如何幫忙或是預防.
- 定義產品
有了相關知識後, 接下來就要跟相關的利害關係人討論, 例如產品主管, 技術組長, 管團隊的人, 思考適合導入 LeSS 做法的產品範圍. 怎樣切才能之後的 Dev Team們, 大多能處理, 可以不會造成太複雜的相依性.
並且產品的功能對客戶來說是有意義的, 他們可以一看就知道是跟他日常要處理的事情有關. 不會是從開發端的角度來切割, 也就是不是從系統架構或是元件來插解.
定義產品的範圍, 對之後規劃 Dev Team有著巨大的影響, 如果可以有有經驗的顧問一起討論, 可以降低導入的風險.
- 定義完成的定義
完成的定義可以幫助團隊逐漸改善, 並且也可以讓團隊擴大學習. 因此, 需要一開始就先定義好, 讓團隊知道對他們的要求是什麼, 讓他們在品質方面要注意.
- 建立適當的 Dev Team
知道產品的範圍後, 接下來就需要根據這個範圍, 建立出合適的 Dev Team. 一開始或許無法完全都是 Feature Team, 但是盡量朝此方向前進. 逼不得也許還是會有 Component Team 的形式出現. 但是要能透過擴大學習的做法, 讓團隊有機會略懂略懂, 日後要再調整 Feature Team 形式的 Dev Team才有機會.
- 只有 Product Owner 可以提供工作給這些團隊
LeSS 中的 Scrum 團隊要做什麼事情, 應該都是要 Product Owner 來提供的, 並且排出優先順序. 就算有隕石發生, 這些隕石也不應該穿過 Product Owner, 直接降到 Dev Team身上.
- 團隊裡沒有專案經理的角色
LeSS 認為團隊應該是要自組織的, 為了能讓這件事情能發生, LeSS 建議沒有專案經理的角色, 專案管理的工作由 Product Owner 和團隊成員來分擔, 因此不需要專案經理這個角色.
另外,在開發過程中需要面對的問題非常多, 我們無法在同時處理所有問題, 因此要從哪些開始呢? 在 [4] 中作者整理一些要面對的挑戰, 以及建議的處理順序, 我覺得很值得參考
- 自組織團隊 (Self-Organized Team)
- 跨職能團隊 (Cross-Functional Team)
- 統一的處理清單 (Unified Backlog)
- 團隊之間的協作 (Inter-team Coordination)
- 功能導向的處理清單 (Feature Oriented Backlog)
- 大規模測試 (Large Scale Testing)
- 持續規劃 (Continuous Planning)
- 日期導向的開發 (Date Driven Release)
|
第一階段 |
自組織團隊 跨職能團隊 統一的處理清單 |
|
第二階段 |
團隊之間的協作 功能導向的處理清單 |
|
第三階段 |
大規模測試 持續規劃 |
|
第四階段 |
日期導向的開發 |
3 如何挑選顧問
此外, 在導入初期, 因為內部對於 LeSS 認知有限, 適當地尋求外援是需要. 利用外援來幫助導入能夠進行比較順利, 避免歪樓歪太大. 此外也可以培育內部員工, 讓他們可以在一開始就接觸到對的東西. 那要如何挑選好的 LeSS 顧問呢? LeSS 有建議幾個面向:
(1) 最好有親身經驗
有些人從沒有用 Scrum 帶過專案, 只是上上課念過書這樣不行.
此外, 專案應該是商業上的專案開發, 不該只是社群間帶帶活動, 或是志工集體幫忙. 因為沒有商業上的真槍實彈和壓力, 那種 Scrum 活動只是遊戲. 練兵跟上場打戰是兩回事.
(2) 不要迷信證照
證照會過, 最多只能說他書念得不錯, 或英文能力不錯, 或是很擅長考試的遊戲規則. 但是真的上戰場打仗時, 能不能活下來那就很難說. Scrum 的導入, 難處都不在 Scrum Process, 而是在環境與人不配合下, 你如何引導, 你如何帶領團隊衝鋒陷陣. 這些不是證照可以檢查出來的.
(3) 評估一個人，而不是公司
很多時候你知道, 公司厲害不代表個人厲害, 那只是那個公司過往累積了很多成就. 所以, 你不用管他是哪間大公司, 而是他這個人是不是真的有本事.
(4) 具備技術上的深度與理解
這裡說的技術, 是指要用 Scrum 來進行的專案所在的專業領域. 例如如果是用 Scrum 來進行軟體開發的專案, 你對軟體開發要有一定程度的認識, 不是說你一定要會寫程式, 但是至少知道原理或是知道哪些該小心或注意, 這樣的顧問才能有效果. 很多懂 PMP 的專案管理師, 原先不在 IT 產業, 念了 Scrum 之後, 就能夠帶軟體開發的專案, 通常下場都不太好.
(5) 最好能長期參與
很多時候顧問上完課, 然後前 2-3 個迭代出現一下, 就能夠把 Scrum 跑好, 這通常是不太可能. 一般來說, 大約需要花 3-6 個迭代, 才能了解 Scrum Process 大約怎麼進行, 這還需要那個顧問在 Scrum 各個 event 都有參與. 所以如果只是上上課, 後面 Scrum event 不參加, 這通常效果也是不好.
除了上述幾點外, 個人覺得可以加上這幾點誤區:
(6) 可以觀察他過往發表過的東西
有些老師從來都沒有深入經驗的分享, 每次都是講同一套經驗, 或者是他都只能帶入門的工作坊, 又或是只說他在社群怎樣怎樣, 卻沒有商業上的案例, 這很明顯是有問題.
(7) 一直說他很厲害
另外, 如果他只是把一件小事情, 誇張地說他有多偉大, 然侯還到處宣傳, 每個社群貼, 每個討論群說嘴. 這個也是怪怪的. 因為大多數技術很厲害的人, 本身都是蠻低調的, 像馬克斯這麼囂張的不多, 就算他這麼囂張, 他也確實有很多別人做不到的實績, 而不是一點點小成就, 就拿出來展示.
(8) 到處跟名人拍照
這個也是很有趣的點, 如果你本身很厲害, 大部分是別人想跟你拍, 而不是你一直找別人拍. 就算找人拍, 也不會到處 show 他今天又跟誰合照了.
4 案例分享
在 LeSS 的官網中有不少案例分享[3], 大約接近 40 個案例, 大家可以去參考. 他們不少來自金融業和電信業, 我有整理出他們是那個行業別, 讀者可以根據行業別來挑選有興趣的案例.
|
案例 |
說明 |
|
Agfa Healthcare |
它是比利時一家提供醫院和臨床資訊系統的公司, 這篇文章講述採用 LeSS 的初始階段. 談論到教育訓練, 繪製價值流程圖, 組織敏捷教練團隊, Product Backlog 的處理, 團隊的組成和協調等議題. |
|
BMW Group – Unified Sales Platform |
Valtech 是德國 BMW 的供應商, 協助開發汽車直銷流程. 文章一開始說明了團隊導入之前的狀況. 接下來談他們如何轉型到多個 feature team 和 LeSS 的過程. 包含如何設計團隊, team building, 系統建構流程, 回饋和整合等等 |
|
BMW Group –LeSS Huge at Autonomous Driving |
本報告探討了BMW集團在自動駕駛部門採用 LeSS 的情況, 時間從 2016 年中到 2019年 10 月, 從時間軸的角度來介紹, 從一開始的教育訓練, 組織變革設計，定義一開始產品範圍, 怎樣從需求領域逐個開始. 此外也從技術的角度來述說, 尤其是分支策略以及架構設計等部分. 是一個非常完整的案例分享. |
|
Cash-in Comfort (假造的名稱) |
Cash-in Comfort (CiC) 可以對個人提供金融服務. 他有 3 個 feature team, 位於三個不同地點的小型案例. 本案例研究重點在於小型 IT 部門採用 LeSS 時所面臨的問題，並解決 LeSS 框架所暴露出來的障礙. |
|
German Big Insurance (假造的名稱) |
一家德國保險公司內的一個部門, 從最初採用 Scrum 到大規模採用 LeSS 的變化. 包含了該部門的重新設計, 建立需求領域, 各個LeSS 事件的實踐狀況, 如何 處理需求和 product backlog 內容. 還有各個角色的演進, 和各種遭遇的問題和處理. |
|
華為 |
這份報告敘述在2015-2016年, 華為在杭州的兩個產品開發部門的經驗. 一個是基礎平台(40人)，而另一個是產品(120人). 這次的經驗是先嘗試建立合適的組織結構，然後再增加輔導團隊的能力。 |
|
Large Dutch Bank (假造的名稱) |
這是一個荷蘭銀行的案例, 如何在 Spotify 的環境下, 使用 Go See 去找出問題, 並且導入 LeSS 的實驗來解決問題. |
|
Large Server Hardware Company(假造的名稱) |
這是一個大型硬體公司的案例, 怎樣從單一元件團隊, 到可以處理多元件, 以及變成 Feature Team 的演進過程. 以漸進方式可以兼顧時程, 讓團隊開始協作和學習. 含包括組織變革的過程. |
|
Nokia Network – High Capacity Network Gateway |
這次是諾基亞一個新技術的產品, 產品所應用的技術非常新且應用場景不確定, 因此用 LeSS 來減緩這個產品開發的風險. |
|
Merkur |
奧地利保險公司的大規模敏捷的旅程 |
|
Port of Rotterdam |
鹿特丹的案例, 四個團隊處理開發和 DevOps, 交付管理船舶交通服務 |
|
RBS |
蘇格蘭皇家銀行如何擴展 Scrum 以滿足大型組織的需求 |
|
Sys Store (假造的名稱) |
德國一家全球軟體產業公司導入LeSS 的故事 |
|
MTS |
俄羅斯最大的電信公司MTS的案例 |
|
Solarwinds |
SolarWinds 是領先的 IT 管理軟體供應商 |
|
Sita – Border Security |
SITA 開發的產品可協助世界各地的政府保持邊境安全的公司 |
|
Thales – Surface Radar |
泰雷茲TU 處部門（一個在具有國防需求的環境中運作的高科技嵌入式軟體開發部門）如何轉型為敏捷組織的故事 |
|
Very Big Bank (假造的名稱) |
大型投資銀行採用 LeSS 的故事
|
|
Y Soft |
描述一家根據學習結果不斷進行組織設計改造的案例 |
|
較小的 LeSS 案例 |
這邊的案例比較短, 但還算是完整的
|
|
其他 LeSS 案例 |
在 LeSS 官網外的, 但不算完整的案例
|
除了 LeSS 的導入案例外, 也順便看看其他不同框架的案例, 發現到一些有趣的現象：
- 作法不太一致
大多是各吹各的調, 每個顧問的玩法不一樣, 你不確定哪些是比較好, 哪些流程是經得起考驗
- 案例完整性和全面性並不足
有些只是 10 分鐘的影諞或是不到 10 頁的投影片. 或者只是某個開發過程的一小段, 例如需求處理, 團隊組建. 也有的雖然是將近一小時的分享, 但是沒有投影片, 像是座談會的分享.
- 關於工程實踐的部分不多
如果是要應用到軟體開發領域, 對於軟體開發的實踐還是要有敘述, 有些問題不是流程可以解決的, 像是分支策略，架構設計和持續整合等等, 如果可以描述一下在多團隊時如何處理, 可以幫助大家轉型的更順利.
但是從 LeSS 官網的案例來看, 你可以發現 LeSS 的導入流程大多很接近, 除了流程之外, 也有不少提出工程實踐落地的處理, 這是我覺得很不錯的地方. 對於接觸到新東西, 想要落實的人們來說, 他們比較容易可以依樣畫葫蘆.
接著我們介紹一個案例[5], 這是有關於德國汽車製造商導入 LeSS 的研究, 這家公司. 作者和這家公司進行了 7 次面談, 整理出他們遭遇到的挑戰, 以及關鍵的成功因素.
首先, 這家公司有四個產品導入 LeSS, 他們的背景資料如下
|
|
產品 1 |
產品 2 |
產品 3 |
產品 4 |
|
何時開始採用 |
2017/4 |
2017 年初 |
2017 年底 |
2018/3 |
|
參與人數 |
約 600 人 |
約 70 人 |
約 90 人 |
約 40 人 |
|
位置 |
德國 |
德國, 南非 |
德國, 波特蘭, 葡萄牙, 俄羅斯 |
德國, 葡萄牙, 俄羅斯 |
|
Feature Team 個數 |
15 |
5 |
6 |
3 |
|
迭代長度 |
3 週 |
3 週 |
3 週 |
3 週 |
|
使用框架 |
LeSS |
LeSS |
LeSS Huge |
LeSS |
作者收集到了各個產品團隊在導入過程中, 所面臨到的挑戰
- Product Owner 會需要由 2-3 個人一起扮演
- 如何可以正確地切產品範圍
- 產品複雜度高不確定是否可以成功
- Feature Team 個數太多
- 太多協調會議
- 如何建立敏捷思維和相關知識
- 傳統的職能角色, 導致容易形成穀倉效應, 只管自己角色的工作
- 經理們擔心會失去權力
- 如何將大的需求拆解成小的需求
- 處理不同 Feature Team 之間的文化差異
另外, 作者也歸納出能夠成功的關鍵因素
- 需要有100%的透明度, 可以激勵 Feature Team 去交付高品質的產出
- 綜合的培訓課程或工作坊, 可以讓 LeSS 的導入變得容易
- 員工需要儘早參與, 以減少變革的阻力
- 需要了解不滿意的員工在想什麼, 並且多對團隊說明變革隊組織的價值
- LeSS 背後的原理和動機, 需要好好溝通和宣傳
由這些關鍵因素可以看出, 事前的準備工作很重要. 在台灣常常會遇到明明就要導入, 但是卻希望上課時間越短越好, 因為同事很忙, 專案很忙. 可以一旦你不知道要導入的東西是什麼, 以及背後運作的原理是什麼, 這樣就一定會失敗的. 另外, 導入新東西一定會有人不接受, 這時候適當的溝通是需要的, 有時候也許只是他們不知道為什麼要做, 或者做這件事情的好處是什麼, 如果一次溝通不行, 那就是再溝通幾次.
最後, 在 IEEE Software 上有篇文章[6], 介紹到導入大規模敏捷時, 會遭遇到的挑戰和建議的作法. 這邊調查包含了Scaled Agile Framework (SAFe), Large-Scale Scrum (LeSS), Spotify, Nexus, and Scrum@Scale 等案例, 大約十三家公司, 所綜合整理出了的資訊, 還蠻有其參考性的.
|
挑戰 |
建議 |
|
大家對於框架的定義和術語認知不同 |
|
|
沒有比較的標準或是憑感覺選擇 |
|
|
導入之前沒做好組織結構調整的準備以及沒有確認大家的意願 |
|
|
單一框架很難適用所有的組織結構 |
|
|
倒底是要上到下來推廣, 還是有下往上呢？ |
|
|
要完全照著框架方法來做, 還是有交付價值即可? |
|
|
如何證明框架有用? 尤其是某些特別的產業或問題 |
|
|
如何讓這麼多開發人員對於怎麼做有自主權 |
|
|
如果客戶或上下流使用不同的框架? |
|
參考文獻
[1] LeSS 三個導入原則
https://less.works/less/adoption/three-principles
[2] LeSS 建議的啟動流程
https://less.works/less/adoption/getting-started
[3] LeSS 官網的案例分享
https://less.works/case-studies/short-case-studies
[4] An Approach for Large-Scale Agile Adoption Challenges, Erez Morabia
[5] Investigating the Adoption and Application of Large-Scale Scrum at a German Automobile Manufacturer, O¨mer Uludag˘*, Martin Kleehaus*, Niklas Dreymann*, Christian Kabelin†, Florian Matthes*
[6] Implementing Large-Scale Agile Frameworks: Challenges and Recommendations, IEEE Software, March 2019
留言列表
