I have never met this man in person, but he is very humble and friendly, he give away his important time to answer my curiosity which i am about to share it with you.
Sebastian Cardoso works in EA (as of now 14 Oct 2009) as development manager and scrum master.
Now what the heck is a Scrum Master?
Well, i have heard of Level designers, lead artists, character artist, programmer, engine guys, localization guys, game tester, and other job titles in the computer gaming industry, but SCRUM MASTER? What IS THAT?
So i wrote Sebastian Cardoso a message and asked him about it, i thought he will never reply, but he did reply with a full explanation about what a Scrum Master is!
And then after replying with thank yous etc, i asked his permission to quote his answer before posting it here.
So ere you go>
Hi Mae,
I'll try to summarize it as concisely and clearly as possible.
Scrum is an agile software development framework. In laymen terms: a way of organizing the way in which you work.
In software development, game industry included, you need some type of project planning or methodology to organize your tasks, the order in which you execute them, the dependencies involved, the risk that needs to be managed, the communication channels that need to be managed, etc.
The most widely use is the waterfall model, which is a sequential approach with stages in which you fulfill certain objectives: stage 1: define goals (what type of game, what is the unique selling proposition, etc.), stage 2: define design (the game design document), stage 3: develop and implement software and audiovisual assets as per the suggested design, stage 4: test and debug everything that went wrong in stage 3.
Agile development methodologies, of which Scrum is one, advocate that models like the waterfall model are highly ineffective for software development, and games, because of 3 reasons:
a) It's very unlikely that anyone can flawlessly envision stage 1 and all its requirements without having seen the product either in development or already finished. Put simply: software (and especially games!) is very unstable, there are always incredibly unexpected dependencies and issues and it usually happens that the developed product is not quite what was originally intended (i.e.: the game designer thought that a specific feature would be great fun but after playing it for the first time, it turns out it's completely and utterly dull)
b) The stages leave no room for iterating. That is: if halfway through stage 3, implementation, you come up with an incredibly cool idea for the game, there will be no time, budget and manpower to implement it because that idea did not appear on stage 1 and design was not written for it
c) The stages are sequential, which means if one of them is delayed, all subsequent stages are delayed. This should be a deal breaker for any company
d) Stage 4, testing and debugging, has been proven to be far more expensive (20x, if memory serves me right), than immediately testing and debugging after a task has been completed
So what agile methodologies propose is instead of having one huge cycle with all the aforementioned stages for the entire development of a product, you have multiple ones. For instance: if you have a 4-month project, instead of using month 1 for defining the goals, month 2 for defining design, month 3 for production and month 4 for testing and debugging, you go through all these stages once a month, effectively repeating the cycle 4 times in 4 months. The benefit of doing this is that at the end of each month you get to see a a small yet finished slice of the product. With that, you can empirically assess if that part of the game is fun, if it's working out, if development times are according to the plan, etc, etc. It's a simply more flexible approach. Plus, if you're behind schedule, you're not completely empty-handed - you could still release a game that's not as complete as you would have wanted, but that can be put in a box.
Scrum in particular has some unique particularities: the project manager is now a scrum master and delegates most decision making to the team; the project plan is organized as a prioritized task list called a product backlog; the cycles (called sprints) are of one month and the mini project plan for that month is called the sprint backlog, which is just a bunch of tasks pulled out of the product backlog; the team has 1 person in charge of deciding the work priorities (what to develop next) called Product Owner; there's 1 long meeting at the beginning of every month to plan work, 1 meeting at the end to present all finished work (to keep everyone accountable) and 1 small postmortem to improve on things for the next sprint, etc.
There. It didn't turn out to be very short nor very eloquent, but since I'm a bit busy, it'll have to do.
I hope it helps and if you need any more info, I'll be happy to help.
Cheers,
Sebastian
More information about Sebastian Cardoso> click here
Sebastian Cardoso works in EA (as of now 14 Oct 2009) as development manager and scrum master.
Now what the heck is a Scrum Master?
Well, i have heard of Level designers, lead artists, character artist, programmer, engine guys, localization guys, game tester, and other job titles in the computer gaming industry, but SCRUM MASTER? What IS THAT?
So i wrote Sebastian Cardoso a message and asked him about it, i thought he will never reply, but he did reply with a full explanation about what a Scrum Master is!
And then after replying with thank yous etc, i asked his permission to quote his answer before posting it here.
So ere you go>
Hi Mae,
I'll try to summarize it as concisely and clearly as possible.
Scrum is an agile software development framework. In laymen terms: a way of organizing the way in which you work.
In software development, game industry included, you need some type of project planning or methodology to organize your tasks, the order in which you execute them, the dependencies involved, the risk that needs to be managed, the communication channels that need to be managed, etc.
The most widely use is the waterfall model, which is a sequential approach with stages in which you fulfill certain objectives: stage 1: define goals (what type of game, what is the unique selling proposition, etc.), stage 2: define design (the game design document), stage 3: develop and implement software and audiovisual assets as per the suggested design, stage 4: test and debug everything that went wrong in stage 3.
Agile development methodologies, of which Scrum is one, advocate that models like the waterfall model are highly ineffective for software development, and games, because of 3 reasons:
a) It's very unlikely that anyone can flawlessly envision stage 1 and all its requirements without having seen the product either in development or already finished. Put simply: software (and especially games!) is very unstable, there are always incredibly unexpected dependencies and issues and it usually happens that the developed product is not quite what was originally intended (i.e.: the game designer thought that a specific feature would be great fun but after playing it for the first time, it turns out it's completely and utterly dull)
b) The stages leave no room for iterating. That is: if halfway through stage 3, implementation, you come up with an incredibly cool idea for the game, there will be no time, budget and manpower to implement it because that idea did not appear on stage 1 and design was not written for it
c) The stages are sequential, which means if one of them is delayed, all subsequent stages are delayed. This should be a deal breaker for any company
d) Stage 4, testing and debugging, has been proven to be far more expensive (20x, if memory serves me right), than immediately testing and debugging after a task has been completed
So what agile methodologies propose is instead of having one huge cycle with all the aforementioned stages for the entire development of a product, you have multiple ones. For instance: if you have a 4-month project, instead of using month 1 for defining the goals, month 2 for defining design, month 3 for production and month 4 for testing and debugging, you go through all these stages once a month, effectively repeating the cycle 4 times in 4 months. The benefit of doing this is that at the end of each month you get to see a a small yet finished slice of the product. With that, you can empirically assess if that part of the game is fun, if it's working out, if development times are according to the plan, etc, etc. It's a simply more flexible approach. Plus, if you're behind schedule, you're not completely empty-handed - you could still release a game that's not as complete as you would have wanted, but that can be put in a box.
Scrum in particular has some unique particularities: the project manager is now a scrum master and delegates most decision making to the team; the project plan is organized as a prioritized task list called a product backlog; the cycles (called sprints) are of one month and the mini project plan for that month is called the sprint backlog, which is just a bunch of tasks pulled out of the product backlog; the team has 1 person in charge of deciding the work priorities (what to develop next) called Product Owner; there's 1 long meeting at the beginning of every month to plan work, 1 meeting at the end to present all finished work (to keep everyone accountable) and 1 small postmortem to improve on things for the next sprint, etc.
There. It didn't turn out to be very short nor very eloquent, but since I'm a bit busy, it'll have to do.
I hope it helps and if you need any more info, I'll be happy to help.
Cheers,
Sebastian
More information about Sebastian Cardoso> click here