敏捷宣言的原則中有提到『最佳的架構、需求與設計皆來自於能自我組織的團隊。』所以自我組織(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 則留言