Reference: Clinton Keith, Agile Game Development with Scrum, Chapter 14.

Scrum doesn't work miracles and has no magical properties. In order to improve development with Scrum, all involved must understanding its underlying principles. Scrum is a framework to build a process that supports talent, great teams, and leaders, but it does not replace them.

Myth: Scrum will solve all the problems for you. If there are underlying problems, Scrum will expose them, not solve them.

Myth: Projects using Scrum always ship on time. Scrum helps you measure velocity against the goal and know what is possible early on in the project, make the right decisions and commitments, and then monitor and progressively refine those decisions.

People use FUD to sabotage the adoption of agile software practices. Change alone creates FUD; it threatens the status quo and therefore a person's security in their position. Sometimes the memory of past successes creates the belief that the practices used then will continue to apply equally as well in the future. Problems are seen not with the process, which has proven itself, but with the developers using it now.

Myth: Scrum is just endless development; agile teams never plan, they just iterate without a goal. Waiting for the game to emerge as a result of iterating without a plan leads to last-minute scrambling and overtime and creates an iterative and incremental death march.

Myth: Scrum is just another management fad; it will be replaced by something else next month. "Agile will go away, but it will most likely go away in the same way discussing the merits of object-oriented development went away. Agile will eventually become the accepted way of doing things, and it will just be what we do."

Myth: the double standard - Scrum was either successful, or the project failed because the team didn't use Scrum correctly. Teams succeed or fail because of many factors: technology, capability, vision, communication, collaboration, talent, or even the underlying idea of the game. Scrum doesn't prescribe what to do when sprints repeatedly show the game isn't fun or the velocity of the team is low.

Myth: Change is bad because our process has worked in the past and if we change things, we'll fail. An existing well-established process is always reinforced by its strengths and weaknesses. Changing core practices is always more challenging than adding a quick fix. The problem is that quick-fix practices become a normal part of a development.

Myth: Scrum consists of nothing but endless meetings. Most meetings (sprint planning, review, retrospective) occur once per sprint, except for daily scrum meetings, which often do not need to be longer than 15 minutes.

Scrum as a tool for process and culture change. Somewhat counterintuitively, Scrum is not a process; it is a framework for creating and evolving your own process. It can help any organization create transparency, which enables commonsense change. Scrum is great at supporting continuous evolution of the process because it provides a clear infrastructure and metrics.

Scrum is about adding value, not task tracking. Many traditional software engineering methods focus on the completion of specific tasks that comprise a feature. Scrum focuses on a feature's emerging value and the impact on the tasks for that feature, but not on the completion of the individual tasks.

Status quo versus continual improvement. Scrum's approach to change: a) make small, reversible steps, and b) make sure that any perceived improvement is real.

Cargo cult Scrum. Simply following a set of practices isn't enough to bring the full benefits of highly productive teams. Teams need to understand the principles behind the practices and improve those practices to best fit their product, people, and culture.

Scrum is not for everyone. Many companies can find ways to accommodate the individuals who are not able or willing to work in an agile environment by creating special roles for them, but in many cases they eventually leave.

Overtime. Scrum neither encourages nor prohibits overtime. Teams need to discover their own pace, but the management needs to have strong policies concerning overtime. If a team decides to work overtime, they do it as a team.

Crunch is an extended period of enforced overtime. Many studios that are new to Scrum continue to practice it until the empirical measure of velocity demonstrates its futility. Team velocity may increase early during crunch, but most likely (because people get tired) it will fall below the pre-crunch (normal) levels very soon.