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

11028Re: [scrumdevelopment] Reforming teams based on Product Owner priorities

Expand Messages
  • Christopher Spiller
    Jan 5, 2006
    • 0 Attachment
      Hi Clint.

      It sounds to me like it is a change in the Sprint Goal. From something like: "Finish the modeling and texturing of the subway level" to "Get the Driving level ready for guest testing". If I were on that team of 50 in either a Dev or management capacity, I think I would want:

      1: To clarify the goal a little bit: Is it getting the driving portion of the game ready for a guest test (maybe in a 2-3 sprint window?), Is it eliminating risk that some vendor-provided module will work when integrated with your mechanics and AI?, etc...

      2: To have something to look at each and every day. Once the goal is clearly defined (maybe for a 'release' i.e. Guest Test/Publisher Demo not just a Sprint if that is easier), is there a way I could start automated integrated builds? Is there a system that at the end of every day (or week) I could see the running, tested, integrated results of what I did, the AI folks did, the texture artists, animators, etc... It would be ideal if there was some representation of the 'Driving Level' at the beginning of the Sprint that was constantly added to over the course of the Sprint. Maybe at first it is nothing, then wireframe models, then simple AI, then simple mechanics. Maybe at the end of a sprint it is still wireframes, but everything is working together. If this was playable at the end of every day, so much the better. This is possible, though hard.

      3: Enough slack in the schedule so that all parts of the production pipeline are not sequenced so tightly that everyone is 'fully utilized' 100% of the time. The goal is not to keep everybody busy but to produce an integrated, playable game. It will be rough at first but over the course of a Sprint or two I would expect sequencing problems to come up and become progressively easier to deal with. If everyone is scheduled to be 'fully utilized' 100% of the time, any change in sequencing will cause delays.

      4: To not fall into the trap of 'delivering' an architecture or infrastructure. I bet (particularly if you are trying to set up some sort of automated integrated playable build) there will be lots of that work. Just make sure there is _something_ playable on top of that infrastructure.

      5: The product owner to be sure this is what they want. It will be very hard if the PO wants to keep switching between delivering 'wide slices' (playable demos?) and 'narrow slice' improvements to AI, mechanics, etc... I would think over the course of the game development lifecycle you'd want to move slowly from wide slice to narrow slice (not switch back and forth). First get something playable out there with rudimentary AI, textures, mechanics, then start refining and refine for as long as the budget allows!


      Then for the nitty gritty of getting those 50 people to work towards that goal:

      It seems like there are 2 (at least) dimensions of teams: The Wide Slice and The Narrow Slice.
      Maybe everyone is on both a wide slice (Driving Level, Spy Level, etc...) and a Narrow Slice (Character Rigging, Lighting, Configuration Management, etc...). The wide slice team is a Scrum team in a Sprint with Sprint Goals. The narrow slice team is not really a Scrum team more of a Specialist Group (there are lots of fancy names for this). I would probably want everyone to go to 2 daily meetings: A Scrum for the 'wide slice' and a similar daily meeting for the Specialist Group. This way the specialists can share knowledge and help each other remove obstacles without trying to maintain a separate backlog of 'Lighting Features' to deliver - because you can't really deliver a lighting feature if there is nothing to light!.

      So - I think everyone will fall pretty easily into 1 or 2 Specialist Groups, then you and the Product Owner can define the Wide Slice Goals and make it clear what the deliverables of a wide slice are. If you know some particular individuals who are strong 'lead from the middle' types you might talk to them about how they'd divide up the work first and use that as some guidance to the group of 50 (something like: 'Driving is going to need a lot of Physics but not much lighting, Subway fight is going to need a lot more lighting and animation.') If the goals of each wide slice are clear, then the group of 50 will be able to self organize into 'wide slice' teams. If the goals are iffy....not so much.

      And let them try again in 30 days :)

      my $.02
      -Chris

      Clinton Keith wrote:
      > Yesterday, our product owner asked that we focus our teams on delivering
      > wider vertical slices of the video game that we are making.
      >
      >
      >
      > Previously we delivered working software that demonstrated incremental
      > improvements in the following areas:
      >
      > - Artificial Intelligence – bad guys doing stuff
      >
      > - Levels/Worlds – Where the action takes place
      >
      > - Gameplay mechanics – What the main character does.
      >
      >
      >
      > We all feel that the problem with having such teams is that there we are
      > still postponing understanding of the true value of our game by having
      > these areas separate and integrating technology later rather than
      > earlier. The new teams would be divided into developing all of the
      > areas above in the separate major gameplay mechanics e.g.:
      >
      > - The driving portion of the game
      >
      > - The “sneaking around and doing spy stuff” portion of the game.
      >
      > - The hand-to-hand combat portion of the game.
      >
      >
      >
      > This mixes things up a bit. For example, each team would need
      > Artificial Intelligence applied.
      >
      >
      >
      > Here’s the question:
      >
      > Since game development requires a lot of specialists (artists,
      > programmers, designers, etc). We still have to consider who goes where
      > (I’ll avoid using the word ‘resources’). It’s a major reorganization of
      > teams. What is the best way to let these 50 people self organize into
      > these teams? The first impulse was to “command and control” it and
      > assign people into the teams. This isn’t the Agile way. However,
      > tossing people into a room and telling them to figure it out doesn’t
      > seem very effective either.
      >
      >
      > Any advice is appreciated!
      >
      >
      >
      > Clint
      >
      >
      >
      >
      >
      >
      >
      > To Post a message, send it to: scrumdevelopment@...
      > To Unsubscribe, send a blank message to:
      > scrumdevelopment-unsubscribe@...
      >
      >
      >
      > SPONSORED LINKS
      > Scrum
      > <http://groups.yahoo.com/gads?t=ms&k=Scrum&w1=Scrum&c=1&s=11&.sig=KvDTKhw7ncC9XbB25jdApQ>
      >
      >
      >
      > ------------------------------------------------------------------------
      > YAHOO! GROUPS LINKS
      >
      > * Visit your group "scrumdevelopment
      > <http://groups.yahoo.com/group/scrumdevelopment>" on the web.
      >
      > * To unsubscribe from this group, send an email to:
      > scrumdevelopment-unsubscribe@yahoogroups.com
      > <mailto:scrumdevelopment-unsubscribe@yahoogroups.com?subject=Unsubscribe>
      >
      > * Your use of Yahoo! Groups is subject to the Yahoo! Terms of
      > Service <http://docs.yahoo.com/info/terms/>.
      >
      >
      > ------------------------------------------------------------------------
      >
    • Show all 10 messages in this topic