RE: [scrumdevelopment] Re: good article on Scrum, game development, and long-term planning
- Hi Andrew,
The article doesn't cover any of these areas you describe, but I would counter most of them with our examples:
#1 - Scrum teams are self-organizing to a great degree. Leads still exist, but focus mainly on mentoring. They still do "physical work" rather than chase people around with clipboards measuring task progress.
#2 - The most effective Scrum teams are the cross-discipline teams. Artists, designers and programmers working together on a shippable feature that has direct customer value can really focus on the feature, not the craft.
#3 - I agree with this. This is part of the mentoring role of leads, but not every team has a lead animator, for example, so some external validation is helpful.
#4 - Two day Sprints?! We've gone as short as 2 weeks, have settle on 3 as a best rhythm that feels good. Oddly enough, the sprints didn't lengthen in production but the teams adopted some "kanaban" style practices to better control the flow of production assets through the pipeline during Sprints.
From: firstname.lastname@example.org on behalf of Andrew Burrows
Sent: Fri 12/21/2007 12:46 PM
Subject: RE: [scrumdevelopment] Re: good article on Scrum, game development, and long-term planning
I haven't read the Gamasutra article yet, so apologies if any of this is
covered in that.
I'm working with a small team right now on Scrum and have been doing so for
about 6 months, but before that I produced Transformers for Activision with
a team of over 70 people (using a waterfall methodology for the first half,
and then a panicked "get it in the box" anti-methodology for the last half).
I've often been trying to figure out exactly what you raised in terms of
breaking the team down on larger projects, and how I would do that if I was
using Agile from the start on such a project.
I genuinely believe it's possible to do this, but I've identified 4
"hypothetical" areas that I would perceive as being absolutely essential for
it to work.
#1 - You would need team leads that can actually lead - i.e. not a lead
who's become a lead simply because that person has been with the company for
the longest. There's going to be a ton of management and delegation work
put onto their shoulders and if they can't lead - or won't lead - then it's
going to fall apart. The lead of each team is also going to do no physical
work in their field - they're whole job is going to be organization.
#2 - Self-organizing teams are fine, as long as they're sociable - I don't
think that it would be hard to get a programming team or an art team working
with Scrum, but the problem is going to be in terms of them working
together. From my own experience it's bad enough trying to get programmers
and animators to see eye to eye when it's clearly marked out in Project
exactly who will be doing what. To this end, I would absolutely reinforce
the idea of presentations between teams to ensure that everyone is pulling
in the right direction. In addition to this.
#3 - Verification is likely to need people external to the team - As per
normal development, a lead animator will be able to approve an animation
look and style without necessarily being able to approve the animation as
correct from an implementation point of view. To this end, it may be worth
appointing select team members from each scrum team to participate in any
#4 - Pre-production sprints should be short - Imagine how short they should
be, and then halve that time. Giving a team too long on a pre-production
sprint makes the process very messy and wastes time. I've found that it's
so much better to have the team pressured into getting everything done in a
very short sprint (say, two days) and to then test the end result of that,
iterate and move on.
Anyway, this is all just hypothetical but if you do want someone to bounce
ideas off then I'm more than happy to help (albeit after I get back from my
vacation on Jan 2nd!)
[mailto:email@example.com] On Behalf Of keithfuller_01
Sent: Friday, December 21, 2007 3:29 PM
Subject: [scrumdevelopment] Re: good article on Scrum, game development, and
I found Clinton's article to accurately represent a number of the
potential gotchas inherent in game development, at least at the
developer/publisher level. I'd find it more helpful to hear his
thoughts on the impact of Scrum implementation on team organization --
i.e. how best to divvy up artists, designers, animators, and
programmers into Scrum teams. That's proving to be a major concern of
mine as I contemplate applying agile to my own game project.
--- In firstname.lastname@example.org
<mailto:scrumdevelopment%40yahoogroups.com> , "Lyndon Washington"
> Thanks for sharing, that was a great read and interesting to see the
> adoption of pre-production and production phases that appear, to my
> eyes to be a form of development and release sprints :)recognize
> I especially liked the checklists for the customer to help them
> their own responsibilities in the process.or
> On 12/18/07, Mike Cohn <mike@...> wrote:
> > In you're interested in how Scrum applies to game development,
> > interested in how it applies to project's with long schedules(e.g., 2
> > years) like a typical AAA game, Clinton Keith just wrote aninteresting
> > article on the subject for GamaSutra. It's at:http://www.gamasutra.com/view/feature/3142/scrum_and_long_term_project
> > Regards,
> > Mike Cohn
> > Author:
> > Agile Estimating and Planning
> > User Stories Applied
> > www.mountaingoatsoftware.com
> Lyndon Washington
> t: 508.425.4722
> w: http://blog.the-washingtons.com/