敏捷從2001年被首次提出到現在已經歷經了17個年頭，作為一種新的思潮和軟體開發方法早已跨越了鴻溝（如圖1所示），並團結了大部分實用主義者，陸續掀起了不可逆的全行業敏捷精益轉型。

如果你的公司或者組織正在進行或者已經經歷了敏捷轉型，那麼作為組織變革者的你，一定在轉型初期，組建了類似於“變革委員會”（或者“敏捷工作組”、“敏捷小組”、“變革小組”、“敏捷組委會”等）的團隊。而在這個行業中應運而生的關鍵角色之一 —— 敏捷顧問/敏捷教練，入駐客戶現場以後，提的第一個建議很有可能也是成立這樣的團隊。

圖1 技術採納生命週期 - 跨越鴻溝 Geoffrey A.Moore《公司進化論》2006

其實這種型別的團隊有一個專業的名詞 —— ETC，全稱為Enterprise Transition Community（企業轉型社群）,是由 Mike Cohn首次提出，並在《SUCCEEDING WITH AGILE: SOFTWARE DEVELOPMENT USING SCRUM》中做了詳細的介紹。

ETC的成員不超過12個，他們來自於參與Scrum轉型的最高級別人員。

ETC的存在是為了營造一種文化、一個氛圍 —— 那些對企業成功飽含熱情的人嘗試做出改變，而這些人的成功又會使更多的人產生更大的熱情。ETC不是通過強行實施企業變革，而是通過指導實施變革的小組，為成功實施Scrum排除障礙，為變革創造活力與激情。

雖然ETC剛開始是Mike Cohn為Scrum設計的，但是在實際應用過程中早已不侷限在Scrum轉型了。同時，ETC也並不只是為企業級別所特有，也適用於更小的規模，比如說：一個BU，一個部門，或者一個產品團隊（通常人數規模在100人以上或者人數少但是跨部門）。雖然每個諮詢師或者每個組織有不同的稱呼，但是幾乎每個諮詢師或者變革組織都會在轉型前期成立這麼一個團隊，足見其重要性。為了統一語言，本文會使用ETC這個名稱做進一步的深入分析。

先來說說我在諮詢現場的做法。我一般會協同高層領導、組織變革者組建專門的改進跨職能團隊，比如一個研發組織，包含業務、開發、測試、運維等部門負責人，成立ETC，選擇改進的Product Owner和Scrum Master，人員控制在15人以內（有的組織非常大，波及人員範圍較廣，需要領導層酌情取捨）。

ETC按照Scrum方式運作，讓變革者在戰鬥中學會戰鬥。團隊有正式的啟動儀式，迭代週期為一個月（或者兩週，不建議更短，後續以一個月為例）。一個月一次改進計劃會議，通過改進Workshop制定改進措施，並梳理優先順序，責任到人，一週兩次站會跟蹤，每次半小時，針對改進項具體內容設定評審時間和形式，一個月一次回顧會議。

這是組織進行敏捷轉型過程中一個非常重要的改進落地機制，是組織的改進引擎。令人欣喜的是，這幾年下來，有很多客戶，在諮詢師撤場兩三年後還能夠繼續按照當初的機制運作，“持續改進”已經植入了組織的DNA，始終有這麼一支隊伍持續不斷地率領組織時刻反思勇往直前。

但是，更多的是運作不好的ETC。尤其是ETC運作初期變革者缺乏經驗，非常容易陷入困境，接下來我們就深入瞭解一下ETC的六個陷阱和應對措施。

陷阱1：沒有共同的目標，ETC名不副實

ETC的成員往往都是參與敏捷轉型過程中的最高級別人員，是一個管理團隊。而管理團隊往往會有屁股思維；以研發場景為例，可能會有開發部門領導、測試部門領導，還有產品領導，專案經理等。

