安利一篇文章，說明SCRUM爲什麼永遠不會起作用。需強調，如作者開篇解釋的，作者本身是SCRUM堅定實踐者，信仰敏捷。本文的目的，是基於as negative as possible情況下，總結SCRUM失效的原因，純理論推導的結果。這種方法類似《思考，快與慢》提到的事前驗屍法，先假設會失敗，然後推因，最可能是什麼原因造成的？其實企業跟人一樣，表象各有不同，但歸根到底就那麼幾個根因，死活無法改變。因此其總結的失敗原因，極具參考價值。特別在傳統企業，習慣瀑布式方法論，組織層級冗餘，弱矩陣結構，對於實施敏捷的阻力，深有感觸。舉個例子，最近在做的項目，業務方反對敏捷實施。理由一業務是全鏈條關聯的，不能先上一部分再上一部分；二是項目不着急，沒必要採用這種大家都不熟悉的方法；三是認爲會犧牲質量，先上的功能沒有得到充分的調研、測試。藍圖階段，只有做全範圍內的調研與方案，才能保證各個功能模塊的質量。其實說到底，還是業務敏捷跟不上。這很難改善，因爲人不會變化。干係人拒絕不確定性，抵制透明。讓一幫傳統企業的大叔陪你玩敏捷？
Anyway，原文鏈接如下。
https://maurits.wordpress.com/2011/07/13/why-scrum-will-never-work/
原文翻譯如下：
因爲本文標題具有爭議性，我需先做下解釋：本文所寫僅是個人觀點，無關我的僱主，如果以後我還有僱主的話。。。此外，我本人是SCRUM和其他敏捷方法的忠實粉絲，畢竟我是從中受益的。最後再強調下，我百分百確信SCRUM適用於軟件開發。
我真的喜歡SCRUM，並在過去5年中一直使用。我在多次會議中做了SCRUM的報告，並寫了一篇相關文獻。敏捷宣言距今已十年，我認爲可以採用 Edward de Bono‘s black hat方法來分析SCRUM失效的原因。
原因1：
SCRUM的基礎是相信他人。創造一個安全的環境，保證我們彼此開放，從錯誤中學習。但這很難實現。許多領導是容易炸毛的（我的領導不是，他是個nice guy）。職場上存在許多alpha雄性領導者，對你、過程、你的成長毫無興趣。開放只會傷害你的職業生涯。不會有機會讓你去犯錯、去接受風險。
原因2：
SCRUM原則“給予足夠的自由度才能發揮人最大的價值”，是站不住的。公司給予最小的自由度因爲軟件開發者通常所得報酬是過低的，特別與他們的領導相比。這也是他們想成爲管理層或架構師的原因，可以愉快的摸魚並獲得更高的獎金。
原因3：
基於上一個原因，我們仍需要在SCRUM團隊上加一層項目管理，來保證最小量的輸出。所以管理上可能不會變化，分配任務給組員，適度管理開發人員，要求做進度彙報等項目工作。所有這些管理工作會使團隊效率變慢。
原因4：
SCRUM只是一個方法論。我已見過許多失敗的方法論，留下一地困惑的people。如果你已陷入到一個傳統、不理解敏捷的組織中，很難發生任何改變。SCRUM不會改善你的軟件，這取決於人。環顧四周，你的開發者都是average joe（張三李四普通人），因爲錢就那麼點。
原因5：
SCRUM並不會實現商業價值。熟悉業務的同事不願參與到你的項目中。他們更願意與客戶打交道，而不是一幫碼農，花額外時間瞭解純IT的概念。所以團隊只能選擇初級業務人員作爲PO。另外，ICT部門本身就是成本中心，何談商業價值？
原因6：
敏捷團隊應該持續改進，這也是SCRUM中回顧會議的意義。哪些做的好，哪些待改進。但人們真的願意去改進嗎？這需要提出可能的改進措施。然後可能就會由提出者去執行了，這往往意味着出離舒適圈。人們害怕變化，因而拒絕改進。舊的習慣也許有問題，但起碼能用，能維持。
原因7：
PO聚焦what及why，開發團隊決定how。如此分離的目的是團隊聚焦質量並保證長期高效。但實際並非如此，PO關注功能的時效性，而不是軟件質量。出於對關鍵顧客或其他相關方的承諾，PO在意的是在deadline之前完成特性。不要以爲團隊可以壓過這位初級業務PO，他背後往往站着高層級業務領導。而作爲開發人員，成本中心的一份子，你只是可隨時被外包替換的資源，如何談激勵與信任？
原因8：
上一個原因有關質量。追求進度會拉低軟件質量。另一方面，當關注質量時，生產力會提高。但average joe開發人員並不關心質量啊。質量差，開發會多花些功夫，但誰會關心？項目經理或者SM，會怪罪於不完善的項目計劃。並不會因爲採用SCRUM，生產力受到更多重視。
原因9：
“但如果我們只構建必要特性，至少我們控制了最低總成本。”這是一個天真的想法。你並沒有構建必要的特性。很多時候簽訂的是固定總價合同，或者政府的包乾合同。你被選擇是因爲價低者得，甲方會確保你的交付物滿足了事前約定的要求。而這其中至少有一半的需求，並沒有商業價值。你是無法糊弄甲方項目經理的，他是位alpha職場人，保證你會交付所有的特性:(
