正在“部署敏捷”的你是不是“真敏捷”？

Doug+Dockery

事實上，“部署敏捷”與“變敏捷”完全是兩回事，僅僅部署敏捷并沒有多少實際價值。

時至今天，相信大家都已經聽說過“敏捷”這個詞。許多公司甚至很可能已有專門的敏捷團隊。大多數軟件驅動的公司希望通過從事敏捷（doing agile）開發來協助解決重大的業務和組織結構問題：諸如各種未兌現的承諾、不盡如人意的質量、缺乏可視性、成本過高、協作性差，以及創新進度緩慢等等。但很可惜，有許多公司發現他們并沒有從敏捷投資中得到預期的結果。

事實上，“部署敏捷”與“變敏捷”完全是兩回事。坦白來講，僅僅部署敏捷并沒有多少實際價值。

這并非敏捷團隊的錯。公司戰略與執行不一致，導致團隊成果與預期南轅北轍是見慣不怪的事情。這些公司一般在組織架構中存在巨大的“脫節”。那些知道如何彌補這一脫節的公司可以確保正確的投資，并以正確的方式組建。但更重要的是，他們可以定期以較低成本改變正在創建的產品，以緊跟市場需求，在開發過程中創造最大價值。這是在規模上實現打造真正的敏捷企業的保證，但要如何實現呢？

對Scrum的迷惘

在提供企業咨詢時，我通常會提出以下三個問題：你的團隊結構怎樣？團隊的工作流程怎樣？你會怎樣計劃？ 典型答案都會關注團隊數量、角色、技術、流程、估算故事價值、sprints長度等等。我們總能改善團隊層面的行為準則，但那又如何？每家公司都可以有Scrum團隊，但絕對不可以迷信Scrum框架會解決公司所面臨的重大問題。事實上，如果你所做的一切只是依賴這些單獨的Scrum團隊，其結果可能比瀑布開發模式更糟糕。

讓我們潛心思考一下。如果你的敏捷團隊的成員認為用瀑布開發模式更好，其中可能的原因就是：在瀑布模式中，當我們對工作所知甚少時，我們會預先作出決策。經驗告訴我們項目將會推遲且超出預算，但我們會知道構建的內容，因為范圍是固定的。與之相比，被稱為“自然法則下的Scrum”（Feral Scrum） 的優化團隊能夠快速交付軟件，而他們則只在Scrum模式下埋頭做著自己的工作。有時，他們與組織的唯一聯系就是唯一一個跟其他模式共享的產品負責人。他們投入許多資源進行開發，但我們不知道他們要交付的產品是否就是我們目前真正所需要的。

敏捷的首要問題

我們先不談出色的團隊執行未能解決我們的業務問題，讓我們來看一下如何計劃工作和安排人員。這時候，我們就要談到項目章程、業務案例、資金和資源審批。我們會討論他們計劃的頻率、參與人員以及需要花費的時間和精力。

一位客戶曾告訴我他們的年度計劃批準了商業智能團隊的71個項目，并且該71個項目目前全部仍處于活躍狀態，“因為管理者需要看到整個系統進展”。其中有一半的項目是從上一年度順延下來的。更致命的是，他們預期今年內不會有一個項目能夠完工。

通過實施看板方案，我們能夠解決這個進行中的工作問題。按照對業務的價值劃分項目優先等級，列出項目必須完成的步驟，以及限制“正在進行中”的工作量。只有在當前的工作完成后，團隊才能接新的工作。一轉眼，項目交付變成可預測了，我們只構建最具有業務價值的部分。我們已經解決了我們的問題，對嗎？答案當然是否定的。

培養企業的敏捷文化

市場每天千變萬化，新的客戶需求層出不窮。一家公司的生存有賴于能夠定期、以較低的成本改變項目組合，以緊追新的業務變化。想要縮短企業選擇最佳方案的時間，并不斷交付予客戶，我們就需要解決戰略與團隊工作之間的脫節問題。

答案就是如何細分舉措，讓團隊與不斷變化的優先重點保持一致、自動化進度報告和選擇能夠推動持續改善的指標。其中的核心就在于季度小組計劃活動Big Room Planning，它讓團隊和領導共同構建每個人可以交付的共享、可實現的發布計劃。由現在開始，每個團隊的工作與戰略變化將會保持一致，Scrum團隊可以“查看”以了解他們正在建模背后依據的基本原理，以及他們的工作如何推動公司戰略的實施。但是，我們還需要具備另外一個條件。

一個敏捷企業必須深諳只有將戰略、能力及文化結合起來，才能實現真正的機構轉變。文化產生于人們的互動方式，因此我們尋求能夠促進不斷學習和改進的互動，而回顧和良好的績效指標能派上用場。

最后，我們不應只是“做敏捷”，更應真正“變敏捷”（being Agile）。我們已具備所有解決重大問題所需的一切條件：包括出色的團隊執行、按價值劃分的優先等級、從戰略到執行的連接，以及滿足我們協調、溝通和改進文化需要的平臺。我們應專注于為客戶創優增值，而非只是創建過程。我們已經彌補組織中的缺口，現在我們可以積極引導我們的公司響應市場變化，真正成為一個敏捷企業。