Scrum不是流程，它是提供給團隊可視性的框架，並且容許他們相應的“檢驗和適應”的技巧。Scrum試圖讓許多存在於開發團隊中的問題顯示出來。比如，大多數的開發團隊並不擅長於計算在固定期間內完成的工作量，因此在第一個Sprint結束時不可能交付他們預計完成的工作。對於開發團隊來說，這個是工作的失敗。事實上，這個經驗正是能更好預計工作量所需的第一步，並促使其對承諾的任務更加負責。這種模式可以使機能失調更易顯現出來，讓團隊切實可以解決問題，是實用基礎的技巧產生出最有意義的收益，是團隊實用Scrum的經驗之一。
一個開發團隊普遍犯的錯誤是當他們在Scrum實踐中遇到挑戰，他們會改變實踐方法，而不是改變自身的問題。比如，開發團隊有困難完成Sprint任務時，會延長Sprint的週期，這樣會破壞了Scrum真正的意義：使優點和缺點都顯示出來，給開發團隊自我的提高提供機會。
另一個普遍存在的錯誤是人們意味某一實踐方法是被禁止的或不提倡的，只是因爲Scrum沒有明確的提出此方法。比如，Scrum並不特別要求產品所有者對於他或她的產品作出長遠的目標計劃；也沒有要求工程師請教更有經驗的人員關於比較複雜的技術問題。Scrum將這些問題留給個人作出正確的處理；在很多情況下，以上兩個方法會被建議。做個比喻吧：“Scrum沒有提出早餐的問題，難道你要餓着？”
另一個需要注意的問題是有時候經理會強制開發團隊使用Scrum；Scrum是爲開發團隊提供自我組織的空間和工具，由上層強加於開發團隊恐怕不是取得成功的良方。比較好的方法是讓開發團隊從同事或經理處瞭解到Scrum，並通過專業系統的培訓，在開發團隊實驗此方法後作出決定。