Sunday, August 03, 2008

Scrum experience at Nokia

Interview with Scott Foe, Producer at Nokia:


You said you're using Scrum.

SF: That's the project development methodology that we've employed. You know, Scrum is - especially with the recent [Game Developer magazine] article from, I believe, last year, “Scrum Rising” - a hot topic in the games industry of late.

People have strong opinions.

SF: People have strong opinions. I definitely have my own strong opinions. It's definitely not a silver bullet, nor is any development methodology. I mean, for example, yes, Scrum leads to greater team communication and cooperation, but if one of your team members is an axe-wielding barbarian, then that might necessarily be a good thing.

But there is certainly, in publishing minds, this kind of idea that Scrum is this evil dragon that - “Oh, if we don't have a waterfall project planned with everything mapped out in detail, then this project is just going to go way overboard, and way over budget.”

I have to say that if you're doing a quality-driven title - so I'm basically separating the universe of game projects into release-date driven, and quality-driven; release-date being, “We gotta get it out by this date,” and quality driven being, “It's gotta be out when it's ready” - for a quality-driven product, using an iterative development model like Scrum is excellent for bringing that home, and for revisiting issues, and making sure that everything is just perfect.

For a release-date driven model, Scrum is excellent because, at the end of every sprint - Scrum project cycles are broken down into a number of sprints - you have something which could conceivably go to quality assurance. So if your due-date has to be - cannot miss! - this certain date, then at the end of every sprint you have something that you can conceivably ship with. Whether that's good or not, that's in debate. But you could theoretically launch it.

From the publishing side, Scrum has very few artifacts, so when you go into a Scrum product development methodology, instead of having, like, oodles of Microsoft Project files and Excel files, and this and that, what you have is the product backlog. People take product elements off the product backlog, the team puts it in the sprint backlog, they complete it, then they give you a sprint report and a playable build. The sprint report and the playable build are probably the best visibility into how the health and well-being of the development project of any of the corporate artifacts that come from the different development methodologies out there.

So, for example, if you're at a publisher, and you really want complete visibility into how is the team doing, what are they accomplishing, you have that sprint backlog and can see, at the end of each sprint, what the team did, what they failed at, and why.

You can't get more clear-cut than that. Having the actual sprint review build, that build of the game, to be able to take around internally and say, “Here, look. This is what the game is about. This is how we're doing. This is how we're going.” There's no better feel for how a project is going, instead of waiting however long for a given milestone build.

From the contractual side? I mean, it requires flex. Say you're doing a release-date driven title, and you're making a contract, and you know the team is operating on a Scrum development methodology. Well, it's easy to say, “This is the due date. These are the payments. And go. These are the number of people you have, and we'll be out on this date.”

Now when you go for a quality driven title, contractually it becomes a bit more sticky, in that you either have to, one, plan on going back to amendments to the contract to say, “Okay, we need two more sprints. We need three more sprints. We need this many more sprints.” Or actually building into the contract the possibility of approving and paying out more sprints on an as-needed basis. And of course, most business development people, and people who write the contracts in the publishing arms of organizations everywhere are probably not familiar with this, and very married to the standard way of doing things, which, of course, causes friction within the publishing organization.

Again, not a silver bullet, but I definitely couldn't see myself using any other development methodology that's in current practice today. I definitely am a huge Scrum fan.

I imagine that kind of heavily iterative method would be particularly suited to a game like this, where you've got fairly disparate gameplay styles that you're bringing together. I suspect that took a lot of trial and error.

SF: Most definitely. I mean, a piece of paper is never fun. Right? First person shooter is easy. Well, easier. You've got a point of reference, you know you're going to need some weapons, and some enemies, and maybe you're going to do an amazing narrative structure, and blow everything else out of the water. But for the most part, you know what you're aiming at.

For something where you are planting the flag, and you are running out ahead of everybody, and there are rocks, it does take time and iteration, and polish to get the jetpack to be as fun as the jetpack could be, or to make sure that the princess-rescuing is satisfying.

One other point, going back to the transparency, I don't think it's really part of the standard Scrum development methodology, although I may be incorrect about this, but one of the things we found really useful on this project is doing our burn-downs by discipline, so you have a burn-down chart which is basically, here's all the work that needs to be done on the project, and you watch it burn-down as elements are taken out of the product backlog.

When you burn-down by discipline, and you see the velocity of how the project is going, you can say, “Oh, we need more artists, or we need more designers, or we need more programmers.” And it becomes more obvious, sooner, although, again, that might already be written down somewhere. I haven't read all the Scrum books. That might be out there.


H-P said...

I was interested if anyone else has used those competency based burndowns and if so, which kind of experiences you have of them?

I was first very hesitant to even try those out when the idea was first brought into discussion by our product owner Kim Lahti. Those seemed to fight so badly against the cross-functionality in all of the levels. But after Kim managed to talk me through to try it out, I'd never let them go anymore in any game development project. As stated by mr Foe in that article, they give great insight in production level, but in addition they were great asset in team level as well. For example when combined with item specific burndowns, they give some quite good indications if the team is in danger of falling into mini-waterfalls, which is especially useful when working with new Scrum teams.

And yes, I worked as a scrum master in the development of the reset generation.

Clinton Keith said...

Hi h-p,

We've been having a discussion along those lines at Mike Cohn's blog:

Personally I think these discipline burndowns work well in production, when we know what the velocity of things like level geometry mean.

In pre-production I feel that the integrated teams are producing real value in discovering value/fun. When I'm in pre-production in a game and trying to discover which mechanics in our action-adventure are fun, the number of animations being created is not a good indication of progress towards that goal.