基本上來說, 導入任何新東西, 都是一種變革管理. 重點都不在你想推廣的那項東西, 而是如何讓人們心裡願意接受, 會認為現在是有必要去做這樣的轉變. 在 LeSS 中認為導入有三個原則

(1) 深入集中 優於 淺薄廣泛

很多公司為了想要趕快看到成果, 或者是為了虛名, 因此一開始就希望全公司能夠一起使用. 但是一方面大家對於 LeSS 那時候還不太了解, 在不知道怎麼做的情況下, 這很容易影響恐慌, 進而導致大家反彈或是集體作假. 另一方面, 初期你能支援 LeSS 導入的支援也不夠, 有經驗的顧問和內部專家都是不足的, 你無法每個地方都顧到, 甚至連大部分都顧到都很難.

因此, LeSS 希望先在一組 LeSS 的產品團隊中, 把 LeSS 給採用好, 遇到問題好好解決, 該落實的實務 (practice) 有做好. 而不是很多產品團隊都開始用, 但是大多只用一點點, 並且沒有深入檢討改進.

(2) 由下而上 且 由上而下

有些時候第一線的員工, 他們最接近問題, 他們想要改變的意願是最強的, 因此很容易由底層發起要實施 LeSS. 但是導入 LeSS 需要組織調整, 並且在分工合作的方式也要做轉變, 因此會一瞬間就讓下面的人就卡關.

也有些時候上面的主管, 覺得目前工作流程不夠有效, 想要導入 LeSS 來改變. 雖然他有權利去做組織調整, 以及分工方式的改變. 但如果底下不配合, 或是沒有意願, 容易變成你說一動, 他們才開始去做, 這樣也無法真的有用.

所以最好的方式是由下而上且由上而下, 讓動機強的員工願意來做, 然後上層也願意積極配合和支持. 這樣才能讓導入的工作能長久和有效.

(3) 讓志願者來

強扭的瓜不甜, 因此在導入時, 通常需要詢問哪些團隊有意願, 讓那些團隊變成 pilot run的團隊, 這樣成功機率才能提升.

對於導入的流程, LeSS 有建議一個流程

(1) 教育所有人

很多公司說要導入一個東西, 就只是口頭上, 說公司現在要求要做哪個, 但是大家對他什麼都不知道, 這樣就開始了. LeSS 認為這樣是不可行的. 事前要先上課幾天的 Scrum 和 LeSS 訓練課程. 不過有點要注意的, 不要只是基層來上課, 高層或是第一線主管更是需要來參加, 因為如果你對一個東西都不懂, 你怎麼敢放心支持, 或是當有遇到問題時, 你也不知道要如何幫忙或是預防.

(2) 定義產品

有了相關知識後, 接下來就要跟相關的利害關係人討論, 例如產品主管, 技術組長, 管團隊的人, 思考適合導入 LeSS 做法的產品範圍. 怎樣切才能之後的 Scrum 團隊們, 大多能處理, 可以不會造成太複雜的相依性.

並且產品的功能對客戶來說是有意義的, 他們可以一看就知道是跟他日常要處理的事情有關. 不會是從開發端的角度來切割, 也就是不是從系統架構或是元件來插解.

定義產品的範圍, 對之後規劃 Scrum 團隊有著巨大的影響, 如果可以有有經驗的顧問一起討論, 可以降低導入的風險.

(3) 定義完成的定義

完成的定義可以幫助團隊逐漸改善, 並且也可以讓團隊擴大學習. 因此, 需要一開始就先定義好, 讓團隊知道對他們的要求是什麼, 讓他們在品質方面要注意.

(4) 建立適當的 Scrum 團隊

知道產品的範圍後, 接下來就需要根據這個範圍, 建立出合適的 Scrum 團隊. 一開始或許無法完全都是 feature team, 但是盡量朝此方向前進. 逼不得也許還是會有 component team 的形式出現. 但是要能透過擴大學習的做法, 讓團隊有機會略懂略懂, 日後要再調整 feature team 形式的 Scrum 團隊才有機會.

(5) 只有 Product Owner 可以提供工作給這些團隊

LeSS 中的 Scrum 團隊要做什麼事情, 應該都是要 product owner 來提供的, 並且排出優先順序. 就算有隕石發生, 這些隕石也不應該穿過 product owner, 直接降到 Scrum 團隊身上.

(6) 團隊裡沒有專案經理的角色

LeSS 認為團隊應該是要自組織的, 為了能讓這件事情能發生, LeSS 建議沒有專案經理的角色, 專案管理的工作由 Product Owner 和團隊成員來分擔, 因此不需要專案經理這個角色.

此外, 在導入初期, 因為內部對於 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 他今天又跟誰合照了.