最後我們來看 LeSS 團隊這個角色. 首先, 還是先看看 Scrum Guide 中怎麼說:

Scrum 以小團隊作為基本單位，稱為 Scrum Team。 Scrum Team 由一名 Scrum Master、一名 Product Owner 與 Developers 所組成。 …

Scrum Teams 是跨職能（cross-functional）的 …

如果 Scrum Teams 變得太大，他們應該考慮重新組織為多個有凝聚力的 Scrum Team，每個團隊還是專注在同一個產品，因此，他們應該有著相同的 Product Goal、Product Backlog 和 Product Owner。

Scrum Team 負責所有與產品相關的活動，像是與利害關係人（stakeholder）的協同合作、驗證、維護、營運、實驗、研究、和開發以及任何其他可能需要的工作。組織成立 Scrum Team 並授權他們自行管理工作。在 Sprint 中維持可持續的步調工作，可以加強 Scrum Team 的專注與一致性。

在 LeSS 的規則中, 和團隊相關的大約有以下這幾項:

用團隊作為基本模塊來構建組織
每個團隊是：a. 自管理的, b. 跨職能的, c. 同在一地, d. 長期存在的
多數團隊都是以客戶為中心的 feature團隊
每個團隊可以擴展共同的完成的定義, 以形成自己團隊更為嚴格的完成的定義

目前上述描述看來, 個人覺得兩者並沒有什麼差別. 因此, 如果團隊成員熟悉 Scrum 運作方式, 應該在 LeSS 中也沒有太多不適感. 不過, 我還是從幾個角度來加以說明:

自組織團隊

在 MIT 領導中心中, 彼得聖吉(第五項修煉的作者)和他的同事發現到, 在不確定時代下, 有 4 種領導力很重要

(1) 讓我們周遭的事情變得有意義
(2) 在組織內部和不同組織建立關係
(3) 創建未來的願景
(4) 創造新的協同工作方法

在自組織的團隊中 所有團隊成員都需要培養上述能力, 並且在各個面向上發揮領導力.

此外, 自組織這件事情, 不是領導跟團隊佈達後, 團隊自然就可以自組織了. 團隊成員一開始會很迷惑, 不知道哪些他們可以做, 哪些需要找人幫忙, 因此往往一開始反而效率下降. 因此需要組織來幫忙, 從命令控制的運作方式, 轉換到團隊自行決定如何做.

例如: ScrumMaster 要當個引導, 幫助團隊成員說出自己的想法, 並且能有效規劃出一些做法, 並且能反思哪些地方需要調整. 並且在工作流程上, 也要鼓勵他們是以協作方式來工作, 而不是只能等某個角色某些工作才能做事.

跨職能團隊

所謂跨職能團隊, 是指產出功能所需技能的人都在, 不是指每個人會所有事情. 因此, 為了交付價值, 他們必須要緊密協作, 必須要討論怎麼進行, 怎樣才能最有效率. 這些是要自組織的方式來進行, 除了你們沒有更懂, 管理要插手, 他要花時間去懂, 這會很沒有效率.

這樣不但工作比較有效率, 並且也沒有交接的問題. 以前瀑布式的方式, 會一棒接一棒, 傳話的過程難免資訊會失真, 導致很後面才發現原來不是那麼一回事.

此外, 這個過程中, 大家可以互相學習, 你可以看到不同專業的處理方式, 讓自己的視野被打開, 並且也可以趁機學習到產品不同部分的知識.

長期的團隊

人跟人的相處, 是需要時間才能培養默契, 才能知道如何相互配合. 根據Bruce Tuckman 的理論, 團隊形成會有四個階段：

Forming：團隊剛成立
Storming：團隊成員各種觀念形成, 彼此激烈碰撞和競爭
Norming：團隊形成規則, 價值觀, 方法和工具
Performing：運作如同一體, 工作高效完成, 不需要高層話太多時間管理

從下面這張圖中可以看出, 必須經歷過 forming, storming 階段後, 團隊的效能才能提升. 如果公司不斷因某些專案或計畫, 就成立新組織來處理, 會導致成員同時參加多個組織, 並且每個組織你都需要花時間去經歷 forming, storming, 可是往往不到 storming, 這個專案或計畫就結束了, 所以不但高效還沒出來, 又讓你的精力在忍耐 forming, storming 的消耗. 這不是好的作法.

圖片來源: https://www.softed.com/us/news/exploring-the-stages-of-team-development/

很多時候當一個團隊績效很好時, 老闆就會想說把團隊拆散, 讓這些績效不錯的員工, 分散到各個團隊去幫忙, 希望能夠讓整個公司都成長起來. 可惜的是通常這樣做了以後, 大多只是失去了一個績效很好的團隊, 但是無法容易讓大多團隊都受益, 畢竟你是想少數去影響多數, 這不是容易的事情.