Scrum不仅仅是一套具体的实践，确切地说更为重要的是这个框架提供了透明度并给出了“审视并调整”的机制。Scrum通过让影响产品负责人 (Product Owner) 和团队 (Development Team) 效率的机能失调和障碍变得显而易见，使它们得到及时处理。比如，产品负责人可能不清楚市场情况、特性或如何估算它们的相对商业价值。亦或者团队可能对于工作量估算或开发工作还不够熟练等。
Scrum框架会迅速揭露这些弱点。Scrum并不能解决开发的问题，只是让问题都赤裸裸地显现出来，并为人们尝试用短周期和小改进试验来解决问题提供了框架。
假设团队因为任务分析和估算技能不佳，而不能交付他们预期在首个Sprint完成的工作。对于团队而言，这是次失败。但是实际上，这是个必需经历的第一步，以使得团队对于以后的预期更加实际和周到。Scrum的这种模式使得机能失调显现出来，让团队能够及时处。正是这种基本的机制带给了使用Scrum的团队所能经历到的最大好处。
一个常见的错误做法是当使用某个Scrum实践遇到挑战时改变Scrum。比如，团队交付有困难，他们可能决定延长Sprint，那么时间永远都是充裕的，并且在这过程中确保自己永远都不用学习如何更好地估算和管理时间。这样，没有经验丰富的Scrum Master的教练和支持，这个组织的Scrum就会蜕变成只是其自身弱点和功能不调的镜像，并且破坏了Scrum所能带来的真正利益：也就是使得好坏都显露无遗，给组织提供自我提升的机会。
另一个常见的错误做法就是假定某个实践是不准许或禁止的，只是因为Scrum没有明确地提到。比如，Scrum没要求产品负责人为产品制定长期策略，也没要求工程师对于复杂的技术问题向经验丰富的前辈讨教。Scrum将这些都留给相关的个人来做正确的决定，在多数情况下，以上两个实践（和其他一些）都是特别推荐的。
还有一个需要注意的是管理者强制团队使用Scrum。Scrum提供给团队空间和工具来自我管理，这种从管理层强压下来的命令并不是取得成功的方法。一个比较好的做法就是让团队先从同事或管理者处了解到Scrum，进行全面的专业培训，然后由团队决定在一定的时期内忠实遵循Scrum实践，在该时期结束时团队将评价其工作经历，再决定是否继续使用Scrum。
虽然首个Sprint通常对于团队来说是极富挑战性的，但值得庆幸的是在Sprint结尾时Scrum带来的好处就会显现出来。所以很多新的Scrum团队都惊叫：“Scrum太难了，但是比起我们以前的做法它简直是太好了！”
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用。你还可以使用@来通知其他用户。