作者 |Miriam Posner
譯者 |彎月
出品 | CSDN（ID：CSDNnews）
記得第一次接觸敏捷是我在圖書館工作期間。我的工作是從無到有建立一個新的數字化獎學金中心，有時我需要與圖書館的軟體開發團隊合作，構建支援專案的工具。當時開發團隊有六名成員，我發現他們的工作方式與非技術人員截然不同。
開會時，他們討論的不是產品功能，而是“使用者故事”（描述功能的小段文字），而且他們還會分配“故事點”來衡量完成相關任務所需的工作量。每天早上，他們會舉行“站立會議”，實際上就是站著開會，據說站著是為了加快會議的速度。他們的辦公空間內，白板必不可少，開發人員會移動白板上的便利貼以表示工作的完成狀態。他們按照“衝刺”劃分工作週期，一般一個“衝刺”為期兩週，他們需要在這兩週內專心完成特定任務。
在與圖書館的工作人員開會時，開發團隊的負責人會使用軟體報告進度，其中包括表示每個專案狀態的儀表板。經理還可以向我們展示團隊的“速度”圖表，即開發人員完成任務的速度，以及歷史資料比較和預測。
後來，我瞭解到這就是
敏捷，一種管理軟體開發的方法
，這種方法在各大技術公司非常受歡迎，而且在非技術辦公場所也越來越流行。老實說，敏捷給我留下了深刻的印象。其實，在日常工作中，我經常感覺很迷糊，不確定自己的工作有沒有進展，或者有沒有做真正有價值的工作。相比之下，開發人員似乎非常清楚自己在做什麼。即便他們遇到困難也沒關係，只要解決困難就可以了。他們的需求會不斷變化，而兩週為單位的工作週期，可以讓他們迅速在各個功能之間切換，甚至可以採用新框架，而無需從頭開始。
這就是
敏捷的美妙之處
：非常靈活，速度非常快，它要求開發人員將每項任務分解為儘可能小的單元。重點是快速釋出，不斷回顧，並根據需要改變方向。
我對敏捷非常感興趣。敏捷是從哪裡來的？敏捷的目標又是什麼？
於是，我開始探索敏捷的歷史。我發現長期以來，經理想要的軟體開發過程與開發人員實際編寫軟體的過程之間一直存在矛盾。各大組織一次又一次地引入新的管理風格，就是希望控制軟體開發面臨的最大問題：超出時間與預算限制。後來，各個公司發現敏捷解決方案不僅可以讓開發人員愉快地完成任務，而且還能保證開發速度。
不過，最近一些跡象表明敏捷的力量正在衰退。人們正在醞釀新的方式，而且很有希望取代敏捷。
軟體工程師
軟體開發的危機在“軟體”這個詞發明之前就存在了。1954年，行業、政府和學術界的領袖們在美國底特律韋恩州立大學召開了一次會議，與會的專家表示，我們缺乏接受過一定培訓的程式設計師。直到四年後，“軟體”這個詞才首次出現在統計學家 John W。 Tukey 的一篇文章中，用於表示應用程式程式設計。到了20世紀60年代中期，美國有至少 10 萬人從事程式設計師的工作，但據估計至少還有5萬的缺口。
在程式設計行業剛剛起步的幾十年裡，大多數專家認為，編寫計算機可讀的程式碼並不是很難。畢竟系統分析師（高階架構專家）已經完成了設計程式和硬體的艱苦工作。而程式設計師的工作不過是將設計轉化為可供計算機執行的程式碼。然而，事實證明這個翻譯過程是一項難度很高的腦力工作。
這項工作需要強大的腦力支援，而且更大的疑問是軟體開發究竟是什麼樣的工作，時至今日這個問題依然困擾著管理人員。在計算機誕生初期，在某些人看來，程式設計是（或者說應該是）純粹的邏輯問題。畢竟，機器只能按照指令工作。因此，我們需要告訴計算機正確的執行方式，而程式設計師的工作就是找到這種方式。
然而，實際的程式設計經驗表明，程式設計既是藝術又是科學。2019 年，Clive Thompson 在《程式設計師》一書中指出，
最先進的程式設計工作都是由一群大學實驗室的技術怪人完成的，他們認為自己既是工匠又是邏輯學家。
軟體本身是看不見摸不著的（你只能看到儲存軟體的介質），因此與其他工程領域相比，軟體開發的工作更加抽象且神秘。其他領域都有一定的物理定律可循，但軟體似乎建立在流沙之上，因為硬體的引數和能力在不斷變化。
然而，電子資料處理領域（辦公自動化，如考勤卡和工資單）得到了迅速發展，因此這些任務使用的機器也迅速地成了技術的最前沿。但我們需要運維團隊來設計程式、準備打孔卡並將資料輸入系統。老牌經理們看不慣年輕的專業團隊日益壯大，也看不慣軟體專案的成本和複雜性經常不可控。計算機科學家 Frederick Brooks 曾將軟體專案比作狼人：這些專案剛開始的時候就像小狗一樣天真無邪，但最後往往會演變成“不遵守時間計劃、預算超支且有缺陷產品的怪物”。20世紀60年代後期，軟體開發面臨三大危機：迫切需要更多的程式設計師；必須提高可預測性；開發人員必須配合管理層的工作。
本著這種專業化的精神，行業領導者鼓勵程式設計師接受“軟體工程師”的概念，這個概念是在 1968 年北約軟體工程會議提出的。許多組織領導都指出，軟體開發的規模龐大、組織難度高，而且很難管理。那麼，為什麼不借鑑一些其他工程領域的方法呢？將程式設計工作發展成為一門科學，並建立一套有秩序、有影響力且可靠的方法。組織者希望，降低軟體開發行業的管理難度，軟體工程師可以學習其他學科工程師的模式，更好地融入企業文化。歷史學家 Nathan Ensmenger 寫道，“為了提高製造軟體的效率，程式設計的黑魔法必須讓位於科學的軟體工程方法。
瀑布式軟體開發
軟體工程似乎的確有效。各個大學都採用了這個術語，鼓勵學生在學習程式設計時，練習完善的工程方法，例如使用數學證明等。計算機科學家 Tony Hoare 聲稱，
這些技術將“改變晦澀難懂且容易出錯的計算機程式設計工藝，以滿足工程專業的最高標準。”
另一方面，經理們也花費了大量心思來組織軟體開發人員，並建立了多種不同的組織方法。其中一種方法是 IBM 推出的主程式設計師組（Chief programmer team，CPT）框架，該框架由一名主程式設計師負責監督一組核心專家成員的工作。還有一種流行的做法是，由多級管理者負責管理程式設計師，管理者們制定決策並將工作分配給麾下的程式設計師。
隨著這些新技術的出現，程式設計師的管理也冒出了很多新方法，其中之一就是
“瀑布式軟體開發”
。從理論上來說，瀑布式開發非常合理：有人為軟體產品設定目標，並將生產分解為一系列步驟，必須確保當前步驟的所有工作都已完成並透過測試，才能繼續下一個任務。換句話說，開發人員只需要按部就班地執行管理層定下的計劃即可。
然而，充滿諷刺意味的是，首次提及“瀑布”一詞的文章指出這種方法不切實際，但這個名稱和思想卻依然流行起來了。瀑布式開發與採用這種方法的公司的層級結構非常契合，正如 Nathan Ensmenger 寫道：“軟體工程運動的本質是控制：控制複雜性、控制預算和日程計劃，而最重要的恰恰是控制勞動力。”而這正是瀑布式開發最擅長的領域。
但不久之後，軟體開發再次陷入危機。部分問題是計算機科學家的供不應求。在20世紀80年代，各個大學沒有足夠的師資力量來培養大量立志成為軟體工程師的學生。美國計算機協會表示，“這種情況十分嚴重，甚至威脅到了計算機科學部門持續培養資訊處理行業以及科技日新月異的社會所需的技術人才的能力。”
缺乏開發人員並不是軟體行業面臨的唯一難題。軟體開發本身似乎也深陷泥沼。瀑布式管理承諾的嚴格控制管理化成了海市蜃樓。再多的文件、再多的流程、再多的程式也拯救不了軟體開發的不可預測性。軟體專案規模巨大、成本高昂，而且經常會失控，由於需求的不斷變化，專案團隊之間在細節問題上爭吵不休，所有的計劃都無法按時完成。管理人員使出渾身解數，想讓軟體開發變得更可靠、更可預測，但結果卻愈演愈糟。正如計算機科學家 Jeff Offutt 所說，“20世紀60年代，程式設計師建造的都是‘小木屋’，而到了80年代，程式設計師團隊建造的都是辦公樓”，而到了90年代，他們建造的都是摩天大樓。然而，技術專家團隊似乎無法協調他們的工作。根據技術行業顧問 Peter Varhol 的估計，20世紀90年代初期，從構思到產品問世，每個應用程式所需的開發時間平均為三年。高科技本應讓各大企業更智慧、更快、賺取更多利潤，然而很多公司的專案都未能順利完成。
“工程師”的頭銜、層級管理結構、周詳的計劃和文件，所有這些都是為了給新興的軟體開發領域帶來秩序和控制，但最後的結果卻適得其反。瀑布並沒有為軟體開發人員掃清障礙，相反大量的文書工作和無休止的會議加重了他們的負擔。
工程師對各種苛刻的管理怨聲載道。他們只想構建軟體，結果卻不得不疲於應付大量文書工作。Douglas Coupland 的小說《Microserfs》（微農）以及Mike Judge的電影《上班一條蟲》（Office Space）中描繪的絕望的開發人員就是那個時代的寫照。
敏捷宣言
2001 年 2 月，17箇中年人聚集在美國猶他州瓦薩奇山區雪鳥滑雪勝地的洛奇酒店裡，為軟體開發制定了一套全新的流程，這就是後來的敏捷宣言。這不是他們的第一次見面。長期以來，他們以各種形式聚集在一起討論軟體開發，最終在 2001 年的這次會議上，他們起草了敏捷宣言。這是一套價值觀，在接下來的幾年裡，這些價值觀滲入了程式設計師管理的方方面面，無論是初出茅廬的初創公司還是聞名世界的科技巨頭都相繼採用了這套管理方案。
敏捷宣言本身簡潔明瞭
：
我們一直在實踐中探尋更好的軟體開發方法，
身體力行的同時也幫助他人。由此我們建立了如下價值觀：
個體和互動 高於 流程和工具
工作的軟體 高於 詳盡的文件
客戶合作 高於 合同談判
響應變化 高於 遵循計劃
也就是說，儘管右項有其價值，我們更重視左項的價值。
該宣言還補充了十二項附加原則，描述了工程師所面臨的難題。瀑布式開發假定軟體應用程式的需求是穩定的，但由於速度緩慢，而且管理僵化，因此最後的結果往往偏離管理層當初制定的計劃。敏捷拋棄了這些高階路線圖，轉而強調即時做出決策。如此一來，
軟體開發人員就可以隨著需求或技術的變化而改變自己的工作方式以及內容。
他們可以專注於構建軟體，而不必被文書工作和各種文件搞得暈頭轉向。此外，他們還可以擺脫無休止的會議。
這份檔案十分有意思。在專業開發人員稀缺的前提下，技術專家們本應訴求更直接的物質利益，比如工會、對智慧財產權的擁有權等，但他們要求的卻是更好的工作環境，能夠讓他們更出色、更高效地完成工作。正如作家 Michael Eby 指出的那樣，這種反抗管理的精神與之前對工作場所不滿的表現方式截然不同：技術人員要求的不是物質提升，而是建立一種基於文化、原則、假設、等級制度和道德的“新精神”。敏捷宣言抨擊了官僚主義、天真以及徒勞無功的努力。開發人員並沒有要求更高的報酬，他們只是希望自己能被區別對待。
組織的無政府主義者
對於軟體開發性質的看法變化並非發生在 2001 年，而是在敏捷宣言出現之後的十年左右。開發人員和管理人員都逐漸認識到，軟體開發不可能完全按照分析師給出的流程圖和工作表推進。正如歷史學家 Stuart Shapiro 指出的那樣，軟體開發的複雜性比較特殊，該領域的問題是“模糊、多變和多方面的，因此很難找到一種通用的方法。他們需要結合多種方法，並調整各自的解決方案。”這與循規蹈矩的填表和打卡完全不同。此外，隨著20世紀90年代程式設計師數量的急劇增加，各大公司招聘了一些非計算機科學專業畢業的人才。這些年輕的程式設計師並沒有經歷過人們在七八十年代嘗試將軟體開發變成一門科學的努力。敏捷宣言並不是一劑良藥，它更像是一支插曲，只不過是展現了軟體開發人員多年來對流行的企業管理模式的不滿而已。
然而，雖然敏捷有一群忠實的擁護者，但它的使命（即消除自上而下的計劃與層級管理）也存在一定的風險。這意味著，管理層要或多或少地將控制權拱手讓給開發人員。大多數大公司都不願意這樣做，至少在 2010 年之前是這樣。不過，根據敏捷諮詢公司 Planview 的統計資料，從2012年～2015年，超過50%的開發團隊都認為自己是“敏捷式開發”。
毫無疑問，敏捷開發的流行在一定程度上受到了網際網路高速發展的影響，網際網路極大地改變了軟體的釋出方式。以前，軟體更新的頻率一般為一年一次，甚至更長。而且必須藉助CD和軟盤等物理介質分發，這極大地限制了新版本的釋出速度。但是，如今我們可以藉助高速網際網路，根據公司的需要頻繁地釋出補丁和新功能，甚至可以高達一日多次。而敏捷正是在這種環境下孕育而生的。
Facebbok 曾有一個座右銘“快速行動，打破常規”，很好地體現了新時代的精神。這是一個考驗膽量的時代，無論是軟體開發還是公司CEO都要大膽創新。風險投資公司的目標是尋找“獨角獸”，他們在2010年前後向科技行業投入的資金創下了新高，因為他們希望儘快看到結果。與眾多創業公司展開角逐需要迅速改變，不斷髮布新版本，並以驚人的速度發展。風險發生了變化，如今堅持使用瀑布式開發會非常危險，而敏捷式開發則可以大幅提升速度。
同樣，軟體開發人員也發生了變化。在20世紀70年代和80年代，專家們將注重系統和邏輯思維的科學家視為理想的軟體工作者。但多年來，這一理想未能紮根。我們透過敏捷宣言就能看出，他們的目標是致力於最高標準，快速而自信地工作，而經理們“相信他們能夠順利完成工作”。但是他們拒絕因循守舊。他們不怕快速變化的需求，相反，他們認為這是“駕馭客戶需求變更的有利競爭優勢”。
解放思想、打破墨守成規的思想與敏捷宣言的理念完全吻合。敏捷宣言的作者們看起來就是典型的工程師，穿著襯衫，腰裡彆著手機套，但敏捷宣言的起草者之一 Jim Highsmith 表示，“無政府主義者本來就不會成為更大的組織”。尤其是在早期，人們曾經就敏捷方法給傳統管理正規化帶來的挑戰展開過許多討論。敏捷的支持者為這種與眾不同感到自豪。Jim Highsmith 曾在 2001 年寫道，這個框架“嚇壞了傳統主義者。”軟體開發人員和顧問 Al Tenhundfeld 也曾表示，“敏捷是公開的、激進的、反管理的。例如，Ken Schwaber ［敏捷宣言的作者］ 直言不諱地表達了希望擺脫所有專案經理的目標。”
反管理，但不是反企業。人們很容易將敏捷開發人員視為20世紀60年代後期圍著打孔機轉悠的科技“怪人”的復興。然而，這兩種人截然不同。早期的科技“怪人”希望程式設計這項新技術能夠投入使用。而敏捷式開發的程式設計師會全身心地投入專案。他們討厭管理層的干預，因為管理層阻礙了他們實現最大的願望，即以最高水平的專業表現迅速完成工作。就像 Aaron Sorkin 的《社交網路》中的開發人員一樣，他們希望所有人都待在自己的工作區域，戴上耳機，消除一切干擾，專心致志地投入工作。
管理層的復仇
在圖書館工作期間，我一直在關注開發人員，我非常欣賞他們的團隊合作和務實精神。然而，隨著時間的推移，我也注意到了這些團隊的一些問題。儘管他們有速度圖表和嚴格的功能記錄，但開發人員的進展似乎並沒有預期的那麼快。他們都在努力工作，這很明顯，但他們面臨一個致命的缺陷：沒有人清楚專案最終應該是什麼樣子，或者說服務的目標是什麼。雖然團隊成員可以開發功能，但他們不清楚為什麼要開發這些功能。也許這個問題只是我們這個專案的問題，但是影響很大。同時，我也開始懷疑敏捷方法是否有一定的侷限性。
事實上，任何接觸過軟體開發的人都可能聽說過關於敏捷的傳言。儘管敏捷宣言給出了許多承諾，但人們逐漸意識到，敏捷式開發也不能完全解放開發人員。軟體開發再次陷入了危機，但這一次，是敏捷危機。從普通開發人員到一些最初的宣言作者，每個人都對敏捷實踐產生了擔憂。很多人都談到了“敏捷工業綜合體”，即由敏捷顧問、演講者和教練構成的網路，他們收取大量費用來幫助組織調整敏捷流程。幾乎每個人都在抱怨敏捷轉向了錯誤的方向：在過去的二十年裡，敏捷偏離了最初的宣言，如今開發人員受到的限制、承擔的工作量與壓力更大了。
部分問題在於敏捷的靈活性。自由開發者 Jan Wischweh 稱這是“沒有真正的蘇格蘭人”的問題。
凡是人們不喜歡的敏捷實踐就不是敏捷。
敏捷宣言的結構就決定了這個不可避免的問題：因為宣言沒有規定任何具體的活動，所以我們只能衡量現行方法的精神，這一切都取決於具體的實踐者。因為敏捷只是一種“思維模式”，而不是一種方法論，因此組織的特徵必然會影響到敏捷的實踐。另外，人們也無法批評敏捷，因為你無法將敏捷化為一組特定的方法。一位產品經理告訴我：
“如果敏捷不適合你，人們會認為這是因為你的實踐方法不正確，而不是因為框架本身有問題。”
儘管敏捷的定義非常靈活，但許多開發人員已經對敏捷的想法失去了信心。Wischweh 本人在向一位律師介紹站立會議時，遇到了一個從未想過的問題。
一位稱職的專業人士每天都需要證明自己確實在工作，而且還要精確到非常小的單位，
這對她來說太荒謬了。Wischweh 開始思考敏捷實際上是在鼓勵開發人員將自己視為機器中的齒輪。雖然他們沒有像瀑布模型那樣被埋在管理層的管控之下，但業務的優先順序仍然由管理層決定。“作為開發人員和 IT 專業人士，我們喜歡將自己視為知識工作者，我們不需要解釋自己的工作，也不能被商品化。但我認為敏捷在朝著完全相反的方向努力。”
宣言的作者之一 Al Tenhundfeld 指出，他們都是在職的開發人員，而最早接受敏捷宣言的是自我管理的程式設計團隊。然而，現在有很多專業人士幫助團隊實施敏捷，而敏捷會議也是由經理主導，而不是開發人員。如今的敏捷變成了自上而下的管理形式。而敏捷專案經理，通常作為“產品負責人”嵌入到團隊中，他們被夾在兩股勢力中間：一方面需要為開發人員考慮，另一方面需要交付成果給管理層。
儘管團隊受到多個方向的牽制，但仍然需要以越來越快的速度推進專案。畢竟，根據敏捷的定義，“衝刺”（sprint）本身就意味著快速。事實上，許多與我交談過的科技工作者都表示前景堪憂。技術作家 Sarah Moir 表示，“你必須定義在這個時間段內合理地完成哪些工作，然後跑到終點；然後再重複，然後再到終點，如此反覆。如果付出百分百的努力，很快就會讓人覺得筋疲力盡。”
此外，還有日常站立會議、輕量級的任務以及頻繁的檢查，對開發人員來說，這些都是為了監控自己的工作。特別是將工作分解成一些小塊，開發人員就揹負起了一種責任感：他們必須完成每一項任務。而且開發人員也會感受到壓力：他們必須證明自己的價值。畢竟，他們是員工，拿了公司支付的薪水。
“故事點”，用來衡量特定開發任務所涉及的工作量的抽象概念，也失去了實質性的作用。最初，開發團隊引入故事點，是為了方便開發人員控制工作量和工作內容。然而，在實踐中，故事點變成了評估開發人員績效的一種方式。西雅圖的軟體工程師 Yvonne Lam 表示，
“一旦將某些東西放入數字工具中，人們就會監控這個數字，並希望它上漲，對不對？”
然而，問題不僅在於監控，還有將這些故事點轉化為時間計劃的方式。John Burns 是一家平臺公司的工程師，他說之前的一個公司只是簡單地將故事點乘以一個共同係數，就粗略地估算出了專案所需的時間。儘管人們普遍認為故事點只是一種非正式的內部衡量標準，但管理人員還是將它們作為計劃的工具。
下一次危機
這些抱怨的背後是對敏捷所承諾的自由的更深層次的懷疑。敏捷非常重視開發人員的創造力和獨特的工作方式。但是，採用敏捷式開發，員工能夠發揮出的創造力有明顯的限制，特別是因為問題常常被分解成如此小塊。Michael Eby 寫道，“很明顯，敏捷消滅了層級管理控制的許多弊端，但只是為了以更微妙的方式管控細節。”Yvonne Lam 指出，敏捷的自治在實施中具有很大變數，
“雖然敏捷說你有自主權決定自己的工作方式，但有時你想要的是有權利說不。”
在軟體開發專案的過程中，我們需要做很多選擇，比如語言、框架、結構等，但我們忽略了一點：
通常重大決策都沒有開發人員的參與。
在過去的幾年裡，這些問題變得更加重要和緊迫。我們看到科技人員改變公司業務戰略的許多例子，Google 開發人員抗議公司與國防部締結人工智慧合同，遊戲開發人員抗議性騷擾。這些要求超出了敏捷的職權範圍，因為它們的目的不是為員工創造更好的工作條件，而是徹底改變工作的性質。
還有一個方面值得考慮，敏捷對塑造辦公文化的影響。不可迴避的事實是，敏捷宣言的作者是一群非常特殊的人，雖然他們的經歷不同，但他們的關注點基本相同。而且這個小組最後也承認當初他們的團隊多樣性不足，並宣稱要在敏捷聯盟（一個與敏捷宣言相關的非營利組織）中加入更多的聲音。
但是，根據一系列敏捷相關方法的調查，如果你在工作中面臨歧視或騷擾，那麼就要有所警覺了。例如，許多人都證實了“結對程式設計”非常有效，但這種做法的前提是兩位團隊成員的關係很融洽。同樣，敏捷的“回顧”聽起來很不錯，但往往會陷入互相指責的漩渦中，一切都取決於團隊的領導。GitHub 前社群安全經理 Coraline Ada Ehmke 講述了開發人員利用程式碼審查的過程騷擾同事的情況。雖然我們知道，消除官僚主義、等級制度和文件記錄非常好，但有時我們卻需要規則的保護。
對於一些失敗的科技專案，敏捷是不是充當著“助紂為虐”的角色？當看到前 Facebook 經理Frances Haugen 於 2021 年 10 月在國會作證時，我想到了這一點。如果一家公司設定的目標是提高使用者參與度，那麼敏捷必然會鼓勵開發人員朝著這個目標努力，那麼是不是說即便經理認為可以讓使用者發表偏激的內容，開發人員也不能據理以爭？是站在道德一方，還是堅持敏捷宗旨全力以赴迅速完成工作？開發人員陷入了兩難境地。
考慮到當代軟體可能涉及機器學習、大型資料集或人工智慧等技術，這個問題變得尤為緊迫，事實證明這些技術具有潛在的破壞性。數字理論家 Ian Bogost 認為，這種快速行動和打破常規的做法恰恰說明軟體開發人員根本不是“工程師”，他指出，工程是一組具有道德和社會責任的規範。敏捷承諾沒有這樣的責任心，它的目標只有一個：構建產品。
敏捷擅長劃分功能，將它們整齊地打包成衝刺和可交付成果。這確實是整個軟體工程的發展趨勢，模組化或“資訊隱藏”是人類管理系統的重要方式，因為系統過於複雜，任何人都無法掌控。但是敏捷將功能轉變為白板上的“使用者故事”，這就有可能創造出 Yvonne Lam 所說的“否認鏈”：整條流水作業線上沒有任何人能對團隊建立的產品承擔全部責任。
敏捷宣言描繪了一個迷人的畫面，看似軟體開發擁有了民主自由。但問題在於，實際的實施注重的只是最終結果，而不是開發人員的福祉。在工作優先順序一致的情況下，敏捷宣言確實可以加強開發人員的自主權，但實際上我們會面臨各種衝突，比如專案經理就經常面臨兩難局面：一方面是對客戶的承諾，而另一方面是開發人員手頭需要優先完成的工作。
一家學術機構的軟體工程師 Mark Matienzo 表示，“人們希望透過流程來管理無法控制的模糊性，尤其是在一些無能為力的地方，比如一些來自高層管理人員或行政部門的突發奇想。你無法影響高層的戰略方向，但敏捷卻讓開發人員覺得自己有一定的自主權。”他直言不諱地說，
“敏捷欺騙了開發人員，讓他們覺得自己擁有工作的自主權，但從勞動者的角度來看，他們根本沒有什麼權利。”
軟體開發永遠都無法達成公司期望的時間計劃和各項指標。現代應用程式的複雜性使得軟體開發有時顯得非常神秘莫測。雖然計算機最初是軍用裝置，但想讓程式設計工作完全遵從資本的優先順序，卻異常困難。當初軟體工程未能拯救軟體開發，於是企業開始寄希望于敏捷，這種思維模式賦予了開發人員一定的自主性，並希望他們全力以赴達成組織的目標。然而，正如越來越多的開發人員指出的那樣，這種自主權非常有限。在企業的實踐中，敏捷所推崇的方法和價值觀總是以企業的需求為導向。無論辦公場所多麼靈活，會議多麼隨意，最終目標依然是組織的利潤。
然而，敏捷也有一些優點。有人指出，敏捷具有促進員工團結的潛力。如果團隊能夠獲得真正的自主權，公開分享一切，也許敏捷真的能夠實現承諾。也許管理層在敏捷的助力下，成為了自己的掘墓人。也許軟體開發的下一次危機就來自開發人員自己。