因為人員角色多，大家關注的內容就各有側重，ETC的計劃會、站會或者回顧會中如果偏向於部門或者專案，那麼另外的人可能參與感就不是很強。更重要的是，分散的目標很有可能會造成互相推諉抱怨，效率低，改進不明顯。

作為ETC的發起人或者變革者，第一個要解決的就是ETC成員目標不一致的問題，就像造船分配任務之前要喚起團隊內心對廣闊無限海洋的渴望一樣，我們需要找到核心問題，讓ETC成員意識到問題的嚴重性，樹立緊迫感，渴望改變現狀，然後引導大家共同制定改進目標。

這只是第一步，變革者需要不斷的與ETC成員溝通問題和變革願景，適當時候對目標升維或者降維，甚至通過求同存異的方式讓大家達成共識。

陷阱2：知易行難，ETC成員沒有以身作則導致轉型也就是一陣風

有一次，開家長會的時候，幼兒園的老師讓家長跟著做動作，老師一邊把手放在眼睛上，一遍嘴裡喊著“請把手放在下巴上”。很多家長不知所云，最後大部分家長都會比較糾結地把手從下巴轉移到眼睛上，又有點猶豫，最終還是效仿老師把手放在了眼睛上。

這是一個很好的“知行合一”的小遊戲，我們的孩子是這樣，我們的團隊也一樣。他們並不會根據管理層說的調整自己的行為，而是根據管理層做的調整自己的行為。

變革過程中，有時候領導會覺得團隊改進進展緩慢，很多情況下與領導的風格大有關係，“一句話需求”或者“說一套做一套”都是最直接的罪魁禍首。

舉個簡單的例子，如果作為部門經理或者專案經理的你，希望在研發團隊運作中增加一個Story Kickoff的環節，就需要不願其煩地與團隊講Kickoff怎麼做，為什麼要加這個環節，能解決我們什麼問題，並且在實際運作過程中參與到具體的Kickoff活動並給予團隊指導；當團隊遇到問題的時候，幫助團隊一起解決問題，並且鼓勵團隊。如果你只是吩咐了一句：“大家做吧”，然後就靜待收割，99%的概率會失望。

再舉個例子，敏捷理念中非常重要的一條是：管理者轉身 —— 使用“使命式指揮”替代命令控制。一起參加培訓的時候，你對“使命式指揮”讚不絕口，非常認同，並啟發管理層全部要向“使命式指揮”看齊，但是培訓過後的日常管理中，對管理層又是直接命令來控制去，這個時候，大多幹部都會潛移默化地效仿並對他的團隊也使用命令控制，而不是“使命式指揮”。

這個陷阱的應對措施最簡單也最難：以身作則，知行合一，有的時候，有些根深蒂固的習慣非常難改，尤其是管理風格，但是要讓團隊知道你是意識到自己的問題並且在嘗試改正的。

如果我們要改變，首先需要定義出我們期望的行為是什麼，我們希望人與人之間有怎麼樣的行為方式，並教會員工這種方法。

陷阱3：事無鉅細，ETC成員淪為微管理現行犯

如果原有領導班子是命令控制性風格，這幾乎是ETC成員最容易犯的毛病之首，管理太細節，改進Backlog太細節。

三年前我就見過一個領導團隊，7、8個部長就一個“測試場地到底有20平方還是40平方，能不能放下測試儀器”的事情吵了起來，而這樣的領導者容易犯的第二個毛病就是：沒有了解清楚就給方案。

關注的內容太過於細節，但是領導往往掌握不了所有的細節，這樣的矛盾就會滋生出更多的矛盾，甚至造成給底層員工添亂的尷尬局面。

而ETC的一個重要職責是營造一種環境，在該環境中裡，可以逐漸形成不 同的改進社群，這些改進社群在追求改善企業產品建立過程中，自發地形成和解散。

Mike Cohn《SUCCEEDING WITH AGILE: SOFTWARE DEVELOPMENT USING SCRUM》

