Gamasutra just posted an good article by Paul Miller called "Top 10 Pitfalls Using Scrum Methodology for Video Game Development". I found it interesting. I agree with some points and disagree with others. The article highlights some misconceptions and myths about Scrum. Since they come from a person which has gone through a product cycle with Scrum, it's very useful to discuss them.
I'll start from the top:
10. A Game Design Document (GDD) isn't needed anymore because the backlog spreadsheet replaces it.
This is one of the biggest misconceptions of Scrum. Agile does not eliminate documentation or planning. It does focus more value on a working game over a design document, but that doesn't mean that we should eliminate all documentation. It just means that we don't rely entirely on the GDD alone to define what the game will be. GDDs can often become too detailed. I've seen GDDs for shooters that try to define the number of bullets in a clip for a fictional shooter. Why can't some of those things be decided while developing the game?
On the other hand we should document what we know about the game. You can't plan away uncertainty, but we should communicate what we are certain about.
I assume that by "backlog" he means "product backlog". If your product backlog is becoming too big to manage, then perhaps it is too granular for future releases.
9. Interrupt what people are doing to have them come to the daily 15 minute stand up meeting.
This sounds like the "daily scrum is about tasks" smell. The daily Scrum is for the benefit of the team and the product. If there are "developers had already been through a couple development cycles on various projects and had an established track record of working on the correct tasks and shipping products on time" then they should help mentor the others who don't have this experience.
If the Scrum is starting late, then the Scrum Master should fix that. Lateness to the Daily Scrum is an impediment because it wastes time. It's the SMs role to fix impediments.
It always amazes me to hear the argument that 15 minutes is too costly an amount of time to spend per day to insure that all 8-10 people on the team are on track. Do companies track bathroom, coffee, lunch and web surfing breaks to insure that we don't waste 15 minutes or more per day? It's not about the time. It's about the resistance to collaborate. As a former CTO I can clearly identify this issue as one which affects senior programmers quite often! ;)
8. Moving all team members into a dedicated team room or team area does not cross-pollinate with cubicle assignments in the per-discipline-organized cubicle farm.
I agree. One point is that when teams reach the proper level of collaboration, they drive this themselves.
7. A team member says "I'm not doing something right now because I was told there needs to be a task entered into the backlog and the task needs to be assigned to me by the project manager."
Teams should have total control over how they achieve the Sprint goals they've committed to. The Sprint goals are increments of value for the customer. I'd suggest to this team that:
- They don't have project managers assign tasks (that's not Scrum).
- They put the Sprint backlog on a task board (3x5 cards) and ditch the spreadsheet.
- They take control of the execution order and creation of tasks within the Sprint.
- Focus on release goals. He mentions that the team is only focused on 2 weeks. This is why there are 2-6 month releases where the team focuses on Big Hairy Audacious Goals (BHAGs).
6. Start managing stories and sprints before all the people are on the team. Decide that your Scrum stories and sprints are 100% completed months before the project even has a QA tester.
Very good point!
5. Scrum Pitfall: The 15-minute daily stand-up meeting degenerates into a daily go-around-the-table-and-each-person-give-a-status-report.
Many teams new to Scrum hit this issues and the result can often lead to managers saying "let's manage the team out of it". There was a recent post on this topic. It is very difficult for teams to achieve the collaboration to become hyper-productive. Sometime the team is not formed correctly, sometimes managers won't let it happen.
4. Make Scrum mandatory.
He makes a very good point about management feedback. One of the biggest problems I find is to get management to understand that each Sprint should show improved value and to have honest discussions about what is working and what is not. Too many times, the "work in is in progress and we'll show more value someday" pattern remains after a team adopts agile.
3. Implement only two weeks' worth of work and write only the code based on what you currently know about the game design.
I agree. Studies have shown that we solve problems best by a combined top-down and bottom-up approach. I've never been very comfortable with XP's "do just what's needed for the next two weeks" philosophy. Experienced developers will have more knowledge and can create farther reaching solutions. However, the problem is that they usually go too far. The opposite side of the problem is with programmers who only code for the current iteration and don't refactor constantly.
2. "Sprint Zero" is pre-production time.
I don't get this one. Prototyping is for knowledge. Knowledge has great value in building and refining the product backlog. I won't limit prototyping to a set number of Sprints (much less one).
1. Start managing the project by prioritizing tasks and asking for time estimates even before any GDD is written.
So what does the team do while the GDD is being written? If I know I'm going to be working on an FPS, I might want to get a camera and character controller working while the customers are trying to define the characters themselves. Perhaps there are questions that come up in the GDD writing process that would benefit from some early prototyping? This relates to #10, but it also reflects the impression that the GDD will answer all questions. If they can honestly say that the games they ship completely match version 1.0 of the GDD, then power to them. I've never seen it.
I'm also getting the impression that their product backlog is a huge spreadsheet of tasks that is prioritized and assigned up front. Tasks should only exist in the Sprint Backlog. Let the team worry about the tasks and their estimates. Estimate the Product Backlog in Story Points or Ideal Days. Don't create too granular of a Product Backlog. It becomes too difficult to manage.
I'm really glad to see such articles written. It reinforces what I've seen as a coach these past six months. The issues that teams adopting Scrum are seeing have patterns. Patterns can have solutions which can be shared.