Search

Tuesday, July 15, 2008

Feedback: "Top 10 Pitfalls Using Scrum Methodology for Video Game Development"

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.

8 comments:

Jobe said...

Hey Clinton, long time lurker on your blog, its had some great stuff that helped with my first experience with Agile/Scrum/XP. Keep up the great work!

Anyway, nice analysis. I am tempted to cross post my own, but I think anyone interested can read it themselves on Gamasutra.

Rory McGuire said...

Clint,

Good analysis. I think my personal takeaway from the original poster's point is that SCRUM is not a magic bullet, if you have a bad team or a bad set of management, they will not become a good team using SCRUM.

I don't want to judge without knowing the circumstances, there's very little information in the author's bio but many of the points such as "Make SCRUM mandatory" (Which deals with management feedback) and point 7 regarding a team member running out of tasks and having to jump through hoops to get work done just set off a ton of red flags.

Those are management failings and have almost nothing to do with scrum or waterfall or anything in between.

Hope things are treating you well, Clint.

~R

Nat said...

Maybe this is more of a people question and less of a scrum question but how do you deal with a situation when another employee is the impediment? Naturally in a scrum meeting, one employee may not want to call out another employee in front of others. Nor would that be the best way to deal with that situation (drama!). And it isn't really an issue of commitment. The team member "completed" a task but perhaps so poorly or just neglected how it affected the other members as to cause impediments.

This blog is an excellent resource!

Clinton Keith said...

thanks Rory and Nat!

Nat,

It's hard to say what the solution is this case. Ideally a fully collaborative team will be able to address these issues without it being confrontational, but rather an opportunity to mentor the poor performer. A good book to read on team formation is "The Five Dysfunctions of a Team: A Leadership Fable"
http://www.amazon.com/Five-Dysfunctions-Team-Leadership-Fable/dp/0787960756/ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1216692925&sr=8-1

Dave said...

I disagree with the original article's contention that scrum meetings which are just a set of status reports are a waste of time. When things are going well and nobody is blocked on anything, the team still wants visibility on what everyone else is up to. You should also choose the right rate for meetings for your team - there's nothing sacred about them being daily.

The most important thing we have learnt about Agile and Scrum is that you have to adapt your process to your team. If you follow the process too religiously, you've missed the point.

Clinton Keith said...

Agreed. I also feel that hyper-productive teams are always pushing the limit of what they can do.... a team that doesn't have any problems for awhile might need to push itself a bit more.

Thanks!
Clint

Caresse said...

Hi Clint,


I am a project manager at a graphic design firm that is considering the scrum methodology. I am researching the method and want to know - where do I fit in with all of this? What is the best way that I can be an asset to the team with this process?


Thanks in advance.

Clinton Keith said...

Hi Caresse,

This is a common question. The answer is that it really depends on what you do now, what the team needs and what the product needs.

One thing I like to do with PMs/Teams is have them identify every one of their individual duties and decide who can do them and if they are needed. This is revisited from time-to-time as teams gain maturity and take over more themselves.

Often teams find a dividing line of what they can do and what the PM should do. As a former PM, I found this liberating (much of the daily fire fighting was solved by the teams) and actually went back to writing more code, which I enjoyed greatly.

I hope this delayed reply helps!