LeSS 原則 (Principles) 是經過了一堆實驗, 從中學習演進而來的. 然後他們在花了幾年的時間, 從這些經驗中萃取出這些原則出來. 就讓我們一一來解釋這些原則吧.

圖片來源: https://less.works/less/framework/introduction#LeSSPrinciples

(1) Large-Scale Scrum is Scrum

LeSS 不是一個新的 Scrum, 他是告訴你在大規模的狀況下, 多團隊如何使用 Scrum 來協作開發. 所以 LeSS 就是 Scrum. 它只告訴你最基本的規則, 其他怎麼做就會根據你的狀況, 自己不斷實驗來演進.

所以 LeSS 不是一個疊床架屋的框架, 不是在上面堆積了很多流程, 增加了很多角色, 讓整個看起來很肥胖. 有些大規模敏捷框架看起來包山包海很完整, 讓你誤以為只要照著做就好, 但是事實上前人就說過：沒有銀製子彈. 這是 LeSS 和他們的差異之一.

(2) Transparency

Scrum 的發明人, Ken Schwaber 說到, Scrum 就像是你的岳母, 總是指出你做不好的地方 (Scrum is like your mother-in-law, it points out ALL your faults). LeSS 和 Scrum 一樣都可以顯示團隊的弱點. 只是 Scrum 顯示的大多是團隊內的問題, LeSS 會讓你看到組織上的問題. 組織設計的問題大多是結構, 流程, 獎勵, 人員等方面. 雖然 LeSS 是一個曝露問題的框架, 讓你可以看到水底中的淤泥. 但是困難的部分是清除, 因為這會涉及到組織政策和結構, 需要高層主管的大力支持.

(3) Empirical Process Control

就如同 Scrum 一樣, LeSS 也是一個經驗為主的流程控制. 因為對於複雜的問題或產品, 本來就很難在一開始就知道要怎麼做, 或是做什麼是對的. 如下圖所示, 預測為主的流程控制, 一開始就認為事情就是這樣, 我一下就能規劃出 A 怎麼到 B. 但是在經驗為主的流程控制, 他不確定如何一定可以到終點, 它只能先到 Q, 再看看下一步要怎麼辦, 決定後再到 R, 之後再討論下一步要怎麼辦, 反覆這樣的流程, 直到走到終點為止.

圖片來源：https://worldofagile.com/blog/empirical-process-control/

因此, LeSS 的設計就是產生足夠的流程, 接下來就是透過實驗和透明性, 來看看做得如何, 然後反思與調適. 因此, 不完整是 LeSS 的精心設計. 讓團隊和上下文來主導.

(4) 以少換多 (More with LeSS)

有時候人多不一定是好辦事. 就像俗話說: 三個和尚沒水喝. 因為人多以後, 就容易分彼此, 就容易推卸責任. 尤其在大企業中, 常常會有很多專職的角色, 負責某項任務. 因此大家就會根深蒂固認為, 這些任務一定要他們才能做, 別人是不該去做. 即使這個工作很簡單, 或者這件事情很緊急, 也要等到這些專門的角色出現去處理. 這樣效率怎麼會好得起來. 所以 LeSS 在設計時, 就會盡量減少角色的數目, 這會有助於團隊自組織, 讓組織比較單純, 也比較靈活去應對.

這過程中 LeSS 希望可以使用較少的文件, 或者較精細繁雜的工具. 讓我們可以專注於客戶的需求, 以及更緊密跟客戶協作. 因為有太多文件, 你的時間很多就會花在寫文件上面, 或者是你沒有這份文件你就會說無法做事. 此外, 有些工具很繁雜, 造成你要花不少時間去設定和維護. 這些都會減少你花時間在客戶和產品身上.

另外, 鉅細彌遺的標準作業流程(SOP), 也導致成員依賴流程上的規範, 自己比較不會去動腦, 遇到 SOP 上沒有描述的狀況可能就會不知道要怎麼變通. 會讓團隊成員在等答案, 或者就只會照規矩行事.

(5) Whole Product Focus

傳統組織都是以某項技術或領域分類, 這樣的作法就是之前提到的泰勒科學管理理論, 因為這樣的分工, 大家只會專注自己的技術或是熟悉的部分, 這樣會造成穀倉現象.

LeSS 希望我們不該只關注自己, 而是要關注產品整體. 例如：

a. 完成是指整體可運作才叫做完, 不是某個元件, 或是前後端做完.
b. 單一產品待辦列表, 不看個別元件或是某團隊自己擅長的
c. Sprint Review 是所有團隊一起舉行, 而非分開舉行
d. Sprint Planning 在第一部分時, 是所有團隊或團隊代表一起參加, 共同決定要做什麼
e. 單一的產品負責人, 避免多頭馬車

(6) Customer Centric

傳統的分工造成大家只熟悉一部分, 但是客戶是誰, 他們會怎麼用我們的產品, 我們往往不知道. 所以當客戶有問題來的時間, 我們往往無法處理, 或是不知道怎麼處理. LeSS 他希望我們是以客戶為中心, 而非以我們方便為原則. 因此它的很多設計都是往這個方向去思考. 以下是一些常見的作法：

a. Feature Team：不是一架構或技術分組, 而是讓團隊可以處理大多數客戶的功能
b. 單一個產品待辦列表：不管你是哪個技術或是元件的功能, 我們都是合在一起, 以客戶的價值來考量優先級
c. 團隊直接和客戶對話：產品負責人會幫團隊和客戶連結在一起, 讓他們直接對話, 而非是傳話.
d. 對客戶展示增量：在 Sprint Review 中的展示, 不該只是對內部成員展示, 應該要邀請真實用戶參與. 並且以互動方式進行, 讓他們可以真實體驗.