Agile Developme - Those doing development planning - read this.
by Andy Hawkins · in General Discussion · 03/31/2007 (4:10 pm) · 9 replies
The game design doc, preproduction, coding, asset creation, bug fix, ship to market paradigm might not always work these days. Considering games come out so quickly and your game is going to take x amount of months / years to complete, you might prefer the Agile method of game development. It stops you from focusing on a game design that might be outdated and not fun to do by the time you ship to market.
Agile on Wiki
In a nut shell it's a way of compartmentalising work into small time segments called sprints of 1 to 6 weeks. You create user stories, like in this sprint, "as a player I want to see my xp on screen above my head", or "as a developer I want to be able to debug at runtime with python". "As a game player I want to see onscreen feedback for my cool moves". That sort of thing. You break each user story into difficulty, 1 to 13. Then you arrange in order of priority (okay not a nut shell now)
Whatever you think can be done in the duration of your sprint you pick, and shelve the rest til next sprint. User stories are then are broken down into how long it will take, and then the steps required to achieve it. Anything that will take longer than 2 working days should be broken into 2 or more tasks.
At the end of each sprint you check the user stories (usually written on cards) Which ever ones are complete get put away (task complete - yay!) Which ever ones are not done get broken down based on what work is remaining and get thrown back on the table to be prioritised against new user stories, and ones not addressed last sprint.
The meeting process is cool too. During sprint meetings you aren't allowed to go off task. For example, a user story comes up, "as a gamer I want to be able to access missiles at the click of a button". The team starts talking about that and how it can be done, and one member goes, "hey did you check out Chrome Hounds and it's weapon system? I was in this firefight and..." STOP! Off task - let's talk about that offline.
Every day you also Scrum. Scrumming is where everyone actually stands up around in a circle in the office and tells everyone briefly what they did yesterday and what they are doing today. Your speech should take 2 mins max. That's the point of standing. Everyone doesn't want to stand around for longer than 10 mins so you are expected to be quick, people don't waste 1 to 2 hours in drawn out sit-down meetings, and everyone can go back to work.
Also you don't need to code it right first time. If you want to try a HUD, to address a user story, you can try a bit of code to address the problem without having to mod all code to support it. It leads you down the path of problem solving and discovery faster, and as coding changes are small, mods to make it project-centric are always quick, once people are happy with the change.
Anyway, this all leads to rapid fire prototyping, development and ultimately a game that has team input, is fun to play and is always in touch with the market.
Agile on Wiki
In a nut shell it's a way of compartmentalising work into small time segments called sprints of 1 to 6 weeks. You create user stories, like in this sprint, "as a player I want to see my xp on screen above my head", or "as a developer I want to be able to debug at runtime with python". "As a game player I want to see onscreen feedback for my cool moves". That sort of thing. You break each user story into difficulty, 1 to 13. Then you arrange in order of priority (okay not a nut shell now)
Whatever you think can be done in the duration of your sprint you pick, and shelve the rest til next sprint. User stories are then are broken down into how long it will take, and then the steps required to achieve it. Anything that will take longer than 2 working days should be broken into 2 or more tasks.
At the end of each sprint you check the user stories (usually written on cards) Which ever ones are complete get put away (task complete - yay!) Which ever ones are not done get broken down based on what work is remaining and get thrown back on the table to be prioritised against new user stories, and ones not addressed last sprint.
The meeting process is cool too. During sprint meetings you aren't allowed to go off task. For example, a user story comes up, "as a gamer I want to be able to access missiles at the click of a button". The team starts talking about that and how it can be done, and one member goes, "hey did you check out Chrome Hounds and it's weapon system? I was in this firefight and..." STOP! Off task - let's talk about that offline.
Every day you also Scrum. Scrumming is where everyone actually stands up around in a circle in the office and tells everyone briefly what they did yesterday and what they are doing today. Your speech should take 2 mins max. That's the point of standing. Everyone doesn't want to stand around for longer than 10 mins so you are expected to be quick, people don't waste 1 to 2 hours in drawn out sit-down meetings, and everyone can go back to work.
Also you don't need to code it right first time. If you want to try a HUD, to address a user story, you can try a bit of code to address the problem without having to mod all code to support it. It leads you down the path of problem solving and discovery faster, and as coding changes are small, mods to make it project-centric are always quick, once people are happy with the change.
Anyway, this all leads to rapid fire prototyping, development and ultimately a game that has team input, is fun to play and is always in touch with the market.
#2
I don't really care if people don't go for it, because I'm not going to 'preach' it to people. It's just a better way to make a game IMHO.
04/01/2007 (7:13 am)
Well it's not at all. You should read it. It may sound hokey, but it's a no-nonsense approach to project development. It is very suitable to self-publishers such as indie game dev co's.I don't really care if people don't go for it, because I'm not going to 'preach' it to people. It's just a better way to make a game IMHO.
#3
Your quick summary of Agile ... where you describe the 10 minute standing meetings, etc, etc ... are most likely how most indie's get there work done ...
Indie games usually don't take years to develop ... they are quick and fast, in most cases ... since the more games they push out, the more money they make ... they don't have the luxury to sit around in conference rooms and shooting the shit ... and I'd be very surprised if any Indie house had formal "meetings" where they scheduled a 1-2 hour time block each day or week to sit down and discuss things ... AND ... kept the meeting appointments ...cause we all know, it's one thing to schedule meetings, it's another thing all together to stick to the meeting ... ;)
Also ... I agree with Mark, as Agile does seem to be more fitting for large development teams ... such as corporations, where things can go off track very quickly and fail to find there way back in any reasonable time frame ...
I do agree, Agile is a great way to get things done ... I just fail to see it's usefulness to the Indie Game Developer community ...
Thanks for the write up, it was a good read ...
04/01/2007 (12:21 pm)
Personally, Agile and SCRUMM are only really useful when you've got large teams ... Indie's by nature tend to work in smaller teams, and in most cases, they are usually remote teams ... so the Agile/SCRUMM "quick meet" concepts wouldn't really work ... and, I think most Indie's use a modified style of Agile/SCRUMM on a daily basis, and just don't realize it ...Your quick summary of Agile ... where you describe the 10 minute standing meetings, etc, etc ... are most likely how most indie's get there work done ...
Indie games usually don't take years to develop ... they are quick and fast, in most cases ... since the more games they push out, the more money they make ... they don't have the luxury to sit around in conference rooms and shooting the shit ... and I'd be very surprised if any Indie house had formal "meetings" where they scheduled a 1-2 hour time block each day or week to sit down and discuss things ... AND ... kept the meeting appointments ...cause we all know, it's one thing to schedule meetings, it's another thing all together to stick to the meeting ... ;)
Also ... I agree with Mark, as Agile does seem to be more fitting for large development teams ... such as corporations, where things can go off track very quickly and fail to find there way back in any reasonable time frame ...
I do agree, Agile is a great way to get things done ... I just fail to see it's usefulness to the Indie Game Developer community ...
Thanks for the write up, it was a good read ...
#4
Personally I think the single best development practice I have read about in a long time (and it was several years ago I read about it and don't recall the source) was the idea of the "mini post mortem" held during development, so that it forced a constant assessment/reassessment of tools practices and policies.
Essentially the idea was while a project post mortem is a good idea after a project is complete, it offers no benefit to the project, because its already over. More to the point, if you are talking about project that runs a year and a half to two or more years, all of the nuances of situational problems get lost and forgotten.
If you are doing a mini post mortem every few weeks to a month, then problems can be identified and solutions found before you get to a point of not return.
I worked in an environment that would have benefited greatly from a mini post mortem practice. Sadly it was never put to use.
04/01/2007 (12:54 pm)
It is an interesting idea. but put it to use a game dev environment ruled by publishers and it goes out the window pretty quick in my opinion.Personally I think the single best development practice I have read about in a long time (and it was several years ago I read about it and don't recall the source) was the idea of the "mini post mortem" held during development, so that it forced a constant assessment/reassessment of tools practices and policies.
Essentially the idea was while a project post mortem is a good idea after a project is complete, it offers no benefit to the project, because its already over. More to the point, if you are talking about project that runs a year and a half to two or more years, all of the nuances of situational problems get lost and forgotten.
If you are doing a mini post mortem every few weeks to a month, then problems can be identified and solutions found before you get to a point of not return.
I worked in an environment that would have benefited greatly from a mini post mortem practice. Sadly it was never put to use.
#5
To often I see people work on their web site when there isn't even a game. No one cares if you have a rocking web site that always has a "coming soon" logo on it.
Or I see someone working on "advanced cool feature X" when basic game play is broken in their demo. Another form of this is someone worring about how to host 1000 players when they don't even have the "start game" menu prototyped.
Just my thoughts and how I approach things.
04/01/2007 (1:01 pm)
I think the practice of coming up with user stories for the game you are trying to make, prioritizing them based on customer value and then always working with a possible shippable bit of code is a good practice for game development. To often I see people work on their web site when there isn't even a game. No one cares if you have a rocking web site that always has a "coming soon" logo on it.
Or I see someone working on "advanced cool feature X" when basic game play is broken in their demo. Another form of this is someone worring about how to host 1000 players when they don't even have the "start game" menu prototyped.
Just my thoughts and how I approach things.
#6
04/01/2007 (3:56 pm)
Yeah that's one of the best parts is that at all sprints the game is runnable. I think it says on the Wiki that it's not suitable for large teams. If you have teams largers than 20 then break them into 2 teams. Say art and dev, or more suitably game play and engine or something like that so there's a mix of artists and programmers in each team.
#7
I do like being able to see what is contained in a sprint, and what is upcoming in a sprint, as well as a backlog. Things like this are very useful.
Paired Programming however, is something I don't think I could ever get used to ;)
Here is a good link to check out for agile game development
www.agilegamedevelopment.com/
04/02/2007 (8:33 am)
There are quite a few game studios using a modified version of SCRUMM . We've toyed around with the idea, not totally sold on it yet (our studio follows the hollywood production model, outsource everything as needed)I do like being able to see what is contained in a sprint, and what is upcoming in a sprint, as well as a backlog. Things like this are very useful.
Paired Programming however, is something I don't think I could ever get used to ;)
Here is a good link to check out for agile game development
www.agilegamedevelopment.com/
#8
My 4 man team at school used SCRUM. I even blogged about it, Have you SCRUMmed lately?
My current company is developing two projects. I'm leading both projects, and using SCRUM for one. The system is slightly modified to accommodate team members working remotely, but everything is going fine so far.
04/02/2007 (9:22 am)
Ummm. . .use what works best for you and your team, but don't dismiss a development process, management practice, or design theory without proper reasoning. Just because a team is independent and/or small, does not mean a system can't work for them.My 4 man team at school used SCRUM. I even blogged about it, Have you SCRUMmed lately?
My current company is developing two projects. I'm leading both projects, and using SCRUM for one. The system is slightly modified to accommodate team members working remotely, but everything is going fine so far.
#9
04/02/2007 (11:56 am)
I use SCRUM in my day job and I have only good things to say about it. I think it lives up to its hype. One concern I often have about people advocating "agile methods" is that they tend to treat good, solid, up front design as unfashionable. I still believe that Code Complete is the best software dev practice book ever written. I can't tell you how often I've been told that design is a waste of time, we need to code first and modify it later. I don't see this attitude in my workplace (in fact, many sprints get devoted to design), but I do see it in open source development projects. 
Mark Ripley
Sounds more suited to corporate environments, where the walls have those "inspirational" posters on them, rather than a creative environment that's also at the mercy of the whims of a publisher, but thanks for that post Andy - I'll have a read up on it now :)