原文地址：
https://medium.com/startup-patterns/why-enterprise-agile-teams-fail-4ae64f7852d6
翻譯君：敏傑小王子
上週，我站在一家市值 200 億美元的公司的會議室裏，推動了一個關於敏捷的研討會。出席會議的小組由這家大公司的一個產品線中的每個職能部門的董事和部門經理組成。從 UX、工程和產品管理的崗位中挑選出來的十幾位領導者組成了一支團隊，他們代表着約 150 人的產品線。作爲一個團隊，他們踏上了“敏捷”的旅程。
這不是我們平時認爲的企業轉型。他們的高層既沒有明確支持也沒有明確阻撓這次轉型，這家公司對敏捷的官方態度最準確的描述是“良性冷漠”。因此，這個團隊基本上只能靠自己來嘗試，無論最終結果是成功還是失敗。
我在那裏的唯一原因，是因爲到目前爲止敏捷旅程還不順利，我的任務是幫助他們找出癥結並解決它。好巧不巧，他們出現的問題與我在過去 5 年中遇到其他團隊的原因相同。爲簡單起見，以下都是直言不諱的事實陳述，但也並非都適用於您的情況。
不明確的願景
如果你在辦公室走廊攔住任何團隊成員，問他：“同學，我們產品的長期願景是什麼？”他們能否用一兩句話來回答？八成不行。他們可能對目標客戶有所瞭解，也可以明確地知道解決方案的功能。但是，他們真的可以說出客戶想要解決的痛點嗎？我猜不會。
一些高級管理人員在權利更迭期間，以臨別頓悟爲基礎傳達了自己的“突發奇想”。這個“想法”被投入了預算計劃角逐會議中，這位特別的高管最終贏得了影響力戰，並得到了 12 個月的項目資助。緊接着這一消息的所有內容通過一個既成事實的 PPT 傳遞給你，功能和時間表提前計劃好了，你被正式告知“請實現它”。現在你正試圖完成那個不可能完成的任務，並希望敏捷能幫到你。
解決方案：花一些時間闡明產品的清晰願景，使用業務模型或精簡圖片表達您的設想，邀請團隊中的每個人參與，將這些設想反饋給高層管理人員（如果他們拒絕參加），並確保你的相關信息出現在同一頁面上。
PS：如果他們找你麻煩，給我打個電話。
被混淆的業務指標
該團隊不會考慮日常的成本和收入。事實上，團隊可能不知道公司要讓他們賺多少錢，他們也不知道他們需要拓展多少客戶，每個時間段需要支付多少錢，以便他們在這個瘋狂的想法上實現收支平衡。他們基本上不太關心自己的工資來自何處。
但如果你問大多數初創公司，他們對自己整體燃燒率和銷售業績會有更好的瞭解，因爲收入和盈利能力對於他們來說始終是最重要的。
其實這個成本在任何情況下都不難計算。直線經理（Line Manager）通常可以在幾分鐘內得出工程團隊燃燒率的準確數字。然後當我們將這個數字（實際成本）與我們當前的銷售數據（我們作爲一個團隊實際產生的收入）進行比較時，這就會是一個全新的業務競賽。
譯者注：直線經理（Line Manager）是指諸如財務、生產、銷售等職能部門經理，每一個直線經理肩負着完成部門目標和對部門進行管理的職責。
解決方案：計算您的產品成功所需的團隊收入和成本，並確保每個人都知曉。它很有可能會讓人大開眼界。您應該在下一次業務規劃會議上與您的團隊一起嘗試。
持續不斷的干涉
由於方向上的某些緊急變化，您最後一次中斷正常工作流是什麼時候？它可以是最近的客戶投訴或請求，也可以是來自首席執行官措辭強烈的電子郵件——郵件涉及團隊在上週產品演示中使用的配色方案。
無論如何，如果你總是打破團隊的正常工作流，會給團隊帶來巨大的壓力。這種壓力轉化爲吞吐量降低、士氣低落、人員流動率增加、航運延誤、工藝粗劣、以及對團隊績效的普遍拖累。所以把這個壞習慣丟棄掉吧，您並沒有因爲在組織中的管理地位而擁有在事務優先級排序方案中的特權。
解決方案：每週爲計劃外工作分配一些容量，比如總容量的 20％，只安排 80％ 的團隊時間，而不計劃其餘的時間。可以在發生“緊急情況”時使用此容量，而不會影響原來的正常計劃。無人認領的話可以用它來償還技術債務。您可以輪換團隊成員來執行此操作。
不夠專注的團隊
我工作過的每個大公司都有這個問題。項目中的大多數人被分配到多個其他項目當中。當我問團隊中都有誰時，我得到的答案一般是某位工程師分配了 50％ 在這個項目上，而某位工程師與我們在一起的時間佔 20％，超過一半的項目人員將一半以上的時間花在其他項目上。難怪項目的最終結果往往是事故，因爲這種工作方式不管用。
產品開發是一項團隊活動，團隊成員之間需要極大的關注和大量的溝通和協調。您團隊中的每個人在部分時間內被分配到其他項目，這會使交付日期常常延遲數週或數月。
關於這一點我從企業管理者那裏得到了更多的案例，舉一個具體的例子，你也許會問：“我們真的需要在團隊中設置專門的產品體驗人員嗎？如果他們一半閒着怎麼辦？我們不是在浪費錢嗎？”
讓我們思考一下：
假設你有十個工程師和一個交互設計師（本來不應該是這個 1/10 的比例，但你可能會這樣做，所以我們姑且先這麼選着）。設計師爲工程師構建了 100 個線框，現在你有 10 名工程師開始工作，設計師又回到了其他項目。
工程師幾乎立即向設計師提出了要求，但設計師此時被其他項目束縛，所以工程師必須等待（延遲）。也許工程師選擇打開另一項任務並開始工作。當設計師重新上線時，工程師必須暫時放下第二個任務以重新打開第一個任務（延遲）。
現在，第二位工程師需要幫助，可能還有第三個工程師，他們都在等待（延遲）。設計師再次有空並開始與第一位工程師合作，而其他兩位排隊等候（延遲），後兩者的任務未完成（延遲）。所有三位工程師都失去了他們正在研究的一些事情的背景（延遲）。
在與第一位工程師合作時，設計師發現了設計中的錯誤，需要更新所有 100 個線框（大延遲）。現在，每個工程師都必須停止並重新檢查他們的工作以應對新設計（大延遲），已經完成的一些工作必須廢棄並重新開始（更大的延遲）。
所以你是選擇固執己見還是有所改變？您可以試試把上面的示例中替換成後端 API 開發人員，事情的結果會變得更糟。
解決方案：請組織小型、跨職能、專注的團隊，將一小組作爲一個單元一起工作，並不斷獲得雙方關於事務進展的反饋與澄清。
分散各地的團隊
大型企業團隊往往由一個地理位置分散的大型池的“資源”組成（原諒我用“資源”這個詞）。因此，企業產品團隊的成員處於不同的時區和地區，這使得溝通協調效率低下且成本昂貴，結果就會發生很多延遲等待和錯誤傳達。遠程通信的保真度絕對不如面對面溝通，視頻通話確實讓溝通變得更容易一些，但它與能夠一起走到白板前討論出來的東西並不相同。
解決方案：將所有團隊成員放在同一個房間，或至少在同一建築物的同一樓層。如果您必須與遠程人員一起工作，請根據康威定律分解任務，按地理劃分（具有明確定義的接口的模塊）而不是按功能劃分（設計、工程）。
太過臃腫的團隊
通常情況下，在企業中找到大型團隊來構建產品不是那麼複雜的事情。但由於各種原因，團隊規模常常大得驚人，這主要與高管傾向於通過指揮大羣人來建立自我的事實有關。
100 名工程師構建一個 SaaS 產品？你確定？較大的團隊效率更慢，因爲協調成本是巨大的。您需要更多層次的管理，更多會議和更多文檔。大型團隊對其速度的負面影響隨着其增長而漸漸變得更強烈。
解決方案：您應該使用儘可能小的團隊在企業中構建產品。如果你可以把它減少到幾十個，甚至一打，那就更好。
太重的技術債務
企業往往有很多舊的代碼庫。然而這並不是企業敏捷團隊積累技術債務的真正原因。我敢打賭，您當前項目中的大部分技術債務是從您當前項目開始以來由您的團隊創建的，而不是通過來自較舊的遺留系統的繼承。
這是因爲，儘管敏捷社區重複了 15 年：
（1）結對編程技術實踐的重要性
（2）測試驅動開發
（3）對代碼的持續集成
但非常少的企業團隊真正去做這些事情。出於各種原因（主要是因爲那些專注於流程而非卓越技術的大型諮詢公司向高管出售的所謂“敏捷”），企業敏捷團隊很少接受：核心技術實踐使得敏捷出色。結果大型的工程團隊開始設計和執行有缺陷的系統，然後在漫長而痛苦的發佈週期中相互折磨。
解決方案：考慮採用“極限編程”，使用敏捷的技術實踐。此外還要考慮使用敏捷構建的現代技術工具和語言。
太多的併發事務
擁有專門團隊的關鍵是一次只做一部分事情並且把它做得非常好。大多數企業團隊可能因爲他們的人員太多而傾向於同時處理數十種特性。
將迭代限制爲幾個關鍵功能會好很多。在看板語言中，我們稱之爲“在製品”（WIP）限制。實際上您可以通過強制許多人在相同的項目上一起工作來創建更加協作的環境。由於 WIP 限制，不允許任何人在未完成目前事務前開始新事務。它可以使事務一次做得越來越少，越來越好。減少返工和減少錯誤，會帶來更多團隊合作、更高的品質和更高的士氣。
方案：立即實施 WIP 限制。如果您有一個 10 人團隊，請將 WIP 限制設置爲 5 個項目，以便每個人都被迫與其他人結對工作。相信我，效果會讓你感到驚訝。
更長的部署軟件時間
大多數企業所處的遺留系統的問題是部署時間過長。企業通常由一個運維團隊負責將代碼引導到生產環境。這些人員經過培訓，需要確保代碼被批准在公司服務器上運行之前是安全，高效和可用的。
當你迫不及待讓凡人工程師將他們自己的代碼手動部署到生產中時，像亞馬遜這樣的公司已經迅速搶佔你的市場份額。您可能依然在權衡開放生產環境訪問權限的風險以及在市場中滅絕的風險，這是因爲您對競爭威脅的反應太慢。
解決方案：DevOps。任何工程師都應該能夠隨時啓動新的開發和測試基礎架構。軟件推送到生產環境應該通過一個自動化過程，並具備所有必要的測試和標準。
被忽視的企業其他成員
最後，在您的敏捷“實驗”中，對您和團隊來說非常重要的成員，那些不需要完成任何關鍵特性但是你不得不合作的團隊：採購、法律、營銷、人力資源等這些崗位人員。如果您必須及時與組織中這些非敏捷團隊進行協調，那麼您會很容易心累。需要有一種方式與團隊外的團隊合作，這種方式不會完全搞砸你的努力。
我們在敏捷社區中注意到，由高層管理者提供自上而下的命令，敏捷轉型往往並不會真正起作用。除非被僱傭的執行層人員對轉型十分興奮，否則敏捷轉型這事就不會被堅持下去。沒有執行支持，也不會自下而上。
解決方案：基本上您有三種策略可以處理轉型問題，需要同時完成所有操作：
- 在您的組織內進行持續影響力的活動，以贏得關鍵的高層支持者。我保證您的企業中還有其他高管和經理也在嘗試或考慮在某個範圍或規模上嘗試敏捷，去尋找他們並結成聯盟。畢竟，在大型人類社會中變化是如何發生的，在大公司也不例外。
- 找出你需要從非敏捷特性團隊得到的東西，並確保提前與這些團隊交談。告訴他們你正在做什麼，事情是如何運作的，最重要的是如何讓他們更容易地與你一起工作。
- 無情地削減你的依賴。這部分或多或少在你的控制之下。推動使用工具、基礎設施、營銷材料、法律語言等，您和您的團隊可以自己構建、借閱或購買。要做到這一點需要時間，所以你應該馬上開始行動。
敏捷，做得對的話，效果驚人
嘗試敏捷並不瘋狂，事實上，我認爲這是讓你的公司進入下一代所需的競爭鬥羅場的唯一途徑。另一種選擇是緩慢地或快速地倒在更小、更靈活的競爭對手石榴裙下。CODING 敏捷模塊助你輕鬆搞定敏捷轉型