Common pitfalls using Scrum methodology

While reading a Gamasutra article about common pitfalls of using Scrum in game development, few of them looked familiar to me (I've worked with "real" and "apparent" Scrum in different projects for more than a year) , so I'll be listing here those which I have something to say about along with my point of view.

No design document needed because the backlog spreadsheet replaces it

I've suffered having no design documentation apart from unit & functional tests documents until the end of the project, and the commercial proposal (which incudes tech specs but not as detailed as developers would want sometimes).

While this can appear to be good, having to "remember" or "ask the customer" for specific features or a requisite can slow development. Also, it is better to do documentation as the project goes on, and not having to remember everything at the end.

Interrupt what people are doing to have them come to the daily 15 min. meeting

Discipline is good, but when developing, sometimes you're in the middle of something, or just came up with the solution to the problem you've been struggling with last four days. In those cases, interrupting can be annoying.

I think that balance is the key: Meetings should be at a scheduled time, but with the option to delay it a bit if the reason is valid.

Not doing something because it is not in the backlog

I haven't faced this one because we've always added new tasks both to the backlog and to the current sprint if we thought necessary.

Also, as the Gamasutra article mentions, this can make the developers feel like working on peaks: Now I've got work, now I don't. It is better to have a steady rhythm of work along all the project.

Start managing stories and sprints before all the people are on the team

This is the worst one. Once, I faced having all the project planned before even knowing what do I was supposed to do. I had to choose tasks I didn't knew what they meant or what time would take, and even estimate them. As a result, we had to re-arrange tasks in sprints almost every three weeks.

Remember: If you're not going to develop something, ask who is going to develop it at least for advice.

Daily meeting becomes a each person give a status report

I have seen this too. Although the time spent was lowered to near 5 minutes, I see no use on just telling "I've finished this" if you have the scrum spreadsheet and can look at it anytime. Make the meetings useful for the team, or skip them.

Make Scrum mandatory

I'm always a bit "rebel" with rules. They are good while they are useful, but imposing something for everything just because "you must follow it" is nonsense.

In one project we were supposed to follow scrum, and we ended switching to Extreme Programming (with small adaptations too ;) because we were two devs only and it was quite faster to do things like pair programming.

Implement only X weeks of work based on what you currently know about the design

False! "Plan in advance". It is fundamental! For example, if you develop a Windows Live Agent without planning how the agent will interact with the Activity Window, you'll end having to modify code and re-arrange it to adapt to the Activity's asynchronous mechanics.

Start managing the project by prioritizing tasks and asking time estimates before the design document is written

Wrong. As I said before, if you don't know what you're going to do, how can you estimate it correctly?

Spend time writing the design document, then estimate and prioritize.

So, in my opinion, take Scrum as it is, a methodology. If something doesn't fits with your team's daily work habits, or if something instead of improving the quality/speed/organization will impede it, skip it.