很多人都聽說敏捷，有些人知道敏捷是什麼，有些人也嘗試過敏捷，本章中將列舉出一些常見的錯誤敏捷實踐，如果想要避免敏捷失敗，建議還是要對照下你所在的敏捷團隊中有沒有類似的敏捷實踐，這對於你的敏捷成功是很有幫助意義的。
-
敏捷錯誤實踐一： 沒有或者糟糕的項目回顧會
回顧會的目的在於總結和發現問題，一句話——繼往開來，團隊中的每個人都可以想一想在過去的這個迭代衝刺中，哪些方面做的很好，哪些方面可以做的更好，哪些方面做的不足，從中我們可以吸取哪些教訓，如果迭代回顧會無法做到這邊方面，那麼我們稱這樣的回顧會是無效的。
-
敏捷錯誤實踐二： 糟糕的PO(Product Owner)
PO 應該深切參與敏捷中的每個重要環節：每日站會、迭代回顧會、迭代計劃會，當然了PO並不需要參與到迭代計會中的任務劃分，迭代計劃會中的任務劃分是項目團隊的工作職責。PO要負責按業務價值對積壓工作項—backlog進行任務優先級劃分，比如，定義業務計劃、產品發佈路線圖，爲項目組定義清晰的用戶故事，進行中的變更不屬於迭代積壓工作項—backlog
-
敏捷錯誤實踐三： 糟糕的敏捷教練
敏捷教練不應該成爲團隊管理者，敏捷團隊本身應該是自我管理的，對於敏捷團隊來講，敏捷教練應該是引導者角色而非領導者角色。當團隊成員出現分歧時，敏捷教練要負責做最終決定，敏捷教練應具備識別團隊障礙優先級的能力，並且儘速消除團隊障礙，敏捷教練應確保整個團隊目標一致，並且通過不斷的改進來達到最終的目標。敏捷教練要確保團隊任務並不是由管理者來分配的，而是由團隊成員主動領取的。
-
敏捷錯誤實踐四： 每日站會耗時太長
在每日的項目站會上，團隊成員應該簡要陳述三點：昨天我做了什麼，今天準備做什麼，目前存在哪些阻塞。站會切記不能長篇大論，具體細節可以會後討論，根據實際團隊規模大小，站會不宜超過10到15分鐘。迭代回顧會和迭代計劃會同樣也應該有時間限制，敏捷會議應嚴肅活潑，輕鬆卻不偏離會議主題
-
敏捷錯誤實踐五： 錯誤定義已完成項
在每次迭代結束，迭代完成產生的軟件應該是滿足產品定義級別，因此也必須是可以演示的，話句話說，迭代所產生的軟件產品應充分測試、包括單元測試、集成測試以及必要的人工確認測試。軟件開發人員充分了解並知曉軟件測試人員的測試退出標準。
-
敏捷錯誤實踐六： 沒有團隊速度跟蹤
當整個項目團隊速度出現下降，敏捷教練必須採取一些措施來改善這些狀況，他可以通過5問法方法或者魚骨圖法來確認問題根本原因
-
敏捷錯誤實踐七： 衝刺內採用瀑布開發
在每個衝刺迭代中，75%的用戶故事100%完成要好於100%的用戶故事都完成了，但每個用戶故事的完成度只有75%，謹記：用戶故事並不屬於單獨的個人，而是屬於整個項目團隊，這個團隊包含所有的開發人員和項目測試人員
-
敏捷錯誤實踐八： 遺留過多技術債務
每次衝刺迭代中，應儘可能的避免產生技術債務，技術債務的增多則會帶來更多的缺陷，當需要重構時，應立即重構，因爲時間越久，花費的代價也就越長，BUG也應該立即處理。
-
敏捷錯誤實踐九： 過多打擾或者新增功能特性直接繞過PO
項目團隊應該全神貫注，避免都多打擾或者中斷，項目PO應負責將新增功能需求特性添加到項目積壓工作項中，並對工作項進行優先級排隊，如果功能特性比較重要，那麼團隊可以選擇在下個迭代進行交付，應儘可能的避免直接將新增功能需求發送給團隊成員。
-
敏捷錯誤實踐十： 沒有分析或者沒有文檔
敏捷並不意味者完全沒有分析或者沒有文檔說明，只是分析或者文檔的方式與傳統略有不同：它是一個持續性的過程。積壓工作項中的用戶故事應足夠清晰明瞭，確保團隊成員可以很方便的進行任務拆分和工作量評估，這也就是說，用戶故事在項目初期並不需要十分詳盡但需清晰明瞭。