團隊對於大規模開發來說, 是關鍵核心的單元. 組織的結構設計, 會對團隊的效率有極大的影響.
我想在網路上, 應該很多人都看過下面這張圖, 一個公司的組織結構可以看得出他們的文化. 像是Amazon呈現嚴謹的金字塔型架構；Microsoft則是各部門互相敵視對著幹；Apple是 Jobs一個人說了算。因此, 如果你想要有快速反應的文化, 在組織架構上就要能有這樣的彈性.

圖片來源: Microsoft Overhauls, the Apple Way, July 11, 2013
http://www.nytimes.com/2013/07/12/technology/microsoft-revamps-structure-and-management.html

LeSS 的發明人 Craig, 他就提出一個相當有名的 Laws of Organizational Behavior, 也是提到在大型組織中, 文化跟隨於組織結構.

(1). 組織在暗中被優化過, 目的是要避免改變到中高階管理者以及單一專業之專家的職位與權力結構現狀
(2). 根據 (1) 的推論, 任何改革的初步行動都會被消減, 並對新術語重新定義或穿鑿附會, 使他們與當前現狀基本上一樣
(3). 根據 (1) 的推論, 任何改革的初步行動都會被嘲弄為”純粹主義”, ”理論派”, “革命性的”, “宗教狂熱”, “只是為了局部考量而搞成的務實性客製化”. 這樣抹黑後, 就可以使它偏離方向, 以免問題直接指向組織的虛弱體質, 管理者, 或專家的現狀
(4).根據 (1) 的推論, 如果經理或專家最終被取代, 他們將變成變革的 教練或培訓師, 時常來強調 (2) 和 (3)
(5) 在大型組織中, 文化跟隨於組織結構. 在小型或是年輕的組織, 結構跟隨於文化
資料來源: https://www.craiglarman.com/wiki/index.php?title=Larman%27s_Laws_of_Organizational_Behavior

因此, 在導入LeSS 時, 最重要的一件事情就是要建立合適 LeSS 的組織結構, 才能發揮最大的效果. 這裡最基本最重要的就是團隊的定義. 在 LeSS 中團隊應該有以下特性

(1) 共同擁有權: 團隊成員共同擁有產品, 產出物和責任.
(2) 跨職能: 要完成此產品所需職能的人都需要加入此團隊
(3) 自組織: 團隊成員自己決定要如何完成產品和如何交付
(4) 長期存在: 團隊會有較長的時間待在一起, 不會臨時組成或很快解散

而落實這樣團隊觀念的作法就是 Feature Team. 它是一個長期存在, 跨職能的團隊, 他們可以處理許多端到端用戶的功能. 這個作法也是當初從微軟那邊學習和衍生過來, 所以是一個經過實戰, 已經被證實可行的作法.

圖片來源：https://less.works/less/structure/feature-teams

在落實 Feature Team 時, 很重要的一件事情, 就是要搭配工程實踐(Engineering Practices)：持續整合+自動化測試, 來確保產品品質. 因為, Feature Team 每個人都可以對代碼進行修改, 各團隊也會些改到相同的元件. 為了不會互相影響, 及早發現修改時的衝突, 這些實踐是要落實的. 這樣才能大家接受程式碼擁有權共享這件事.

下面這張圖就是一個典型的例子, 假設開發人員每次 Sprint都開發 10 個功能, 但是測試人員每次 Sprint時, 回歸測試要面對的功能是越來越多, 這時候如果你沒有持續整合+自動化測試來幫忙, 到最後不管是開發或是測試人員, 他們只會關心這個 Sprint 新開發的功能, 以前的功能不是放棄, 就是看時間剩多少加減檢測一下, 求個安心.

另外, 大家可能會誤解, 以為 Feature Team 的成員就要懂全部, 這個是錯誤的. 而是整個團隊合起來, 有製作這個功能所需要的技能. 而非要求你要全會. 但是還是有可能會遇到這個團隊不會, 或這是會的那個人很忙, 這時候LeSS會視這個是一個學習的機會, 可以讓大家成長的機會. 而不是只是說我不會, 或者是把它視為是一種約束.

當然這也不是說要放棄專業性, 我們還是需要重視專業性, 因為有些工作還是需要專業的來. 並且有些狀況, 我們也需要專業的人指導其他團隊成員. 但是LeSS 會希望你可以學習多點專業, 以及多點略懂略懂的東西. 像這樣的人才我們會稱為是梳型人, 你可以想想梳子的形狀, 他有很多根直直的腳, 就像下圖所示, 這些是你可能掌握的專業. 橫的柄的部分, 你可以想像成是其他略懂略懂的東西, 如果這些你可以了解多一點, 就可多點機會幫助其他人完成事情.

這邊所提到的專業, 一般來說會有技術的專業和客戶領域的專業. 傳統的思維可能會想加強技術的專業, 這樣開發會做得比較快? 但是 LeSS 的想法, 是比較傾向客戶領域的專業, 懂客戶的領域, 知道他們想要什麼, 會遇到什麼問題, 這樣開發出來的東西能符合他們需求的機會才比較大.
或許有些人會說要精通一個新的東西, 這是需要很多時間的. 他會說網路上不是說要 10000 個小時的刻意練習. 我想這可能是對的, 如果是你要精通一個東西. 但是很多時候, 你可能只要 60-70 分的了解, 很多事情就可以幫忙處理了. 那 60-70 的程度需要這麼多時間嗎? 答案是不太需求. 根據 Learning Curve Graph 的資訊, 如果只是想要達到60-70 分的水準, 所花的代價是比你想的少的許多.

圖片來源: https://www.valamis.com/hub/learning-curve

為了讓大家可以多學習一點, 前面在講LeSS 規則中提到, LeSS 製造了很多協作機會, 就是要讓大家可以相互學習. 這個也就是 Team 和 Group 的差別. 很多人都知道 Team 比 Group 多了共同的目標. 但是也是有 Group 他們是有共同的目標, 但是看起來不像是 Team. 主要是他們缺乏的互相協作的能力. 當事情發生時, Team是大家一起合作, 共同承擔責任. 像多團隊的 PBR 和 Planning 會議, 或是以 pair programming 來做事, 都是 LeSS 強調的協作方式.