起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識敏捷試點團隊初見成效，卻為何離自組織卻越來越遠？
但凡談起敏捷團隊，我們總是會想到“自組織”這個概念。實施敏捷的團隊，產品交付質量與效率都有大幅提升，但這樣的團隊就一定是“自組織”化的團隊嗎？
敏捷試點團隊初見成效
先分享一個案例：某公司決定啟動新項目，并嘗試采用Scrum的流程來進行開發。
其中的Scrum Master職位由比較資深，且對敏捷開發有不錯認知的原項目經理擔任。
在推行了一段敏捷開發，經過幾個Sprint之后，試點團隊取得了初步的成功。產品交付效率和質量都有了大幅提升，團隊成員對敏捷也有了比較高的認可，該項目最終的交付產品達成了預期目標。
公司管理層及團隊成員都非常欣喜，有鑒于此，想要進一步擴大試點團隊的規模及覆蓋面，但是在該項目臨近尾聲的時候，卻也冒出了一些不太好的苗頭：
1. 每日站會，計劃會議，驗收會議，回顧會議等各種會議，如果Scrum Master不召集就不會召開。
一些團隊成員由于前一天加班較晚，結果第二天發生了晚到的情況，當天的站會因為人員不齊就不了了之了。
這其中最明顯的就是回顧會議，它已經變得越來越索然寡味，了無生趣，大家覺得各方面已經不錯，沒什么亟需迭代完善的。
隨著項目的持續推進和深入，回顧會議的價值卻在不斷被弱化，沒人覺得有何大礙，更沒人站出來指出隱患。
加之擔任Scrum Master的是項目經理，一旦他臨時參與一些其他重要會議，與此發生時間沖突的敏捷各項會議，因團隊內部無人張羅組織，自然也就不能按時召開。
2. 團隊經常受到緊急需求困擾，導致迭代計劃與交付難以展開。
很多時候，高管強行安排新需求，打斷團隊之前的開發節奏，經常能聽到領導說這樣的話：
這個新需求，已經答應客戶了，所以需要緊急處理，要求一周后交付，其他的先暫停一下。
團隊成員也從剛開始的抱怨，變成了習以為常，迭代計劃和交付拖期時有時無的在發生，大家也都覺得很正常，沒什么大驚小怪的，畢竟人家是高管，自己說再多也是白搭。
3. 團隊中開發與測試位于不同的樓層，平時溝通都是用社交聊天軟件，缺乏應有交流。
受制于社交聊天軟件，開發與測試的同事線下面對面溝通的機會較為缺乏，充其量就是在每日各項敏捷會議時有些互動，但畢竟時間有限，項目同步性或多或少已經受到一些影響。
以上這些不太好的苗頭，在很多敏捷團隊都屢有發生，但是因為對最終的產品交付尚未造成比較大的影響，也就沒人覺得要上綱上線，指責Scrum Master,或是團隊其他成員的不是了。
可是究竟是出了什么問題，才會導致出現這些隱患呢？
我們的團隊怎么了
乍一看，該公司的試點團隊在敏捷推行方面已經初具成效，可是為什么仍然會冒出那些看起來不好的苗頭？其癥結就在于：團隊的“自組織”出了問題，才造成雖然試點團隊取得了初步成功，卻離團隊“自組織”越來越遠。
為什么這么說呢？我們來看一篇堪稱敏捷思想鼻祖的文章《The New New Product Development Game 》中是如何定義“自組織”的呢？
一個群體具備三個條件時擁有自組織能力：自治、自我超越、正向交互。在我們對多個新產品開發團隊的研究中，都發現他們具備這三個條件。
而在案例中，領導直接命令，注重審核，是根據命令讓團隊執行的他組織下形成的習慣，這其實已經犯了團隊“自治”的大忌。
在《The New New Product Development Game》中寫到：
團隊自治要求總部的參與僅限于在開端提供指導、金錢和道德支持。在日常的基準上，高層管理者很少介入，團隊可以自由地設定自己的方向。
在某種程度上，高層管理者充當風險資本家?；蛘哒缫晃桓吖芩f：“我們打開錢包，但保持閉上嘴巴?！?/p>
案例中，團隊成員從起初的抱怨到習以為常，也是因為此前一直處于他組織的狀態下，接受指令，按部就班的執行，從而形成了固有的行為和思維習慣。
敏捷中的各種會議（儀式）都是團隊被動執行，為了向Scrum Master交代而執行的，團隊并沒有使用這些工具來不斷提升自己，也就是團隊成員”自我超越”出了問題。
在《The New New Product Development Game》中提及：
自我超越要求項目團隊表現出對“極限”永無止境探索的專注。從最高管理層提出的指導方針開始，他們開始建立自己的目標，并在整個開發過程中不斷提升它們。通過追求起初看起來相互矛盾的目標，他們設計出了顛覆現狀和重大發現的方案。
自組織，要求團隊成員每個人都要為負責，而不是“無為而治”全憑大家即時的想法。在執行“人人負責”的過程中，建立自己的目標，不斷提升自我，實現自我超越。所以當發現Scrum Master不在時，團隊成員每個人都應該去想如何去組織會議，而不是沒人組織那自己也無所謂。
這就像夫妻兩口子過日子，目標都是讓日子過得更好，雙方都要為此而建立自己的目標，也都要為此而負責，而不是遇到事情的時候，一看你不管，那我也不管，這日子肯定過不長遠。
敏捷團隊中的溝通出現問題，團隊沒有坐在一起形成不了團隊立場，團隊成員沒有彼此交談所以出現不了主動性，這其實是團隊“正向交互”出了問題。
在《The New New Product Development Game》中有載：
正向交互，要求一個項目團隊的成員包含不同的功能的專家、思考過程和行為模式執行新產品開發。
雖然選擇一個多樣化的團隊是至關重要的，但是直到成員開始交互，正向交互才真正發生。這個步驟遵循以下的基本原理：“當所有團隊成員都位于一個大房間時，甚至不需要努力某個人的信息就變成你的。然后，你開始思考什么是對團隊最好的或第二好，而不僅僅是站在你的立場。如果每個人都理解對方的立場，那么我們每個人都更愿意讓步，或者至少愿意嘗試彼此交談，也才能生發主動性?！?/p>
自治，自我超越，正向交互，作為自組織團隊必備的三大條件，并非孤立存在，而是兩兩之間存有微妙且有機的聯系。
建議
1. 讓高管保持“我們打開錢包，但保持閉上嘴巴”。
管理層的工作是給予團隊合適的任務，并幫他們移除障礙。也就是說對團隊限制和控制越少，結果就越好。
如果領導層過分約束團隊解決問題的方法，就不會有自組織團隊。團隊將停止思考，因為已經告訴他們太多的解決問題的細節。告訴他們如何做，接下來的部分他們也會等別人來告訴他們。
2. 給團隊一個好的目標，并激發他們。
最高管理層通過發出一個廣泛的目標或一個總體的戰略方向來啟動開發過程。它很少提出一個明確的新產品概念或具體的工作計劃。但它為項目團隊提供了廣泛的自由度，同時也建立了極具挑戰性的目標。
管理層與領導者通過激勵員工，并給他們挑戰，來提供支持自組織和演化的能量。這些挑戰創造了產品的當前狀態和預想狀態間的差距，或是創造了團隊當前績效和期望績效間的差距。當團隊受到激勵并接受挑戰時，他們會為了克服挑戰而自組織起來。
3. 確保團隊的溝通
盡最大的努力讓團隊坐到一起“當所有團隊成員都位于一個大房間時，甚至不需要努力某個人的信息就變成你的”。
如果團隊不在同一個辦公地點，那么你必須花費更多的金錢來創造團隊面對面溝通的機會（Mike Cohn曾在其著作《Scrum敏捷軟件開發》中提到聯絡訪問和旅行大使就是針對此問題提出的解決方案）
4. 給他們時間，他組織力突然消失之后，自組織力并不能很快成長起來。
這個過程需要時間。這種自組織力一開始是很孱弱的，但它是“時間的朋友”。這個循環運行的時間越久，自組織力越強。
但從反面來看，自組織力的形成有個時間的滯延。它不像他組織力那樣召之即來揮之即去，它要從無到能發揮作用得給足時間。
Mike Cohn博客：《Self-Organizing Teams Are Not Put Together Randomly》
原文地址：https://www.mountaingoatsoftware.com/blog/self-organizing-teams-are-not-put-together-randomly
編輯：坎叔
顧問：曉宇
本文由 @敏捷行動派 翻譯發布于人人都是產品經理。未經許可，禁止轉載
題圖來自Unsplash，基于CC0協議
關于敏捷需要團隊成員理解如下兩點：
1、工作的價值取決于交付給用戶的可使用價值【自我價值的衡量】
2、從科學和長遠的角度看，團隊單位時間的內的產出是固定，但是產出的價值受Product Owner決定的【PO的工作的重要點】
其次在執行敏捷的過程中要保證過程是透明的，每個Sprint該總結的還得總結，該舉辦的活動必定不可少，Scrum Master 可以展開一些有趣的活動。重點是可量化、透明、自主參與。