我討厭說說而已的敏捷
摘要：說了這麼多，總結一下解決辦法：有清晰的目標，不要太過關注產出，用路線圖代替里程碑，與可信任的產品團隊合作，發現獲得價值的最短路勁。基於這個定律，我們可以這麼想：管理層想要在頂端控制整個系統，而敏捷團隊想要向實際的用戶交付價值，如果想要結束這種對立局面，就要讓處於各個層面的人都有的選擇。
現在總有人說“ 敏捷 死了”，然後又說“我們是開玩笑的”。他們想表達的意思是，敏捷本身並沒有死，是我們的敏捷實踐方式出了問題。那麼怎麼做纔是對的？或許真正的敏捷只存在於理論之中？有時候我也會這麼說，但現在已經感到厭倦了。
網上有很多替敏捷辯解的觀點：“有問題的是瀑布式 scrum，而不是 《敏捷宣言》 中所宣揚的敏捷……”但 Bob Marshall 卻直言不諱地指出：“《敏捷宣言》已經是老黃曆了”。然後他說了一些令我信服的觀點，經過一番思考之後，我寫下了這篇文章。
知道《敏捷宣言》第一行寫的是什麼嗎？不知道吧？沒關係。它是這麼說的：“我們正在探索更好的 軟件開發 方法……”請注意，這裏說的是“軟件開發”，並沒有說“如何讓組織變得更精益”、“如何償還向敏捷轉型而欠下的債務”、“如何專注結果”、“如何修復老舊的預算系統”，或者其他任何可以增值的東西。
另外請注意，它說的是“我們正在探索……”，並沒有說“我們已經……”。從 2001 年發表《敏捷宣言》以來，我們就沒有學到什麼東西嗎？有是有，但大部分企業的狀態似乎仍然停留在 1987 年。
《敏捷宣言》自然有它的用意，但不會把你送到你想要去的地方。所以，繼續學習吧。我們的知識是有保質期的，而且這些保質期比我們認爲的要短得多。我們的同事（通常是領導）經常會說“沒時間學習”，可能是因爲他們對自己所知道的東西太過於自信了。所以，列一個書單吧。如果你還沒讀過這些書：“Sense & Respnd”、“Lean Enterprise”、“A Seat at the Table”和“Everyone Is a Change Agent”，那麼開始讀起來吧，讓你的領導也讀一讀。
你也可以看看這些大師的博客，比如 John Cutler、Melissa Perri、Bob Marshall、Allen Holub、Laura Klein、Erika Hall、Neil Killick，等等。他們的觀點會一樣嗎？或者會和我一樣嗎？不會。但他們都是聰明人，看他們的博客也會讓你變聰明。《Fast Company》雜誌說，企業 CEO 平均每年會讀 60 本書，那麼你的領導會讀幾本？爲什麼要讓他們讀書？因爲如果他們的知識不更新，總以舊眼光看待 scrum，那麼你也會被死死地禁錮在 80 年代或者 90 年代。
所以，我們要持續學習，不斷更新知識，不要把敏捷當成萬靈丹。可以這麼說：敏捷只爲整個系統提供局部優化。敏捷所做的只是把軟件開發團隊放在一個局部空間，並不會提升整個組織的敏捷性。Ken Schwaber 說，敏捷試圖“收拾 瀑布開發 留下的殘局”，但卻從未提供全盤可行的替代方案。畢竟實踐和理論之間是有差距的。當我們抱怨“AINO”（Agile In Name Only，名義上的敏捷）時，我們要先捫心自問。
我們要面對這樣的事實：實踐中的敏捷大部分都只是名義上的敏捷。這看起來好像是敏捷運動的錯，不是嗎？但不管怎樣，我們還有很多重要的東西需要學，比如精益用戶體驗（Lean UX）、精益企業（Lean Enterprise）、超預算（Beyond Budgeting）、約束理論（Theory of Constraints）、產量會計（Throughput Accounting）、設計思維（Design Thinking）、DevOps 和組織治療（Organizational Therapy），等等。
你可能會問，爲什麼精益用戶體驗會排在最前面？因爲精益用戶體驗強調的是結果。如果你不知道要做出怎樣的轉變，也就不知道該做些什麼。如果沒有明確的方向，你就無法變得“敏捷”。敏捷的核心就是要快速轉變。可能有人會說，“除了這個，還有自省和調整”。話是這麼說，但在實踐當中，我並沒有看到有人進行自省和調整。我只看到敏捷團隊不斷地從積壓待辦的任務列表裏領取任務，倒騰 Jira 和 Rally，就像搬磚工人一樣一塊一塊地往上砌牆。
敏捷通常會把缺乏垂直信任的核心問題隱藏起來。等敏捷教練離開之後，事情會變得更糟糕。管理層和開發團隊之間的溝通變成了雞同鴨講。開發團隊認爲管理層什麼都不懂，管理層則認爲應該把精力集中在任務範圍、截止日期和效率上，卻不曾想這些截止日期都是拍腦袋決定的，而預估時間什麼的其實是一種浪費。
那麼這兩者誰會贏？他們看問題的視角完全不同，但無奈的是，其中一方的績效評估是由另一方決定的。開發團隊就像是盲人摸象，他們可能摸到不同的部位，然後得出不同的結論。而管理層則是瞎了眼的大象踩在了人身上，他們得出了一致的結論：人是扁的。解決這個問題的唯一辦法是要認識到整個團隊是一個完整的系統，不要只是做局部優化，而且要把信任放在首位。
開發團隊不是工廠生產流水線上的工人，我們不是在生產什麼塑料餐具，我們生產的是軟件產品。我們不能用經營披薩店的方式來運營團隊。做披薩和開發軟件是不一樣的，做披薩用的是同樣的菜譜做出同樣的披薩，而開發軟件是一項具有創新性的活動，我們要自己設計菜譜。或者說開發軟件是一個發現的旅程，不僅僅是按部就班地交付東西那麼簡單。如果意識不到這一點，就會造成巨大的浪費：開發出來的功能沒有人用，開發團隊付出的努力得不到相應的結果。這暴露出了敏捷的另一個深層問題：把用戶當小白鼠，讓他們先把產品用起來，後續再加以改進。但面對糟糕的產品，用戶頭也不回地走了，後續的產品改進純粹就是在浪費資源，因爲用戶根本不買賬。
有人會說，敏捷其實也關注創新性的工作。如果你主要從事設計或創新性方面的工作，那麼請回答以下這些問題：在跟敏捷團隊合作的時候，他們是怎麼對待你的？他們認爲你會給他們帶來價值並幫助他們進行自省和調整嗎？或者他們有要你體現出你存在的價值嗎？Alan Cooper 說過，如果你被要求體現出存在的價值，那無異於是在告訴你：在這個系統裏，你是沒有價值的。請注意，他們要開發人員證明自己的價值，而不關心開發人員寫了多少可以帶來正向結果的代碼。換句話說，他們關注的仍然是人，而不是工作本身。他們仍然關注成本，而不是價值，所以有很多價值從指縫間悄悄溜走了。
如果下次還有人要你“證明自己的價值”，你可以問他們：延期交付的成本是怎樣的？怎麼評估這些成本？具體的目標是什麼？達成這些目標所對應的工作量佔了總工作量多大比例？如果他們回答不上來，你可以繼續問：如果有更好更快的辦法可以知道該做些什麼，而不是僅僅是機械式地交付代碼，他們願意學嗎？他們的工作流效率是怎樣的？他們在不必要的會議上浪費了多少時間？如果有一些做法可以在更短的時間內推動更好的決策，他們有興趣去學習嗎？
這是另外一種思維方式，一種元思考，一種戰略性思考。Austin Govella 說，敏捷和瀑布關心的是如何構建軟件產品。如果他們只是埋頭交付代碼，關注成本問題，他們就永遠都不會意識到他們只能獲得更多自己關注的東西（也就是成本）。他們變成了一個交付軟件功能的工廠，就像是在生產塑料餐具。但其實你可以有其他選擇，你可以做更有價值的事情，而有價值的事情需要去發現。當你發現了更多選擇，也就獲得了更多可以產生正向結果的途徑。想要達到怎樣的目標？有沒有找到三五種達成目標的方式？當只有一種選擇的時候，你沒得選擇；當有兩個選擇的時候，你陷入了兩難的境地；當有三個甚至更多的選擇的時候，你總能選擇其中一條路走到你想去的地方。
你有聽說過“必要多樣性定律”（Law of Requisite Variety）嗎？這個定律指出，在一個系統中，具有最多選項的組件將擁有系統的控制權。基於這個定律，我們可以這麼想：管理層想要在頂端控制整個系統，而敏捷團隊想要向實際的用戶交付價值，如果想要結束這種對立局面，就要讓處於各個層面的人都有的選擇。解決辦法不是在敏捷或者瀑布之間二選一，而是要將自上而下的瀑布策略和自下而上的經驗驅動策略相結合。
說了這麼多，總結一下解決辦法：有清晰的目標，不要太過關注產出，用路線圖代替里程碑，與可信任的產品團隊合作，發現獲得價值的最短路勁。
所以，這意味着敏捷要“死”了嗎？當然不是，我認爲敏捷還沒有死，我也不希望它死掉。敏捷運動的價值在於它可以幫助實現文中提到的一些想法。但需要注意的是，敏捷運動和敏捷實踐是兩碼事，敏捷實踐實際上比敏捷運動要早出現幾十年。
