過去十年被奉為圭臬的 Scrum 敏捷開發框架，正在被大型科技公司拋棄，甚至從未被真正接納過；而隨之而來的，是 Scrum Master（敏捷大師）與 Agile Coach（敏捷教練）這類職位的「大出走」（The Great Exodus）。
想像一下，你和一群朋友要一起蓋一棟非常複雜的樂高城堡，這座城堡沒有完整的設計圖，你們只知道最終希望它看起來「宏偉壯觀且充滿奇幻色彩」。如果沒有任何方法，大家可能會七嘴八舌，東蓋一塊、西蓋一塊，有人想蓋尖塔，有人想蓋護城河，最後可能變成一團混亂，甚至永遠蓋不完。
Scrum 就像是為這個樂高團隊設計的一套「遊戲規則」。它說：「嘿，朋友們，我們不要想著一次把整個城堡蓋完。我們把時間切成一小段一小段，比如每兩個星期為一個『衝刺』（Sprint）。在這兩週開始前，我們開個會，從一大堆『想蓋的東西』（產品待辦清單）裡面，挑出幾個我們認為這兩週內可以完成的小目標，比如『蓋好城堡的大門和一段城牆』。然後，在這兩週內，我們每天早上花 15 分鐘碰個頭，叫做『每日站立會議』（Daily Standup），每個人都快速分享一下：我昨天完成了什麼？我今天打算做什麼？我遇到了什麼困難？這樣大家都能知道彼此的進度，也能及時互相幫助。兩週結束後，我們把自己蓋好的部分（大門和城牆）展示出來，看看成果如何，也聽聽大家的意見。然後，我們再開個『反思會議』，討論一下這兩週的合作有什麼可以改進的地方。接著，下一個為期兩週的『衝-刺』又開始了，我們再去挑新的目標來蓋。」
在這個過程中，還有一位特別的角色，叫做「Scrum Master」。他就像是這個樂高遊戲的「裁判兼主持人」。他不負責親手堆樂高，他的工作是確保大家都在遵守遊戲規則，比如會議不能開太久、幫助遇到困難的隊員掃除障礙（例如，樂高零件不夠了，他要去想辦法弄來），保護團隊不受外界干擾（例如，有其他朋友跑過來說：「嘿，我覺得你們應該先蓋一個噴水池！」Scrum Master 會去擋駕，告訴他請等我們這輪蓋完再說）。
聽起來很棒，對吧？它有固定的節奏、清晰的溝通管道、及時的反饋，確保團隊不會偏離軌道太遠，並且能夠持續地交付看得見的成果。這套方法在過去的軟體開發領域解決了一個巨大的痛點：傳統的開發模式就像是花一年時間埋頭畫完整張樂高城堡的設計圖，然後再花一年時間照圖施工，結果蓋出來發現，大家想要的早就不是這種風格了，浪費了大量的時間和資源。 Scrum 的出現，讓開發團隊變得更「敏捷」，能夠快速應對變化。
這就是為什麼在過去十幾年，整個科技行業，尤其是軟體業，都對 Scrum 趨之若鶩。公司花大錢讓員工去考取 Scrum Master 證照，成立了專門的「敏捷教練」團隊，把「兩週衝刺」和「每日站立會議」當作開發的聖經。
現在，讓我們回到文章的核心論點。作者拋出了一個驚人的觀察：那些我們認為最成功、最頂尖、定義了現代軟體開發的科技巨頭——Google 、 Facebook (Meta) 、 Netflix 等——他們從來就沒有真正投入 Scrum 的懷抱。
這就好比，全世界所有的新興餐廳都在瘋狂學習麥當勞的標準化 SOP（標準作業流程），認為這是餐飲業的終極答案。結果你跑到那些真正的米其林三星餐廳的廚房去看，發現他們根本沒有 SOP，沒有人每天開站立會議報告自己今天要切幾公斤的洋蔥，也沒有一個「流程大師」在旁邊指手畫腳。這會讓你感到非常困惑：難道我們一直以來學習的「最佳實踐」，在最頂尖的地方其實並不存在？
作者進一步用數據佐證這個趨勢。 2023 年上半年的科技業大裁員中，Scrum Master 和 Agile Coach 是受創最嚴重的職位之一。這不僅僅是因為經濟不景氣，公司要砍掉那些看起來「非必要」的成本。更深層的原因是，許多公司開始從根本上質疑：「這些確保流程正確運行的角色，真的還能為我們帶來等值的價值嗎？」
這就是所謂的「大出走」。這場出走不僅是被動的裁員，也包含了公司主動的組織架構調整。他們發現，當團隊成熟到一定程度後，Scrum 的各種「儀式」（ceremony），如每日站立會議、衝刺計畫會議、反思會議等等，反而變成了一種官僚化的負擔，而不是助力。
讓我們用樂高城堡的例子來深化理解。想像一下，你的樂高團隊成員，經過長時間的合作，都已經是頂尖的樂高手藝大師。他們彼此之間默契十足，對最終要蓋出什麼樣的城堡有著共同的願景和高度的熱情。在這種情況下：
- 他們還需要每天開站立會議嗎？ 可能不需要了。他們在動手做的過程中，隨時都在交流。「嘿，我這邊城牆要轉角了，你那邊的塔樓接口準備好了嗎？」這種有機的、即時的溝通，遠比每天早上固定 15 分鐘的刻意匯報更有效率。
- 他們還需要一個 Scrum Master 來「掃除障礙」嗎？ 可能也不太需要了。作為頂尖的大師，他們自己就有能力解決絕大多數問題。當零件不夠時，他自己就知道去哪裡找，或者用現有的零件創造出替代方案。他們不需要一個「保姆」來替他們解決問題。
- 他們還需要嚴格的兩週衝刺嗎？ 或許也不用了。一個複雜的魔法塔，可能需要花三週才能蓋出一個完美的雛形，硬要在兩週時打斷，展示一個半成品，反而會打亂他們的創作節奏。他們更傾向於基於任務本身的複雜度，來決定工作的週期。
當團隊成員都具備了高度的自主性、專業能力和溝通默契時，Scrum 這套原本為了「扶持」普通團隊而設計的「輔助輪」，就顯得礙手礙腳了。這正是文章所揭示的，大型科技公司之所以不採用 Scrum 的深層原因。他們從一開始就致力於吸引、僱用和留住那些最頂尖的人才，並給予他們極大的自主權。他們相信，與其用一套僵化的流程去管理一群頂尖的人，不如給他們一個清晰的目標，然後相信他們能自己找到最佳的路徑去達成。
一位前 Facebook 產品經理的話完美總結了這一點：「我在 Facebook 當 PM 一年多，從來沒開過一張票（ticket/task）。我們也不搞衝刺。這裡的 PM 專注於願景、策略和合作夥伴關係，而不是專案管理和任務分配。工程師承擔了大部分的專案管理職責，並且自己創建任務。」
這句話的潛台詞是什麼？在 Facebook 這樣的公司裡，產品經理（PM）的角色更像是「指引北極星的人」，他負責告訴大家：「我們的目標是遠方那顆最亮的星星。」而工程師團隊則是經驗豐富的航海家，他們自己會看星象、辨風向、規劃航線，甚至自己製造和維修船上的工具。他們不需要 PM 每天告訴他們：「今天你要把船帆升起三公尺，明天你要把甲板擦乾淨。」
所以，第一個核心論點可以總結為：Scrum 框架，這個曾經被視為軟體開發的萬靈丹，其熱潮正在退去。最明顯的症狀就是 Scrum Master 和 Agile Coach 角色的式微。而其根本原因在於，行業的領導者——那些頂級科技巨頭——從未真正依賴過這套方法，因為他們的成功秘訣並非流程，而是聚集了能夠在高度自治環境下自我管理、自我驅動的頂尖人才。 當一家公司的人才密度和文化成熟度達到頂點時，Scrum 的價值就從「助推器」變成了「減速傘」。
這就引導我們進入下一個需要深入探討的問題：如果他們不用 Scrum，那他們到底用什麼方法來打造出那些改變世界的產品呢？
第二部分：巨頭的另類之道——從「做敏捷」到「是敏捷」
在理解了頂尖科技巨頭為何不需要，甚至排斥僵化的 Scrum 框架後，一個自然而然的問題浮現出來：那他們究竟是如何工作的？如果沒有了每日站立會議、沒有了兩週衝刺、沒有了故事點估算，他們如何確保數千名工程師能夠協同工作，打造出像 Google 搜尋、 Facebook 社交網絡這樣複雜而龐大的系統？
文章對此提出了第二個核心論點：大型科技公司並非陷入混亂，而是採用了一系列更注重結果、信任和自主性的「反方法論」的方法。其核心是從「遵循流程」（Doing Agile）轉變為「內化文化」（Being Agile）。
讓我們再次運用費曼學習法，把這些看似高深的概念，用簡單的比喻來一一解構。
1.「無正式方法論」（No Formal Methodology）—— 專家樂團的即興演奏
想像一個由世界頂級音樂家組成的爵士樂團。他們上台表演前，會不會有一份精確到每個音符、每個節拍的樂譜？通常不會。他們有的，可能只是一個簡單的主旋律，或者一個共同的基調，比如「今晚我們來一段藍調風格的即興」。
這就是「無正式方法論」的精髓。它聽起來像是「混亂」，但實際上是一種「高度優雅的秩序」。這種秩序建立在幾個基礎之上：
- 僱用最卓越的人，並信任他們（Hiring exceptional people and trusting them to figure it out）： 樂團裡的每一位樂手都是其領域的大師。小號手知道如何吹出最動人的旋律，鼓手知道如何給出最精準的節奏。團長（好比是領導者）的工作不是去教他們怎麼演奏，而是相信他們能憑藉自己的專業和默契，合奏出美妙的音樂。同理，Google 僱用的是最頂尖的工程師，他們相信這些工程師有能力自己「搞定（figure it out）」。
- 清晰的目標，而非詳細的流程（Clear objectives instead of detailed processes）： 樂團的目標是「創造一段能讓聽眾感動的藍調音樂」，而不是「小號手在第三分鐘吹出一個高音 C」。科技公司的目標是「讓用戶上傳照片的速度提升 50%」，而不是「工程師 A 需要修改第 37 行的程式碼」。目標指明了方向，但到達目的地的路徑，則由專業的執行者自行探索。
- 快速交付，拋棄儀式（Shipping fast without ceremony）： 樂團的價值在於演奏出音樂，而不是在演奏前開冗長的會議討論樂理。同樣，軟體公司的核心價值是「交付（Ship）」能為用戶創造價值的產品。所有不能直接服務於這個目標的「儀式」——過多的會議、繁瑣的報告、僵化的流程——都應該被簡化或拋棄。
所以，「無正式方法論」並非沒有方法，而是方法內化在了每個成員的能力和團隊的文化之中。它是一種基於信任和精英人才的高級協作模式。
2.「OKR 取代衝刺」（OKRs Over Sprints）—— 航向目的地，而非計算划槳次數
這是一個非常關鍵的轉變。讓我們回到蓋樂高城堡的比喻。
- 衝刺（Sprints）思維： 我們這兩週的目標是「用掉 500 塊紅色的樂高積木」或者「蓋好東邊的城牆」。這是一種基於產出（Output）的思維模式。我們關心的是「我們做了多少事」。
- OKR（Objectives and Key Results，目標與關鍵結果）思維： 我們這個季度的目標是「讓我們的城堡看起來更具防禦性」（Objective）。如何衡量我們達成了這個目標呢？關鍵結果（Key Results）是：「1. 城堡的高度增加 30 公分；2. 至少建成四座可以防禦的箭塔；3. 護城河的寬度增加一倍。」這是一種基於成果（Outcome）的思維模式。我們關心的是「我們做的事達成了什麼樣的影響」。
看到區別了嗎？OKR 賦予了團隊極大的自主權。領導者只設定了「O（目標）」，並和團隊一起商定了衡量的「KR（關鍵結果）」。至於如何實現這些 KR——是先蓋箭塔還是先挖護城河，是用圓形積木還是方形積木——這些都交由團隊自己決定。他們不再被「兩週」這個固定的時間盒子束縛，而是圍繞著一個季度性的、更有意義的目標去組織工作。他們開會討論的，不再是「你今天能完成幾個任務點？」，而是「我們如何才能最有效地讓城堡看起來更具防禦性？」
這徹底改變了對話的層次，從關注「忙不忙」，轉向關注「有沒有用」。
3.「規劃、建構、交付」（Plan, Build, Ship）—— 回歸常識的極簡主義
這個方法聽起來簡單到像一句廢話，但它的深刻之處就在於它的「返璞歸真」。
想像一位獨立的工匠要打造一把椅子。他的流程是什麼？
- 規劃（Plan）： 他在腦中構思椅子的樣式，需要什麼木材，用什麼工具。可能還會畫個簡單的草圖。
- 建構（Build）： 他開始動手切割、打磨、組裝。
- 交付（Ship）： 他把做好的椅子交給顧客。
然後，他根據顧客的反饋，開始打造下一把椅子（Repeat）。
這其中沒有複雜的儀式。他不需要每天早上對著鏡子裡的自己開站立會議，也不需要用一套複雜的系統來給自己的每個步驟打分。他專注於核心的價值創造活動：思考、製作、交付。
在大型科技公司，這個流程被放大到團隊規模。一個小團隊（通常被稱為「特徵團隊」）會圍繞一個特定的功能或產品進行工作。他們會進行規劃，然後投入數週甚至數月的時間去深度建構，最後將其交付給用戶。這個週期比 Scrum 的兩週要長得多，也更靈活。比如 Basecamp 公司提出的 Shape Up 方法，就是採用六週的開發週期，中間還有兩週的「冷卻期」，讓大家可以修復 bug 、整理程式碼，或者探索新的想法。這更符合創造性工作的自然節奏。
為什麼這套「反方法論」能在巨頭公司奏效？
文章給出了根本性的解釋：因為 Scrum 旨在解決的問題，在這些公司中從一開始就不存在。
Scrum 最大的價值之一，是搭建一座橋樑，連接「不懂技術的業務人員」和「不懂業務的技術人員」。 Scrum 的各種儀式，像是一個翻譯器，讓雙方能用一種共同的語言（如故事點、衝刺目標）來溝通，避免了業務人員提出天馬行空的要求，也避免了技術人員埋頭做一些沒有商業價值的東西。
但在 Google 、 Facebook 這樣的公司，這座橋樑是多餘的。因為公司的創始人本身就是工程師，整個公司的 DNA 就是技術性的。在這裡，「業務人員」很可能就是一個有著深厚技術背景的產品經理。他們和工程師說的是同一門「語言」。他們不需要翻譯器，他們可以直接對話，深入地討論技術實現的可能性和商業價值的權衡。
這就像兩位頂級廚師在討論一道新菜。他們可以直接交流：「如果我們用法式舒肥法來處理這塊和牛，雖然耗時較長，但能最大限度地保留肉汁，提升顧客體驗。你覺得我們的後廚設備和人力能支持這個流程嗎？」他們不需要一個「廚房流程管理師」在中間傳話：「A 廚師說他想用一種很慢的方法做牛排，B 廚師你評估一下要花幾天？」
所以，文章的第二個論點可以總結為：頂級科技公司用一套基於信任、目標導向和極簡主義的文化取代了僵化的 Scrum 流程。他們透過僱用頂尖人才，讓技術和業務思維深度融合，從而消除了對 Scrum 這類「溝通橋樑」的需求。他們追求的不是紙面上的「敏捷流程」，而是根植於組織文化中的、真正的「敏捷狀態」。
這也解釋了文章中一個有趣的觀點：為什麼 JIRA 這款最流行的敏捷專案管理工具，在工程師群體中聲名狼藉（NPS 得分為-83）。因為對於這些追求自主和創造力的工程師來說，JIRA 代表了那種他們極力想擺脫的、鉅細靡遺的、官僚化的微觀管理。當工具本身成為了仇恨的對象，它所代表的工作方法論，自然也到了需要被深刻反思的時刻。
在最後一部分，我們將探討這一切對整個行業，以及對從事敏捷相關工作的人們，究竟意味著什麼。
第三部分：敏捷的未來——從框架的信徒到文化的園丁
我們已經探討了 Scrum 的式微，以及科技巨頭們所採用的替代方案。現在，我們來到最後，也是最具指導意義的一個論點：敏捷（Agile）並未死去，但圍繞它形成的「產業複合體」正在消亡。未來不屬於框架的盲從者，而屬於那些能夠培養自主、實驗和快速反饋文化的領導者與實踐者。
這是一個充滿希望和挑戰的結論。讓我們用費曼學習法來深入理解這其中的轉變和對個人的啟示。
首先，我們必須釐清一個至關重要的區別：「敏捷」（Agile）與「Scrum」的關係。
想像「健康生活」是一個巨大的、美好的理念（這就是 Agile）。它包含了很多核心原則，比如：均衡飲食、規律運動、充足睡眠、保持心情愉快等等。
而「生酮飲食法」、「地中海飲食法」或「CrossFit 健身計畫」則是實現這個理念的具體、標準化的「方法論」（這就是 Scrum 、 SAFe 等框架）。
文章的核心觀點是：人們對「健康生活」（Agile）的追求從未停止，而且愈發強烈。但越來越多的人發現，盲目地、一成不變地遵循某個特定的「飲食法」（Scrum）可能並不適合自己。有的人用了生酮飲食法，結果精神不濟；有的人練了 CrossFit，結果受了傷。
於是，聰明的人開始做什麼？他們不再問「我應該遵循哪種飲食法？」，而是回歸到「健康生活」的本質原則上。他們開始學習營養學知識，了解自己的身體狀況，然後為自己「量身訂做」一套方案：可能早餐像地中海飲食，午餐注重低碳水，晚餐後會去散步，週末還會做瑜珈。
這就是文章所說的，從「做敏捷」（Doing Agile）到「是敏捷」（Being Agile）的轉變。
- 做敏捷（Doing Agile）： 就是嚴格遵循 Scrum 的規則。開每日站會、跑兩週衝刺、估算故事點、使用 JIRA 。這就像一個新手廚師，嚴格按照食譜上的指示操作：「加入 5 克鹽，攪拌 30 秒」。他可能能做出一道還不錯的菜，但他並不真正理解為什麼要這麼做。他的團隊可能在「做」敏捷，但內心深處仍然是僵化和被動的。
- 是敏捷（Being Agile）： 則是將敏捷的核心原則內化於心。這些原則包括：以客戶為中心、擁抱變化、小步快跑、持續反饋、團隊協作與信任。這就像一位經驗豐富的大廚，他理解鹽是為了提鮮、攪拌是為了讓食材混合均勻。他會根據食材的狀況、顧客的口味，即興地調整鹽的用量和攪拌的方式。他的團隊是真正「敏捷」的，因為他們具備了適應和創造的能力。
文章指出，71% 的受訪者仍表示他們在開發中採用敏捷方法，這並不矛盾。這正說明了大家依然認同「健康生活」的理念，但他們實踐的方式正在變得越來越個人化和混合化（tailored approaches）。他們可能會保留每日站會，但把衝刺週期拉長到一個月；或者他們會放棄故事點估算，轉而用更務實的對話來評估工作量。他們在保留敏捷精神的同時，正在無情地剝離那些對他們而言已經成為負擔的「儀式」。
那麼，Scrum 在什麼情況下依然有效？
文章也公平地指出了 Scrum 的適用場景，這幫助我們更完整地看問題。
- 「廚房水槽團隊」（Kitchen sink teams）： 想像一個團隊，什麼亂七八糟的活兒都往裡扔，有客戶支持、有新功能開發、有 bug 修復。這種情況下，一個固定的節奏（衝刺）能幫助他們在混亂中建立秩序。
- 需要保護的團隊（Teams that need protection）： 如果團隊總是被來自四面八方的領導和利益相關者打擾，Scrum Master 就像一個門衛，能為團隊創造一個專注工作的「保護罩」。
- 業務與技術脫節的組織： 在那些業務人員完全不懂技術，技術人員也完全不關心業務的公司裡，Scrum 的橋樑作用依然至關重要。
但是，文章的潛台詞是，這些場景恰恰是「不夠理想」的組織狀態。一個成熟的、高效的組織，應該努力讓團隊變得專注、自主，並促進業務和技術的融合，從而「進化」到不再需要 Scrum 的階段。
對敏捷從業者（Scrum Master/Agile Coach）的啟示
這篇文章對這個群體發出了最嚴峻的警告，同時也指明了進化的方向。如果你的價值僅僅是「背熟 Scrum 指南」、「主持會議」、「移除團隊成員提出來的日常小障礙」，那麼在經濟下行和組織成熟的雙重壓力下，你的職位將岌岌可危。因為這些事情，一個成熟的團隊完全可以自己完成。
未來的敏捷專家，需要從一個「流程警察」轉型為一個「文化園丁」。他們需要具備更高級的能力：
- 不依賴框架，促進協作（Facilitate collaboration without rigid frameworks）： 你能否在沒有每日站會的情況下，依然確保資訊在團隊中順暢流動？你能否設計出更適合團隊現狀的溝通方式？
- 幫助團隊對齊目標，而非管理衝刺（Help teams align on objectives rather than manage sprints）： 你能否引導團隊進行 OKR 式的思考，讓大家從關注「做了什麼」轉向關注「達成了什麼影響」？
- 移除系統性障礙，而非日常阻礙（Remove systemic impediments rather than just daily blockers）： 當團隊成員說「我電腦壞了」，幫他報修是日常阻礙。但如果你能發現「公司採購的這批電腦普遍存在問題，導致開發效率低下」，並推動更換，這就是移除系統性障礙。後者的價值要大得多。
- 建立文化，而非遵循流程（Build culture rather than follow processes）： 這是最高級的能力。你是否能幫助團隊建立起信任、透明、敢於實驗、不怕失敗的文化氛圍？文化，才是那個讓團隊在沒有流程約束時依然能高效運轉的隱形力量。
對領導者的啟示
最後，文章將責任回歸到了領導者身上。如果你想要一個具有高度自主性和創新力的敏捷文化，你不能靠引入一個框架來「安裝」它。你必須去僱用和培養能適應這種文化的人。
偉大的領導者僱用偉大的人才，偉大的人才促成偉大的文化。（Great leaders hire great talent, great talent enables great culture.）
這是一個簡單而深刻的因果鏈。與其花錢請一堆敏捷教練來教大家「做敏捷」，不如把這些資源用在吸引那些天生就「是敏捷」的頂尖人才上，並為他們創造一個能讓他們盡情發揮的環境。
最終總結
這篇文章透過對 Scrum 現象的深刻剖析，向我們揭示了一個軟體行業正在發生的巨大轉變。以 Scrum 為代表的、標準化的、儀式化的敏捷框架正在退潮，尤其是在行業的頂端。取而代之的，是一種更加務實、靈活、以人為本、以成果為導向的「真敏捷」文化。
這不是對敏捷精神的否定，恰恰是它的進化和升華。未來屬於那些能夠理解並實踐這種文化的人，無論他們是領導者、產品經理、工程師，還是正在尋求轉型的敏捷專家。科技巨頭們早已領悟到這一點，現在，是時候讓其他人跟上了。