「給我這個酷東西，我們來搞敏捷吧！」—> 高機率得到壞結果
「我們來解決問題吧！」—>有可能成功導入敏捷，就算沒有，也解決了問題

記得過去的日子，曾經我們所有團隊各個角色聚在一起，聽了關於敏捷以 Scrum 的介紹，當時我覺得這酷東西真棒，團隊也是依照這樣的框架持續運作，我想著我們一定可以做出成功的產品，未來應該會像獨角獸新創一樣閃閃發光吧！但一年後，我們的產品賣不出去，公司也倒了，這個故事是否太黑暗，但其實後來再次回顧過去新創公司的一切，突然發現不會倒才奇怪（？
以下就針對敏捷以及產品開發面向，跟大家分享這個失敗經驗。

導入敏捷後反而看不清問題點

如同文章一開始說的，我們導入了敏捷這個新框架，但好像變成為了跑scrum而敏捷，卻忘了去探索目前我們要解決的問題是什麼，所以每個sprint 好像很快速的交付了東西，但這些功能卻很發散甚至讓產品長得奇形怪狀，然後新功能上線後，客戶跟市場就很有感了嗎，答案是沒有，甚至衍生出很多bug，導致客戶不爽、業務不爽、專案經理不爽、CEO發飆、開發團隊沒有成就感。所以我們要看到的問題或痛點到底是什麼？我們交付的新功能有解決這些問題嗎？這些看似簡單理所當然的問題，我們當時似乎在 Scrum 的速度感中迷失了，而忘記要花時間在這些最核心的根本上。

我們的roadmap 很敏捷

常有人說敏捷帶起了速度感，減低很多時間成本，如果是用在開發與流程上我不反對，但我們的敏捷卻是隨時可能變動的 roadmap (因為謎之音說市場變化很快，所以我們也要隨時調整方向)，而這也會進一步導致需求與開發隨之變動，像是上次才release的功能，現在不推給客戶了，或是這個功能頭都洗一半了，突然說不幹了而且要把頭砍掉，於是這樣的敏捷讓各個角色變得很困擾；業務賣出去的東西，突然回過頭發現已經不一樣了，不如什麼都賣什麼都不奇怪？開發團隊發現花了幾個sprint 好不容易推上去的大功能，原來沒有什麼價值。這一連串的過程會帶來背叛感、不信任與無力感，然後最後大家在一個恐怖平衡下虛弱地維護著產品。

以上兩個原因其實帶我們走向了消亡，但這其實只是冰山一角，下次等我翻起回憶錄時再跟大家繼續分享！