根據官方網站的紀錄, 這是 2020 年 12 月更新版本的規則(Rule). 讓我們一起來看看.

A. LeSS 結構 (Structure)

(1) 用團隊作為基本模塊來構建組織
(2) 每個團隊是：a. 自管理的, b. 跨職能的, c. 同在一地, d. 長期存在的
(3) 多數團隊都是以客戶為中心的 feature團隊
(4) ScrumMaster負責LeSS的導入並確認運作順暢. 他們關注於團隊, 產品負責人, 組織和開發實踐。一個ScrumMaster不只關注單一團隊, 而是整個組織系統.
(5) ScrumMaster是一份專職和全職的角色
(6) 一個ScrumMaster可以服務1－3個團隊
(7) 在LeSS裡 管理者是非必要的. 但是如果管理者存在的話, 他們的工作內容可能會改變. 他們的焦點從每日產品的工作管理, 轉成如何改善產品開發系統的價值交付能力
(8) 管理者的角色是藉由實踐“實地查看 (Go See)”, 鼓勵停下來修正(Stop & Fix)，以及“試驗高於遵循 (experiments over conformance)”來改進產品開發
(9) 對於產品群組從一開始就建立完整的LeSS結構，這個對LeSS導入至關重要
(10) 對超越產品群組的更大組織，採用“實地查看”來演進地導入LeSS，從而創建一個以試驗和改進為常態的組織
來源: https://less.works/less/rules

在實施 LeSS 之前, 強調必須要先調整組織的結構. 這個Craig 的背景也有關係, 他擅長組織變革, 認為大型組織的文化追隨組織結構, 如果要組織可以自組織自管理, 一開始的設計就很重要. 這也是 LeSS 和其他規模化框架不同之處, 有些框架不強調要先做組織調整, 甚至還可能把原先所有角色都包含進來, 讓大家都有事做, 職位都保住.

另外, 和 Scrum 不一樣的地方, LeSS 強調 ScrumMaster 是一份專職和全職的角色, Scrum Guide 中並且說 ScrumMaster 要是這樣的. 個人覺得在大規模狀況下, ScrumMaster 要照顧的狀況更多, 沒有專職很難把事情給作法, 這樣的改變是需要的.

Don’t look with your eyes, look with your feet… people who only look at the numbers are the worst of all. ~ 大野耐一

LeSS 中是可以允許有管理者存在, 但是會強調他們需要 Go & See, 也就是實地查看, 這不只管理者要這樣, 團隊成員也是要這樣. 唯有實際看到工作現場的問題, 提出來的解法才會貼近真實狀況. 不該只是從會議, 文件報告或是電子郵件的資訊, 來決定怎麼做. 實地查看不是走動管理, 到處走走只能看到表面, 管理者需要和現場工作人員一起深度討論或是觀察, 這樣才會有效果. 所以實地查看是需要花時間的.

B. LeSS 產品 (Product)

(1) 對整個產品只有一個產品負責人(Product Owner)和一個產品待辦列表 (Product Backlog)
(2) 產品負責人不應該獨自處理產品待辦列表的梳理工作；藉由讓多個團隊直接和客戶／用戶以及關係人直接互動, 來進行梳理的工作
(3) 所有的優先級排序都通過產品負責人來決定，但是澄清盡量由團隊和客戶／用戶以及關係人來直接溝通進行
(4) 產品的定義應該是在實際的前提下, 盡量寬廣並且以終端用戶／客戶為導向。隨著時間的推移，產品的定義可能會擴大。我們傾向於更廣的定義
(5) 對整個產品有一個所有團隊一致的完成的定義 (Definition of Done)
(6) 每個團隊可以擴展共同的完成的定義, 以形成自己團隊更為嚴格的完成的定義
(7) 完美的目標是通過改進完成的定義, 以達到每個Sprint都產出可交付的產品（或者更為頻繁）
來源: https://less.works/less/rules

LeSS 中強調每個 LeSS 只有一個產品負責人 (Product Owner), 裡面只有一個產品待辦列表 (Product Backlog). 和 Scrum 不太一樣的地方, LeSS 在做產品待辦列表梳理時, 是讓團隊直接和客戶或關係人討論, 不見得全部都是他代替客戶來直接釐清, 讓團隊可以更瞭解客戶在想什麼, 客戶遇到什麼問題, 讓待辦列表內容更正確. Scrum Guide 中這些事情都是產品負責人在做, 雖然他可以委託他人來幫忙, 但是這個他人不見得是團隊的成員.

Scrum Guide 中雖然有提到完成的定義, 但是沒有具提說明他要被怎麼用. 在 LeSS 中完成的定義是用來持續改善的工具. 在後面我們會詳細說明如何來進行.

C. LeSS Sprint

(1) 有一個產品層面的Sprint，而不是每個團隊有不同的Sprint。每個團隊同時開始和結束一個Sprint。每個Sprint產出一個整合過的完整產品
(2) Sprint 規劃會議由兩部分組成：Sprint規劃會議第一部分是所有團隊共同來進行，而Sprint規劃會議第二部分通常由各團隊分別進行。對那些相關性強的條目, 會在一個共享空間內, 進行多團隊的Sprint規劃會議第二部分
(3) Sprint規劃會議第一部分由產品負責人, 團隊或團隊代表參加。他們一起試探性地選擇每個團隊將在下一個Sprint會進行的條目。團隊會識別出一起合作的機會，並澄清最終的問題
(4) 每個團隊有自己的Sprint待辦列表 (Sprint Backlog)
(5) Sprint規劃會議第二部分是讓團隊決定, 怎麼處理他們所選了的條目。這通常涉及設計, 並且建立他們的Sprint待辦列表
(6) 每個團隊有自己的每日站會
(7) 跨團隊協調由團隊決定要進行。傾向於分佈式和非正式協調, 而非集中式協調。強調實時交流(Just Talk)和非正式的網絡，利用代碼、跨團隊會議、組件導師(component mentors)、旅行者(travelers)、偵察員(scouts) 和開放空間會議(open spaces)等方式來溝通
(8) 產品待辦列表梳理會議會由多團隊協作來進行, 以增加共同的學習，並發現協調的機會
(9) 只有一個產品的Sprint Review 會議；這是所有團隊都是共享的。確保足夠的關係人能夠參加, 並貢獻有效檢驗和適應所需要的信息。
(10) 每個團隊有自己的Sprint回顧會議
(11) 在團隊各自的回顧之後舉行一個整體的回顧來討論跨團隊和系統性的問題，並創建改進試驗。這個會議由產品所有人、ScrumMaster們、團隊代表和管理者（如果有的話）來參加。
來源: https://less.works/less/rules

LeSS 中 Sprint 的運作方式和 Scrum 很接近, 基本上你懂 Scrum, 大致就可以了解. 差別的地方是會安排多團隊之間如何協作. 例如Sprint規劃會議, Sprint回顧會議, 和產品待辦列表梳理會議. 這裡也是和其他大規模敏捷框架不同之處. 別的框架不見得會說這是單一團隊或是多團隊要開, 也不會說多團隊要如何進行. 後面我們會詳細介紹 LeSS 如何進行.