往往在團隊接觸SCRUM一兩個月後，在自認為對SCRUM的方法和流程已經足夠了解後，容易犯下幾個小錯誤。但如果不能夠及時加以糾正，將可能導致更大的錯誤。以致阻止SCRUM或者其他敏捷的正常實施和組織的順利轉型。

誤區一： 越頻繁變更越彰顯“敏捷”

進入這個誤區的人不在少數，大多數認為“快”就是敏捷，SCRUM中的Sprint週期如能縮短，團隊將會更加靈敏；有些業務分析員，一邊“享受敏捷的禮遇”，一邊工作“開著小差”，覺得自己隔三差五給團隊個交代就可以了。於是，想到哪裡設計哪裡，也不和客戶保持經常的接洽，更不會去管理客戶需求，所以是客戶說的，無論是成熟與不成熟都扔給開發團隊；這導致了產品三天一小改、一星期一大改；這樣的“SCRUM”開發模式把團隊完全被弄蒙了，還沒等團隊沒明白過來怎麼回事，就被教育“進入下一個迭代了”，一邊重複工作著，一邊被教育越“快”就是越“敏捷”。這種做法顯然可笑，因為敏捷的增量型遞增模型完全就不存在，團隊變成了“無頭蒼蠅”。

不得不指出，這種現象尤其發生在網際網路行業；這個行業的客戶其實就是普通大眾，而一半大眾到底稀罕什麼、另一半不稀罕些什麼是經常發生的事情；例如說針對網頁中的“動畫Flash”，如果詢問使用者，差不多喜歡和痛恨Flash的一半一半。如果你不仔細分析和觀察這類普通大眾的需求，很有可能今天加一個，明天再去掉一個動畫，並且開始爭辯哪種方式最好。這樣，既浪費時間又耗費團隊的精力。

實際上，我們仔細分析，這類痛恨Flash的使用者，是不喜歡使用不當的Flash，那些大而複雜的動畫，下載時間長，還沒有興趣完整的看完的動畫；設計不可避免變更，但絕不要用“縮小迭代週期”“短頻快”的作法來遮掩設計的缺陷。

所謂“武功唯快不破”的那只是小說。