ETC最大的目標是創造這麼一個環境，讓改進社群確認自己的目標，並自發地組織起來達成目標。

現在你是否發現，進入ETC其實並不意味著我們自己要做很多很多的任務，比ETC實際要完成的這些工作更重要的是，傳遞我們的轉型願景並激發別人的興趣。

陷阱4：將信將疑，ETC成員期待他山之石可以攻玉

例如，作為事業群的最高領導者及ETC的PO，其實對整個轉型過程呈觀望狀態，由於其他事業群的壓力所迫，不得不跟風；雖然敏捷運作開始了，但是更多是謹慎前行，你希望團隊要告訴你敏捷到底行不行。

這種場景，幾乎都有一個同樣的結局：失敗。

經歷過這種轉型的諮詢師或者變革者都會深有感觸不堪回首。我在諮詢現場，對領導層提的第一個要求就是：樂觀並且堅定。管理層的樂觀和堅定非常重要，強調多少遍都不為過。

因為，如果管理層將信將疑，團隊會從各種互動中感覺到管理層的質疑，繼而團隊就會質疑，覺得轉型沒用，然後又會反過來影響管理層對轉型的信心並加劇管理層的質疑，迴圈往復。最終以失敗告終。

這裡必須要提一下“文化變革的新舊途徑”，約翰·舒克是豐田城的首位美籍員工，在經歷了NUMMI公司的成功精益轉型之後，他對沙因的文化變革模型進行了修改，他認為：

要改變文化，首先要去改變的不是人們的思考方式，而是行動方式，即他們怎麼做事。

2015年，在沙因和約翰的模型基礎上，為了讓變革者能夠更容易操作，我提出瞭如下觀點： 對於管理層，我們要通過改變他們的思想改變他們的行為； 對於基層員工，我們要通過改變他們的行為來改變他們的思想。

隨後的幾年諮詢生涯中，又經歷了許多案例，何嘗不明白“二分法”是最危險的思想，不管對於哪個群體，讓其發生改變其實都需要思想和行為的相互佐證。但是，在大多數情況下，這樣看似粗暴的劃分其實並無大礙。尤其對於管理者而言，思維改變是前期最重要的一環，從古至今的無數變革案例幾乎都昭示了一個不爭的事實：領導者沒有下定決心痛定思痛，變革的路就走不長遠。

圖2 文化變革的新舊途徑

陷阱5：缺乏與基層團隊的多渠道連線，ETC更像空中樓閣難以為繼

就像陷阱3中提到的，ETC成員靠自己只能完成一點任務，取得一點成果，他們更需要依靠組織中的其他人完成實踐落地而走向敏捷所需要的大部分工作。因此ETC如何發動群眾，輻射群眾，與更廣大的團隊形成一對多的繼承和相互促進的關係就顯得尤為重要。

改進社群、各角色技能CoP（Community of Practice，實踐社群）都是不錯的選擇。切忌管理層在ETC各種指點江山發號指令，而忘記了團隊疾苦，很多改進措施難以落地，團隊叫苦連天，時間長了，不僅僅是變革像空中樓閣難以為繼，更有甚者倒退回比之前都不如的境地。

場景一：某企業某事業部正在進行從上至下的敏捷轉型，作為部門A的基層員工，根本不知道為什麼要轉型，每天的事情已經夠多了，為什麼還要多出這麼多敏捷轉型的討論和會議？

場景二：經由一些天的頭腦風暴和深思熟慮，在大領導的帶領下，大家終於下定決心要對現狀的短瀑布流程進行徹底變革，用敏捷核心實踐來改善目前的產品質量。大家成立了ETC，並建立了改進Backlog，開始跟蹤各種事項。作為中層管理幹部，你很幸運參與了整個過程。不過你的團隊經常對你飈出的一些新詞以及那片花花綠綠的改進牆充滿了疑惑和好奇，最開始你還解釋一下，慢慢的時間長了，你也懶得一遍遍解釋，他們也就熟視無睹了。

