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

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

Expand Messages
  • Diana Larsen
    Jan 4, 2006
    • 0 Attachment

      If you are concerned that 50 people can't self-organize for this task, consider having someone come in to facilitate an Open Space around the question, "As an Agile team using Scrum principles, what will best help us deliver wider vertical slices?" Reorganizing the team is one solution. And that may be the one that surfaces at the end of an open space session. But, there may be other solutions out there that you/we don't see that will emerge from self-organized action planning among people who are there dealing with the daily constraints/opportunities of the your work and your environment. 

      Tossing people in a room could also work, but it might take longer. Telling them to figure it out has a command and control feel to it. Extending an invitation to explore and offering a bit, a small bit, of structure to the discussions (as through Open Space Technology) will help folks get to work on the question faster. 

      Trust the team. The best answer lies within their collaboration. 


      Diana Larsen

      www.futureworksconsulting.com   503-288-3550


      Upcoming Events:

      - Open Workshop with Diana Larsen & Esther Derby 

        "The Secrets of  Agile Teamwork: Beyond Technical Skills"

         Next Session: June 6-8, 2006, Portland OR USA 

         email Diana or Esther for more information:

         dlarsen@...  or derby@...

      On Jan 4, 2006, at 10:49 AM, Steven Ropa wrote:

      I personally am a big fan of tossing people in a room.  If you let everyone sign up for whatever they are interested in, and vigorously apply pair programming, you end up with a much more informed team.  Obviously, the artists won't be signing up for AI, and hopefully the programmers won't be signing up for graphic art.  I would also suggest it might be worth your while to gently make sure that such sign-ups don't happen.
      Here's a thought that just occurred to me.  Why not put up some sign up sheets.  One sheet for each portion of the game, with a heading for each role you want to have filled.  Don't number them, but see where everyone organizes themselves.  Leave them up for a few days/ a week/ however long you can afford.  You'd probably want some caveats that these teams are not permanent, but it would at least give everyone a chance to organize for the first sprint or so.  I haven't thought this through, mind you, but it feels good to start with....

      From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Clinton Keith
      Sent: Wednesday, January 04, 2006 10:16 AM
      To: scrumdevelopment@yahoogroups.com
      Subject: [scrumdevelopment] Reforming teams based on Product Owner priorities

      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!




      To Post a message, send it to:   scrumdevelopment@...
      To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...



    • Show all 10 messages in this topic