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

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

Expand Messages
  • Diana Larsen
    Jan 6, 2006
      Gee Thanks, Guys! Affirmation feels good and warm on a rainy, dark Friday afternoon. 


      On Jan 6, 2006, at 2:08 PM, Clinton Keith wrote:



      We’re going to definitely let the team figure it out (with an outside Agile coach) in a few weeks once we get our Epics for the releases identified.


      Diana did an Open Space for the last Scrum Gathering in Boulder…it was very impressive indeed!




      -----Original Message-----
      From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Dan Rawsthorne
      Sent: Friday, January 06, 2006 11:37 AM
      To: scrumdevelopment@yahoogroups.com
      Subject: RE: [scrumdevelopment] Reforming teams based on Product Owner priorities


      Clint, I believe in letting the team figure it out. The first question I would pose to them is "can you guys figure out the new structure, or should we get some facilitation in here?" and give them a fixed time-box (1 hour, say) to discuss this and make a recommendation. The recommendation could be different like "we need some more info on this Open Space thing..." or it could be more concrete.


      However the team decides to do it, the goal is to have fairly wide stories (PBIs) that have a teamlet (work cell) swarming on them. These teamlets can be fixed or more organic (I prefer the latter, once the team has some maturity).


      And, if you want Open Space facilitation, you can't go wrong with Diana (blatant plug, but I've seen her work...)


      Dan  ;-)

      Dan Rawsthorne, PhD
      Senior Consultant, Certified Scrum Trainer
      office: 425-269-8628
      fax: 425-642-8202

      Net Objectives now provides technical staffing as well as training and coaching. Net Objectives' vision is effective software development without suffering. Our mission is to assist software development teams in accomplishing this through a combination of training and mentoring.


      Upcoming courses
      Design Patterns Explained  Jan 24-26  Bellevue, WA
      Design Patterns Explained  Feb 8-10   Cupertino, CA
      ScrumMaster Certification  Feb 21-22  Bellevue, WA
      ScrumMaster Certification  Mar 8-9    Cupertino, CA
      Lean Software Development  Mar 23-24  Bellevue, WA
      ScrumMaster Certification  Mar 22-23  Bloomington, MN
      Design Patterns Explained  Mar 28-30  Denver, CO
      The Product Owner          Mar 29-30  Bellevue, WA
      Lean Software Development  Apr 18-19  Denver, CO


      From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Diana Larsen
      Sent: Wednesday, January 04, 2006 1:38 PM
      To: scrumdevelopment@yahoogroups.com
      Subject: Re: [scrumdevelopment] Reforming teams based on Product Owner priorities



      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:



      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@...








      This email has been scanned by the MessageLabs Email Security System.
      For more information please visit http://www.messagelabs.com/email

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


    • Show all 10 messages in this topic