在一月份的 AgileCommunity.tw 的聚會中，Shawn 談到他們公司不敏捷的敏捷經驗，引起廣泛迴響，而當天最後一位五分鐘分享者也表示她主要想來問問大家，用敏捷到底對解決他們專案的問題有沒有幫助。當時 Shawn 問我有沒有什麼好建議，我說我待過的新創公司也碰到同樣的問題，而我也沒有什麼好方法。然而經過聚會的討論後沉澱、以及會後在網路社群意見的交流之後，讓同人能夠更完整而清楚地思考為什麼敏捷沒有效。
對於用 agile 到底可不可以解決時程拖延的問題、可不可以讓專案順利出貨、以及產品大賣；簡單地說，就是 agile 到底有沒有用，是不是萬靈丹？David Ko 提到「沒有銀彈」，他認為對 agile 來說最棒的事是給予回饋使人們可以儘可能早日發現問題，但它不會告訴人們該如何去解決問題。當然可以從 agile 方法或實務中選擇可用的工具來解決問題，但那些工具不見得是最佳的工具，我們不應該被工具所框限。
喲哪桑也認為Agile 不是 Startup 的銀彈，他提到：
照 Lean Startup 的講法：Startup 要解決的問題是未知的，顧客也是未知的，找出問題開發顧客才是 Startup 的難題，例如那位產品賺不到錢的觀眾， Agile 只是幫助「建造」出顧客需要的方案，找出問題開發顧客，就可能不是 Agile 所能幫妳解決的了。
David Ko 和喲哪桑的觀點都指出 agile 不是軟體開發的銀彈：它可以幫助人早日發現問題，但卻沒辦法解決對問題無知的問題。如同另一位學長 Simon Su 在會後分享他對 Shawn 的簡報內容的感想所指出的：敏捷不起來不是新創公司在敏捷的失敗，而是商業模式的失敗。他提到敏捷方法不是新創公司失敗的根本原因，只是公司最重要角色的觀點會認為商業模式才是關鍵成功因素。他推崇 Shawn 說的「選擇適合公司的流程」，而敏捷只是方法之一，此外，Simon Su 還引用《Scrum in Action》的觀點提醒以組織、基礎建設、團隊、技術、流程、業務等六大面向來評估敏捷在公司是否可準備就緒。
敏捷的採用、調適、與熟練
Simon Su 的觀點指出了一個重點，那就是新創公司不敏捷的敏捷經驗並非採用 agile 應用在不正確的商業模式下，縱使經營者或是出資者可能認為關鍵成功因素在商業模式而質疑開發者努力在不對的事情方面。而是因為沒有將已知的方法加以調整，使它適用在可能的商業模式上，然後讓成員能夠純熟地操練並應用而獲得預期得到的效果。
這正是意味著敏捷能不能救的了你，並不是你有沒有用 agile 或 scrum 的方法及實務來開發產品，而是你對自己的問題和處境了解多少？能不能在企業價值和技術風險之間保持穩定的平衡狀態？如果可以，你不用執著於 agile 或 scrum 的方法論都能夠敏捷，因為即使在面臨高度壓力的情況下，你都能夠臨機應變地迅速反應變化。否則，敏捷都只是方法論的名稱而已，執著在 agile 及 scrum 的名相之中，你只是被限制在敏捷的框限中，但沒有順著心意去做事，所以並不敏捷。
因此同人認為敏捷不是萬靈丹，它能夠解決的問題是有限的；至少你必須先要認清問題是什麼，才能試圖用敏捷的修煉－即敏捷三部曲：adopt、adapt、adept 的過程這三部曲最早是由點空間的 Peter Ho 提出來的。，而非將它當成銀彈或是呼名大法的神話－來解決它。然而，雖然我也覺得想用 agile 挽救產品的失敗，這真的是搞錯方向，但對於有人提到 agile 適合在既有成功的商業模式下做流程改善的觀點卻不能贊同。
因為所謂的「適合」或「不適合」、或是所謂的關鍵成功或失敗因素，這些都只是事後諸葛可以找到失敗的理由，但卻不能在事前為成功找到方法。然而事實的真相往往是沒有人知道有沒有或什麼才是成功的商業模式，大家都在摸索中成長，因此斷言要做什麼或是如何做才正確，其實可能反而是適得其反。經常人們在抽象概念上認知適用的方法，在真實世界會遭遇到現實因素而完全行不通，原來所謂的「適合」或「不適合」只是人被情境迷惑的一種假定，實際上會因為無法預料的變化而使事物的發展全然改觀。
因此，方法本身本來就沒有不適合的問題，關鍵反而是人在不諳情勢的情況下採行對事情沒有幫助的舉措，當人們沒有意識到它，在敏捷之前就不大可能事先前饋、然後以回饋調整與演進過程、再事後追踪問題是否得到改善，於是錯失因應不同條件搭配而調整的機會、慢慢地，理論和實務的落差變得愈來愈大，成員沒辦法在實際的工作上勤訓苦練，來讓使用方法的技藝能達到純熟與提昇能力，於是當面對更複雜的問題時，不能有效溝通只有做事不明究裡而招致官僚釀災。
為什麼沒有認清問題？
換言之，採行敏捷並不能挽救產品開發失敗的命運，這並不是敏捷方法或實務不適用在新創公司的商業模式上，而是開發者沒有認清必須要解決關鍵的問題是什麼，以致他們的敏捷無法調適和熟練而發揮效果。那麼開發者為什麼沒有認清問題的關鍵，是不是因為能力問題還是他們根本對開發的東西不熟悉？就同人的觀察，我看過新創公司敏捷失敗的案例，開發者的能力都是一時之選，而且對他們開發的產品都有相當的瞭解，但問題就因為專注在能力和知識，強調在專業和技術等內部觀點的創新，卻忽略了一般性的外部觀點。
什麼是外部觀點？在《再想一下：好決策的關鍵思考術》這本書提到人有偏好內部觀點多於外部觀點的傾向，它是人腦常犯的幾種錯誤之一：
內部觀點以聚焦在特定任務及垂手可得的訊息來思考問題，並依照狹隘和獨特的訊息做出預測。這些信息可能包括傳聞證據或謬誤的看法，但這是大多數人在建立未來模型所使用的方法，而且確實也常見各種規劃型式中。
外部觀點要問的是，是否有類似情況可提供統計的基礎，以便做出決策。外部觀點不看問題的獨特性，而是想知道有沒有其他人遇到類似的問題；若有，結果是什麼？這種外部觀點是一種很不尋常的思考方法，人們在這種觀點之下不得不把搜尋到的寶貴資訊擺到一邊去。……外部觀點通常可為決策者創造出一種極具價值的實際驗證。
這本書提到社會心理學家區分出三個會導致人們接受內部觀點的假象：優越感的假象、樂觀的假象、控制的假象。這三種假象正合乎同人看到新創公司敏捷失敗的觀察，因為對自己太有自信、對情況太過樂觀、以為一切都在自己能力控制範圍之內，於是不會去傾聽別人的意見，導致一意孤行而不去溝通、調適、以至於熟練內化技術融合問題領域的能力，同人看到敏捷失效乃是因為沒有貫通敏捷的過程，不單只是執行一系列的方法或實務，更需要去發揮個人的創意與價值，它們是比流程方法更為重要的關鍵。
理想 vs. 現實
一般而言，加入新創公司採用敏捷開發方法的開發者會比一般人更有理想和抱負，他們對工作充滿熱情而且表現積極的態度，希望藉由達成願景而實現他們的理想世界。為未來理想而努力是為了創造某種改變，然而當我們不把心力投注在對現存事物的認識，理想其實沒辦法造成任何改變，因為察覺不到現在，未來也不會有出現的時候，而只會讓我們對現況不滿的反抗與掙扎，一切紛擾都只是反抗的反作用力而已。
同人從克里希那穆提對教育的觀點來得到敏捷沒有成功的啟發：理想或完美烏托邦藍圖的沒有成功，是因為沒有人的內心沒有徹底改變；理想不能改變既存價值觀的改變，惟有藉由正確教育以培育對「現在存在事物」的了解。
當我們為了某個理想，為了未來而努力，我們是按照對此未來的概念而塑造個人；我們對於人一點也不關心，我們關心的只是「人應該如何」的這種想法。對我們來說，「應該如何」變得比「現在存在的事物」－－換句話，就是個人和他本身錯綜複雜的問題－－更重要了。如果我著手於直接了解個人，而不要透過我們想的「他應該如何」的布幕來看他的話，那我們關切的便是「現在存在的事物」了。這時，我們便不再想要改變個人。我們關心的只是幫助他了解他自己；沒有私人的企圖或利害關係。如果充分察覺到「現在存在的事物」，我們便會了解它，擺脫了它的束縛而得以自由。因此，要覺察到真正的自己，我們必須停止想要成為他人的掙扎。
理想在教育中並不重要，因為理想妨礙對「現在」的了解。顯然地，唯有不逃避
未來現在照書的上下文意來看，此處應該是現在不是未來，可能是出版時沒被勘誤到的錯誤。，我們才能覺察到現在存在的事物。轉向未來，追逐理想，表示心智的怠惰，以及一種想要逃避現在的慾望。～張南星譯（1995），《人生‧教育‧學習》，p.24 ~ p.26，方智。
在敏捷社群當中，我想最多人第一件談的事情就是理想。當然，有理想決不是一件壞事，它讓人們有創造的意圖，去創造讓更美好的事情發生。然而，同人發現這當中最引人迷惑的字眼就是「偉大」（Great）這個字。我的意思不是說敏捷有理想不偉大，但它的偉大不意謂的比他人更好，而是都有他們可以發揮偉大的地方。因此，同人認為當我們向別人宣稱敏捷開發的偉大理念時，小心不要被自己遠景的理想所迷惑，而逃避或忽略現實，掉落到優越感、過度樂觀、以及一切都在控制中的假象。
我看到的不敏捷的敏捷
同人過去在新創公司開發產品的敏捷經驗就曾看到這三種假象。那時候公司的總經理是居住在美國的台灣人，他在美國完成學業並且創業成功，回台灣開公司希望能幫助國內軟體產業升級。他提出公司的願景是要成為最偉大的軟體公司，當時我們的主要競爭對手，財力和資源都比我們公司雄厚，但我們的表現卻一直超越他們。總經理認為除了歸功於成員的努力之外，更重要的是我們工作講求方法。當時我們採用 scrum 的 daily stand-up meeting 和以看板呈現任務狀態等敏捷實務，他告訴成員要用 Keep it Simple 的態度來工作，工作不一定要講求快速，但一定要講求一開始就做對。
在和這位老闆互動的過程中，同人發現他的文化優越感常讓他看不清楚現實，而只關心別人是不是按照他的理想去做事。他對產品的規劃，很少讓實際實作的人員參與產品規劃的過程，通常是他和高階經理私下討論後，才開出規格讓開發者開發程式。在感覺上他似乎認定只要成員把他的東西做對了，就沒有問題，但他卻很少考慮到要檢視他的東西是不是對的。同人曾經建議他要注意開發過程缺少驗證需求，但和他討論下來，我發現他把軟體開發看得太簡化，樂觀的態度讓他對軟體工程的 V&V 觀念茫然。
當我們開發的產品交付到客戶端時，發生很多非常嚴重的問題，總經理對問題的反應是歸咎於我們沒有把 code 寫對，加上 QA 又測試不到有問題才會讓我們處境艱難。他質疑我們為什麼不一開始就把東西做對，而要出了問題才知道要修正程式或設計？他以為這是台灣的工程師不如美國人做事有系統和嚴謹，認為我們做事沒方法才會遭遇問題層出不窮的問題，不過這顯然是只思考工程技術觀點的狹隘視野，沒有察覺社會技術觀點的影響因素。
有一次他和 QA 經理找同人討論問題，他講到目標是做對事情，同人反問如何定義做對事情這件事？這時 QA 經理向總經理說，做對事情這句話有問題，因為沒有絕對的正確，而只有相對的正確。後來同人和 QA 經理都離開了那家公司，據聞只有聽他話做事的人會留在公司，其他比較有主見的同事也都離開了，同人不知道這是否就是那位聰明的老闆曾說過，他所揣摩出來磨合東西不同做事方式所發展出來的領導風格，但這顯然是他被控制假象所迷惑。
同人認為他是精明的美國人，從西方教育的訓練讓他有很強的邏輯數理能力，但以台灣人的出身卻沒能體會到東方文化的智慧精髓。簡單地說他是一個崇尚西方科技文明重視直線思考、強調個體的力量，卻不諳東方重視關連的思維，不知道力量來自於整體關係的平衡。同人常常看到他為了表現個人的力量而破壞和團隊成員之間的關係，為了捍衛自己的主張，經常會提高音量來斥責他人，甚至拍桌子而把氣氛弄得非常緊張，事後他會表示他「對事不對人」而不以為意，但這種互動模式嚴重地影響他和團隊成員的關係，引發情緒問題讓問題更顯得棘手。
面對現實才能敏捷
同人上面的經驗，讓我沒辦法同意喲哪桑說做「Great Product」不一定可以賺到錢是迷思，聽到「偉大」兩個字讓我感到不安。同人知道學長不喜歡寫文章和人爭辯，但即使我的觀點不受歡迎，我也應該表達清楚我的不安：我們不能因為個人偏好的價值判斷，而忽略對問題的客觀思考與分析。
其實敏捷不是追求理想的方法，而是認清現實來擁抱改變。當人對理想的堅持而落入價值判斷，因為沒有認清現實而一意孤行，理想並不會改善現狀，而會帶來不明智反抗的反作用力。同人以前的文章曾經提到過，敏捷社群有人曾批評瀑布模式並不是成熟的軟體開發模式，同人當時表達瀑布模式和敏捷開發模式所要解決的問題、以及面對的客戶是不一樣的，因此評定瀑布模式比其它模式不成熟，那不是成熟而是幼稚。有趣的是同人的回應引起了某人在人後道長短，他批評我露餡的舉動，也正是落入自以為優越的假象，而認識不清自己，已然在我及我的讀者面前露餡了。
當然，人對理想懷抱熱忱是好的，它不是錯誤的想法。但為了堅持主觀的理想而忽略外在條件的客觀因素，這決不是敏捷的明智作法，代表出了問題而需要調整作法。只是個人思考的內部觀點優於外部觀點的傾向，人的非理性會迷惑於優越感、樂觀主義、以及控制慾的迷霧而讓逐漸失去理性。當每一次人因為相信獨特性而認定成功在望時，從另外一面的共通性來看，失敗的心態都沒有太大的不同－相信方法可以讓人掌控事物的發展而表現出過度樂觀的態度，卻走不出對問題和人認識不清而遭致失敗的命運。如同愛因斯坦說過的「精神錯亂」：一次又一次地重覆做同樣的事情，卻期待得到不一樣的結果。
敏捷為什麼會沒有效？同人以為不是因為敏捷不適用，沒有依據現實環境來調適敏捷方法及實務、或是沒有讓成員熟練調適過的流程，都會導致敏捷的失誤。然而再大的失誤都比不上忽略外部觀點的優越感、過度樂觀、和認為一切都在掌控中的心態作祟。敏捷不需要依賴技術、效率與控制，而是重視關係的相互信賴、整體協調與參與促成良性互動，因為後者會讓人回到外部觀點的具體和客觀，它們比前者更能發揮較大的力量。
