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

Re: [scrumdevelopment] Scrum for Games Development

Expand Messages
  • Ron Jeffries
    ... I m sure it ll be useful. In my opinion, quite likely MORE useful the more dynamic the project environment is. Ron Jeffries www.XProgramming.com You have
    Message 1 of 6 , Jun 1, 2004
    • 0 Attachment
      On Tuesday, June 1, 2004, at 9:31:30 AM, blzbub69 wrote:

      > I was wondering if any one has had any experience running a (and I
      > hasten to use the term) 'creative' project rather than one that is
      > more business orientated. Do you think the course would be of use?

      I'm sure it'll be useful. In my opinion, quite likely MORE useful the more
      dynamic the project environment is.

      Ron Jeffries
      www.XProgramming.com
      You have to either laugh or cry. -- Bill Rogers
    • Bryan Zarnett
      In the development of simple games such as on-line gambling, I don t view much of a difference between normal business development and the development of games
      Message 2 of 6 , Jun 1, 2004
      • 0 Attachment
        In the development of simple games such as on-line gambling, I don't
        view much of a difference between normal business development and the
        development of games (based on past experience). In terms of large-
        scale gameplay where you need to coordinate art directors, producers,
        graphic artists, etc. I think Scrum would be a very useful tool for
        the management of any game project from first person shooter to a
        massive on-liner. The simple reason is time management and the
        coordination of resources in association to a specific block of work
        being done.

        Knowing stuff from some of the big game companies, things are
        mismanaged from the get go - primarily from a lack of focus on what
        needs to be done. Between the two backlogs, this will help focus and
        define the work. The burndown chart and sprint signature log will
        help focus a team on what a problem is so that during the
        retrospective it can be fixed (or sooner).

        I honestly don't think in total that business versus game development
        is very different. It might be percieved to be, but I don't think it
        is. It's just a different group of people. You still need to follow
        some basic principles and engineering practices. If you don't, then
        maybe that is the first place to start.

        Are there specific issues you are attempting to solve or see solved?


        --- In scrumdevelopment@yahoogroups.com, "blzbub69" <bigg@a...> wrote:
        > Hi All,
        >
        > I'm relatively new to the Scrum process having used 'iterative'
        > project management tools previously.
        >
        > I've signed up for the ScrumMaster course run by Ken but I'm not
        > totally convinced that I would find the course useful. I'm not a
        > programmer by any means (unless you count basic Basic and macro
        > coding!) but have been running game projects for over eight years.
        > I've read Ken's Agile Project Development with Scrum as it's more
        > relevant to me than the software development one.
        >
        > I was wondering if any one has had any experience running a (and I
        > hasten to use the term) 'creative' project rather than one that is
        > more business orientated. Do you think the course would be of use?
        >
        > Kind regards
        >
        > G
      • Deb
        There is not a line of code in the course... it is really about running the project (any project), which is what you sound interested in. Various participants
        Message 3 of 6 , Jun 1, 2004
        • 0 Attachment
          There is not a line of code in the course... it is really about
          running the project (any project), which is what you sound interested
          in. Various participants in the course contribute in different ways -
          some will suggest technical solutions as part of the exercise, others
          will provide leadership. The big advantage of the course over the
          book (in my view) is the experience it gives you of how quickly Scrum
          can boost a team into action, and how it gets (and keeps) the
          creative juices flowing. I suspect it would be great for game
          development!

          Note: one reason people are switching to Agile is that software
          development is much more like research than like manufacturing... And
          Agile is better suited to this. You've probably read this in Ken's
          books. In this way, Scrum (and Agile in general) are very well suited
          to creative activities, where features shift and the outcome is only
          glimpsed at the outset.

          One of our ScrumMasters has used it to run Museum Exhibitions, I
          believe: Joseph, can you offer some commentary on your use of Scrum
          in the creative domain?

          --- In scrumdevelopment@yahoogroups.com, "blzbub69" <bigg@a...> wrote:
          > Hi All,
          > ...
          > I was wondering if any one has had any experience running a (and I
          > hasten to use the term) 'creative' project rather than one that is
          > more business orientated. Do you think the course would be of use?
          >
          > Kind regards
          >
          > G
        • Graeme Monk
          ... That s what I m kind of hoping! The problem we have is that the goal posts tend to change on a regular basis either on how gameplay feels or more asthetic
          Message 4 of 6 , Jun 1, 2004
          • 0 Attachment
            --- "Deb" wrote:
            > I suspect it would be great for game development!

            --- and "Ron Jeffries" wrote:
            > I'm sure it'll be useful. In my opinion, quite likely MORE useful
            > the more dynamic the project environment is.

            That's what I'm kind of hoping! The problem we have is that the goal
            posts tend to change on a regular basis either on how gameplay feels
            or more asthetic changes. It's this process that causes major delays,
            especially when it's decided to return to the orginal system that was
            criticised 6 months previously :o(

            --- "Bryan Zarnett" wrote:
            > In terms of large-scale gameplay where you need to coordinate art
            > directors, producers, graphic artists, etc. I think Scrum would be
            > a very useful tool for the management of any game project from
            > first person shooter to a massive on-liner.
            > <snip>
            > Are there specific issues you are attempting to solve or see solved?

            From what I've read of the process thus far I believe that you are
            correct. I've initiated Scrum for our current project and whilst the
            team are keen on the approach, management still need to be convinced -
            although they are getting there. I still have a problem whereby
            management still want a day to day input on the project and cause the
            team to stray, which I understand is a problem with changing from the
            more traditional approach. I also recognise this as a failing on my
            part, hence signing up for the course.
          • Deb
            ... the ... the ... I assume that managment is one/the source of your features? If you run short sprints, management can have input to the Feature Backlog
            Message 5 of 6 , Jun 1, 2004
            • 0 Attachment
              --- In scrumdevelopment@yahoogroups.com, "Graeme Monk" <bigg@a...>
              wrote:
              > I still have a problem whereby
              > management still want a day to day input on the project and cause
              the
              > team to stray, which I understand is a problem with changing from
              the
              > more traditional approach. I also recognise this as a failing on my
              > part, hence signing up for the course.

              I assume that managment is one/the source of your features?

              If you run short sprints, management can have input to the Feature
              Backlog daily if they want, without upsetting the Sprint, and can
              replan the Sprint Backlogs regularly (some people run 2-week
              sprints). Once they understand that they can rearrange the Features
              in future sprints, including tweaks to prior Sprint features, they
              might just be happy to leave you alone for two weeks.

              In our case, our verrrry insecure customers settled down fast, once
              they realised that their requests were absolutely not being lost or
              shelved. They explicitly said - no, it's ok, we can wait for that, we
              know we'll see it on the list again at Backlog Planning time. The
              Product Backlog is visible to them at all times, in fact it is
              THEIRS. This is very reassuring.

              Also, they get to see working code demo' (say, every two weeks) so
              you are less likely to throw out 6 months of work. This is a big
              selling point - if they are really paying attention, you could only
              be throwing out one Sprint's work, which is not so bad.
            Your message has been successfully submitted and would be delivered to recipients shortly.