敏捷宣言的原則中有提到『最佳的架構、需求與設計皆來自於能自我組織的團隊。』所以自我組織（Self-Organizing），或簡稱自組織，在敏捷開放中是個常被提到的關鍵字。
可惜 Scrum Guide上也沒有針對自組織定義，只好參考維基百科對自組織的解釋是：
自我組織，也稱自組織，是一系統內部組織化的過程，通常是一開放系統，在沒有外部來源引導或管理之下會自行增加其複雜性。 自組織是從最初的無序系統中各部分之間的局部相互作用，產生某種全局有序或協調的形式的一種過程。這種過程是自發產生的，它不由任何中介或系統內部或外部的子系統所主導或控制。
參考以上，在敏捷式管理中，我對自組織的解讀是：為了達到群體的目標（以服務或產品的形式提供顧客價值），由每個團隊內部或個人發動，所產生的協調和行動。
自組織不是有無、而是多寡的問題
其實現實中每個團隊多多少少都有自發產生的行動，所以自組織並不是一個 0 或 1 二選一的答案，如有自組織、或是沒有自組織。而是類似量的概念，如權限大的團隊，自然比權限小的團隊更能自組織。
而這個自組織的量要怎麼衡量呢？
Leading Teams 書中有提到權限矩陣，把權限和團隊的自我管理能力分成四種等級。
書中把權限區分成四種，每種權限不是交給團隊，就是由主管掌握：
- 執行 (Execute)：用體力或智力完成工作，包含決定如何完成工作
- 監督與管理工作流程 (Monitor & Manage) ：取得和分析工作進行的資料，發起糾正行動
- 設計團隊和安排組織支援 (Design)：構建工作項目，決定團隊人員組成，建立工作行為規範，確保團隊有完成工作所需的資源和協助
- 設定團隊方向 (Set Direction)：建立共通的目標和願景，讓種種的小工作都是因為達成這些而發生
隨著主管交給團隊的權限越大，團隊自組織的程度就越高，由低到高的階段分別是：
- 主管領導 (Manager-Led)：團隊執行，主管負責監督控制工作成果
- 自我管理 (Self-Managing)：團隊執行工作外，還要自行負責改善做事情的方法
- 自我設計 (Self-Designing)：團隊可以自行決定成員，決定自己要做那些工作
- 自我治理 (Self-Governing)：團隊可以自行設立目標
當然每個階段還可以往下細分，如一個團隊可能可以自行決定成員，但不能決定自己的工作事項，這就達到了部分的『自我設計』。
Scrum 到底要求什麼程度的自組織？
就 Scrum 定義來看，我認為開發團隊是要求在『自我管理』的程度，因為團隊不但自行決定如何工作，還定期自省 (Retrospective)改善目前的做法，包含了『執行』和『監督與管理』的權限。但團隊的工作還是由 Product Owner 排序，所以不包含自我設計。
如果把 Product Owner 算入團隊中，那整個團隊就會提升到『自我設計』的程度，因為擁有決定工作的權限。但不算完全的『自我設計』，除非團隊可以決定人員的組成和自行取得團隊外的資源。
自組織就是團隊隨心所欲？
子曰：『從心所欲，不踰矩。』矩就是取得的授權。
所以自組織當然不是想做什麼做什麼，團隊要校準共同目標，還有主管的授權到哪裡。
很常見爭議是團隊覺的管理層管太多：『既然 Scrum 是自組織，強調自我管理，那幹嘛還管我們？』
如果團隊要求的是『自我管理』這個階段的權限，決定如何執行（如要拿多少工作項目），要如何改善工作模式（如實施 Pairing Programming）。按照 Scrum 的定義，如果這個權限都不給團隊，就不要說我們在跑 Scrum 啦。沒有 Scrum 沒關係，還是可以說我們跑敏捷 XD。
同樣的，如果團隊要求的是『自我管理』外的權限，如要自行加程序員鼓勵師啊，決定要做支援小花航空罷工App，主管要管是應該的。這 Scrum 就沒辦法幫忙背書了，這時需要靠之前的表現、與主管的信任度來看看能不能商量增加權限。
權力越大、責任越大
反過來說，權限帶來的也包含責任，如果團隊擁有『監督與管理』的權限，但是沒有扛起相對應的責任（比如說，開了十次自省會議待改善事項都沒變），那權限被收回去也是可預見的結果吧。
所以自組織不是誰說了算，而是校準公司的共同目標（帶給顧客價值），靠主管和團隊雙方互相溝通、清楚了解：團隊有那些權限，所擔負責任的程度和限制是什麼。更重要的是，自組織不但讓團隊獲得權利，也需負起責任，只拿好處不負責任可稱不上自組織哦！
圖片來源：
“http://rudbol.dk/wp-content/uploads/2014/03/SSP_4193-1-2000×925.jpg”
Leading Teams: Setting the Stage for Great Performances
在〈自我管理就是我說了算？ – 談自組織的不同階段〉中有 2 則留言