不管是Mike Cohn提到的ADAPT模型（如圖3所示）還是Kotter教授在《 LEADING CHANGE》中提到的變革八部曲（如圖4所示），都著重強調了一個“真理”：

每一個成功實施變革的組織都是在多個層次上進行這些活動

這個問題是：大部分變革專案都是由許多小專案組成的，這些小專案同樣也需要經過從緊迫感到融入文化這8個步驟（如圖4所示），缺一不可。而這是很多變革者最容易忽視的問題之一，他們往往蓄了足夠的勢，在最高層級用各種手段打開了突破口，找到了同盟軍，讓關鍵者動起來了，然而忘記了在下一個層級持續蓄勢，或者忘記了教會他們的ETC用同樣的方法鼓動底層員工跟著動起來，這也是敏捷轉型非常容易失敗的一個最關鍵的因素。

而另一問題是：整個變革專案行至中途，一些小專案完成了，而有的小專案才剛剛開始。不同專案不同團隊的狀況不一樣，需要我們分別對待。

針對這兩個問題核心應對措施就是：變革者要不斷識別團隊或專案處在變革過程中的哪個步驟，在多個層次和層級上反覆進行變革措施，並培養更多的變革者，在不同的範圍內和層次間不厭其煩地重複變革步驟。

圖3 ADAPT模型 Mike Coh

圖4 John Kotter’s Change Model-8 Steps 來源：staff.napier.ac.uk

陷阱6：忽視推廣和傳遞，最終臣服於企業重力

最近幾年，越來越多的企業管理者終於明白，敏捷轉型是在不同的層級上進行的，敏捷變革所取得的成效也與其所能夠影響的範圍有直接的關聯。就像上述陷阱5所講，如果在IT組織內部不能夠持續影響並顧及到多層級效應，就很難做出大的改變取得可觀的效果，轉型很有可能半路夭折。如果前五個陷阱完美應對過來了，基本可以說轉型成功了一半。

為什麼是成功了一半呢？其實對於進行敏捷轉型的企業組織，只要踏過前五個陷阱，都能夠取得不錯的成績，但是還差最後一關，那就是突破IT，向組織內更大範圍推廣和傳播。

“企業重力”是一個很有意思的說法，不同的書籍均有提到相似的概念。這也是沙因對企業文化的解讀：

文化 —— 是一個群體在解決外部適應和內容整合的問題時所學到的一套被普遍認可和不言而喻的假設。這些假設在過去運作得足夠好，被視為有效的，因而被作為理解、思考和感知這類問題的正確方式傳授給這個群體的新成員。 —沙因 《企業文化生存指南》

曾經讓這個群體成功的那些思考、感受和看待這個世界的方式就是企業重力，因此敏捷轉型的影響必須推得足夠遠足夠廣，才不至於使整個轉型因為“企業重力”而被拉回到原點。

最經典的例子就是IT部門內部的敏捷轉型，如果不連同業務部門，甚至HR、財務、物業等部門，用不了一兩年，就會發現改進乏力，這也是《精益企業》中所提倡的，我們要在更大的組織和範圍內進行徹底全方位的精益轉型，才能讓我們在不確定的市場環境中更具有適應性。

也有很多敏捷顧問/敏捷教練或者企業轉型者認為只要ETC旗幟一樹，正常運作起來，就成功了大半，殊不知這才是剛剛開始，組織轉型本身就是九死一生的博弈，Kotter教授也在《LEADING CHANGE》中一開篇就介紹了導致組織轉型失敗的8種常見錯誤。

而本文用敏捷轉型過程中的ETC作為引子幫大家鑑別領導班子的風格會嚴重影響組織轉型的進展，希望正在做組織轉型的你能夠在面對ETC團隊的各種問題見招拆招。

文/ThoughtWorks劉玉青 更多精彩洞見，請關注微信公眾號：思特沃克