爲何企業敏捷團隊會失敗

原文地址：
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。任何工程師都應該可以隨時啓動新的開發和測試基礎架構。軟件推送到生產環境應該經過一個自動化過程，並具有全部必要的測試和標準。

被忽視的企業其餘成員

最後，在您的敏捷「實驗」中，對您和團隊來講很是重要的成員，那些不須要完成任何關鍵特性可是你不得不合做的團隊：採購、法律、營銷、人力資源等這些崗位人員。若是您必須及時與組織中這些非敏捷團隊進行協調，那麼您會很容易心累。須要有一種方式與團隊外的團隊合做，這種方式不會徹底搞砸你的努力。

咱們在敏捷社區中注意到，由高層管理者提供自上而下的命令，敏捷轉型每每並不會真正起做用。除非被僱傭的執行層人員對轉型十分興奮，不然敏捷轉型這事就不會被堅持下去。沒有執行支持，也不會自下而上。

解決方案：基本上您有三種策略能夠處理轉型問題，須要同時完成全部操做：

• 在您的組織內進行持續影響力的活動，以贏得關鍵的高層支持者。我保證您的企業中還有其餘高管和經理也在嘗試或考慮在某個範圍或規模上嘗試敏捷，去尋找他們並結成聯盟。畢竟，在大型人類社會中變化是如何發生的，在大公司也不例外。
• 找出你須要從非敏捷特性團隊獲得的東西，並確保提早與這些團隊交談。告訴他們你正在作什麼，事情是如何運做的，最重要的是如何讓他們更容易地與你一塊兒工做。
• 無情地削減你的依賴。這部分或多或少在你的控制之下。推進使用工具、基礎設施、營銷材料、法律語言等，您和您的團隊能夠本身構建、借閱或購買。要作到這一點須要時間，因此你應該立刻開始行動。

敏捷，作得對的話，效果驚人

嘗試敏捷並不瘋狂，事實上，我認爲這是讓你的公司進入下一代所需的競爭鬥羅場的惟一途徑。另外一種選擇是緩慢地或快速地倒在更小、更靈活的競爭對手石榴裙下。