《靈活宣言》釋出後，“靈活”被越來越多的小型開發團隊認可。與此同時，另一個問題也逐漸暴露了出來：以 Scrum 為首的靈活方法論對那些大規模的開發團隊并不友好。
基于此，業界開始探尋能夠達到多個團隊協作開發最佳效率的辦法。直至2005年，當時在諾基亞公司工作的 Bas Vodde（一位精益靈活教練）和 Craig Larman（一名組織設計顧問）對此産生了莫大的興趣，兩人一拍即合。憑借 Bas 對 Scrum 等靈活方法的應用，以及 Craig 對産品開發流程的熟悉程度，他們打造了一款适合于多團隊的規模化靈活架構——Large Scale Scrum（LeSS）。
對于如何大規模實踐 Scrum 這一問題，Bas 和 Craig 找到了完美的答案。
實際上，LeSS 架構就是将 Scrum 架構放大，并應用于多團隊管理層級中，是以，LeSS 保留了很多 Scrum 中的基本要素，例如：每日站會、産品待辦清單、Sprint 計劃會議、Sprint 評審會議、回顧會議等。但在 Scrum 架構的基礎上，LeSS 架構又延伸出比之更大的範圍。
對于多團隊來說，規則越少，實踐的門檻就會越低。是以，LeSS 架構是一個極簡架構，以真正的團隊作為基本建構塊來進行整個組織的架構。另外，在建立 LeSS 的過程中，Bas Vodde 和 Craig Larman 盡可能地減少定義的輸入，更多的是推動團隊憑自身經驗建立适合自己的流程。
LeSS 具體細化為兩種架構：一種是适用于8個小團隊進行開發，每組最多8人的“LeSS”；另一種是協調、管理多達上千人的團隊的“LeSS Huge”。不論是哪一種具體的架構，對團隊自身的要求都不會改變。
1. LeSS 團隊要求是自管理的
一個自管理的團隊，能夠幫助各團隊成員之間增強協同能力，提高團隊工作效率。這裡的一個大前提就是，各團隊有一個共同的願景和為之奮鬥的目标，讓每一位成員都有“主人翁”意識。
2. LeSS 團隊要求是跨職能的
Craig Larman 解釋，“與其引入一種方法，在這基礎上打各種更新檔的話，倒不如嘗試改變組織架構，建立一個跨職能的團隊。”跨職能的團隊具有很大的靈活性，能夠更快地響應不斷變化的需求，并能更好地處理團隊之間的協作問題。
3. LeSS 團隊要求是協同辦公的
多個團隊協作辦公，以更快地為客戶傳遞新的産品。無論如何，需要打破部門和團隊間的壁壘，通過不斷地學習、試錯來幫助各團隊、各成員之間快速适應。與此同時，與其他流程部門之間的溝通、交流也能夠為團隊增加新的可能。
4. LeSS 團隊要求是長期存在的
由于 LeSS 面向的是多個團隊，這就要求各團隊的組合不能随意變動。因為團隊的目标是長期的，是以通過将大目标分解為小目标，協調各個團隊步調一緻，才能實作項目的成功。如若各個團隊随意組合，那麼最初拟定的計劃則會被全盤打散。
總的來說，LeSS 團隊與小型靈活團隊的要求沒有太大的差别。但 LeSS 架構是如何做到，既能在團隊間保留足夠的靈活能力和擴充能力，又能有充足的時間來啟動整個流程的呢？LeSS 架構具體又應如何實踐呢？且聽下回分解。