Loading ...
Sorry, an error occurred while loading the content.

RE: [scrumdevelopment] Re: good article on Scrum, game development, and long-term planning

Expand Messages
  • Clinton Keith
    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
    Message 1 of 6 , Dec 22 9:27 AM
      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.


      -----Original Message-----
      From: scrumdevelopment@yahoogroups.com on behalf of Andrew Burrows
      Sent: Fri 12/21/2007 12:46 PM
      To: scrumdevelopment@yahoogroups.com
      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
      verification meetings.

      #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!)

      Happy holidays!

      From: scrumdevelopment@yahoogroups.com
      [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of keithfuller_01
      Sent: Friday, December 21, 2007 3:29 PM
      To: scrumdevelopment@yahoogroups.com
      Subject: [scrumdevelopment] Re: good article on Scrum, game development, and
      long-term planning

      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 scrumdevelopment@yahoogroups.com
      <mailto:scrumdevelopment%40yahoogroups.com> , "Lyndon Washington"
      <hoshposh@...> wrote:
      > 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 :)
      > I especially liked the checklists for the customer to help them
      > their own responsibilities in the process.
      > Cheers,
      > -Lyndon-
      > 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 an
      > > article on the subject for GamaSutra. It's at:
      > >
      > >
      > >
      > >
      > > 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/
    Your message has been successfully submitted and would be delivered to recipients shortly.