曾經參加過大師91 Chen的講座，他提到：『現在在外面做scrum教練已經很難了，原因有二，一是有很多人認為Scrum不適合我們，二則是其他還有更多人認為我們現在的scrum經過我一翻修改後已經超棒棒了，我不需要什麼教練或mentor。』

筆者感同身受，其實，在台灣的業界，大家(尤其是技術出身，現居要職的那些『大佬』們)都很喜歡拿著自己的信念，去學習新的技術或觀念，然後搞出一套自己覺得好棒棒的『玩意兒』，並稱之為『我們門派的____技術』，然後讓手下人照著做。

隨著資訊發展與迭代速度越來越快，這件事在最近的10年內最明顯。譬如有些人用SVN習慣了，於是拿著以前SVN的那一套，融合了Git的某些特性，發展了專屬於自己的一套『GitSvnFlow』;有些人用傳統網站模式習慣了，即便引用了專為MVC或是RESTful設計的既成框架，也還是要把其中的某幾塊特意拆掉，換成自己習慣用的技術；而在流程方面，有更多更多的Waterfall專家，在引進了scrum流程框架以後，硬是要把其中的一些流程，抽換成自己喜歡的樣子。

譬如，我還是一樣在scrum，還是一樣sprint，但是我有5個部門：

1. 企劃部花一個sprint企劃
2. 設計部花一個sprint設計
3. RD部花一個sprint寫程式
4. QA花一個sprint測試
5. RD和QA再多花一個sprint來回驗測與修正

『多聰明如我，設計這樣的scrum，企劃部第2個sprint開始又可以企劃新案子了，整間公司就像pipeline一樣，大家維持一模一樣的節奏，都沒有人很閒，棒呆了！』

唉唷，我的老天鵝啊！

我記得在以前的文章中曾經不止一次說過，scrum框架裡的流程可以置換，但是不管你怎麼置換，都不可以違背敏捷精神。上面的『變形式scrum』問題出在哪裡？

關鍵在於，Waterfall的中心思想在『每個人都是這台大工廠裡的螺絲釘，你只要做好份內工作，其他事你不要管。』而上述的流程正好穩穩當當地落實了這個中心思想。這麼說吧，還記得我們聊scrum時都會聊到的『最小可行性商品』(MVP)嗎？都不要看別的，就算上面的步驟每個人都把所有事情案時間做完也都好棒棒地沒有任何閃失，客戶最快最快要多久後才能拿到產品？答案是10週，也就是兩個半月。然後他拿到了一個『完整商品』。

『完整商品有什麼問題嗎？』沒有問題啊！只要你能確保你做出來的事100%他想要的，那就完全沒有問題。要知道，大部分的情況下，客戶其實不太知道他自己要什麼，即使知道也形容不出來，即使形容得出來你也不一定懂，即使你懂了RD也不一定能做出你要的樣子，即使做出你要的樣子也不一定跟客戶當初想的一樣，而最慘的是，即使跟客戶當初想的一樣，也難保客戶在這兩個半月中沒有改變心意。

這就是為什麼我們每兩周就要拿出一個『最小可行性商品』來給客戶看，以減少(當然不可能完全消除)上述的那些壞情況發生呀！

Waterscrum以各式各樣的型態在業界流傳並發生著，我不能說他們不好，它們會被這樣設計一定有他的理由與考量，只是，我們必須退一步來看，他是否有符合敏捷精神。如果有，那其實是很OK的，萬一沒有，也不能說你的老闆錯，只能說『這樣並不敏捷』而已。

最後，敏捷保證成功嗎？不，沒有人能保證你成功，找到最好的、最舒服的方式，帶領團隊往前(錢)走，才是成功的唯一定義。