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

Reforming teams based on Product Owner priorities

Expand Messages
  • Clinton Keith
    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
    Message 1 of 10 , Jan 4, 2006
    • 0 Attachment

      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

       

       

    • Steven Ropa
      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,
      Message 2 of 10 , Jan 4, 2006
      • 0 Attachment
        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....
         
         
        Steve


        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!

         

        Clint

         

         

      • Dave Churchville
        There is an interesting parallel between what you describe in game development (the specialist problem), and in some of the enterprise enviornments I ve
        Message 3 of 10 , Jan 4, 2006
        • 0 Attachment
          There is an interesting parallel between what you describe in game development (the specialist problem), and in some of the "enterprise" enviornments I've worked in. The specialists there are DBAs, networking experts, the "server-side" guy, the "web" girl, etc.

          In my experience, an effective way of reorganizing is to make "feature teams" or groups of people that focus on one end-to-end slice of the final system. You've already identifiend the slices, it looks like, so it's a matter of figuring out how to make teams.

          If you've got limited specialists (e.g. 2 AI people, 6 general developers, 1 artist, etc.), you'll probably need some people to be on multiple teams. Probably not more than 2 or 3, though, just for sanity.

          Possible arrangement:

          - Driving Game Team
          - 2 developers full time (Steve and Bill)
          - 1 AI person, part time (Fred)
          - 1 artist, part time (Joe)
          - Fighting Game Team
          - 2 developers full time (Mary, Tony)
          - 1 AI persion, part time (Fred)
          - 1 artist, part time (Joe)

          Each team can have their daily scrum/stand up, and work their project. The people on multiple teams can help keep consistency and eliminate duplication (in things like AI, character development, etc.). It might be helpful to have the specialists have their own breakout meetings (an AI meeting or an artists meeting).

          Alternatively, you could have a "scrum of scrums", or a separate meeting where a representative from each team meets (or everyone meets if there are less than 10 people or so).

          As far as command and control versus "self-organizing", maybe it's just a matter of suggesting some possibilities, asking for what the team wants to do, and supporting it. Of course, if the team hasn't been doing agile very long, you might not get the answer you want. I don't think there's anything wrong with a little guidance here.

          Hope this helps.

          --Dave

          -----------------------------------
          Dave Churchville
          ExtremePlanner Software
          http://www.extremeplanner.com
          Agile Project Management for Distributed Teams

          --- In scrumdevelopment@yahoogroups.com, "Clinton Keith" <ckeith@h...> wrote:

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

          > 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.
        • Paul Hodgetts
          ... My first advice is to make sure you have a product backlog that reflects the wider vertical slice strategy. We want to make sure we put that in front of
          Message 4 of 10 , Jan 4, 2006
          • 0 Attachment
            Clint wrote:

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

            My first advice is to make sure you have a product backlog that
            reflects the wider vertical slice strategy. We want to make
            sure we put that in front of the team as the goal. In other
            words, their primary issue to solve is how to deliver that
            backlog with its priorities, not how to organize and allocate
            resources (oops, sorry, I used that word ;-).

            I don't think it's necessarily a bad idea to toss them into a
            room and ask them to figure it out. But two caveats. We're
            asking the team to not only figure out how to get the work
            done, but also to figure out how to structure the team to give
            them the capability to get the work done. If the team is not
            at a stage where they can self-organize at this level, they
            may not be able to solve this as a team and we may need to
            revert to a more "telling" or "selling" approach. Or they may
            need some work on building their abilities to solve this type
            of issue as a team. Some preparation is probably a good idea.

            Second caveat, I would never toss the team of 50 into a room
            without really good facilitation and experienced coaching to
            help them through this type of situation. Perhaps the coaching
            can come from folks in your organization that are good at team
            facilitation and have some experience with solving this type of
            resource allocation problem. A free-for-all won't help at all.

            I'd also allocate sufficient time for this. It won't be a one
            hour meeting with a crisp answer. They may need to do a little
            sprint planning to see the skills needed for the backlog items.
            They may need some elapsed time to chew on things, generate
            ideas and reconvene. Facilitate and focus, but don't rush it.

            But I think if the team is very focused on figuring out how to
            deliver the backlog, and they have sufficient skills and/or
            coaching, having them solve this issue will be very powerful.

            Once they know how to do it, they can then work on being able
            to self-adjust each sprint when the new mix of backlog items
            needs a slightly different team organization to get it done
            most effectively. If the team of 50 is working together and
            thinking like a team of 50 instead of multiple teams, they can
            be a very powerful development engine for larger projects.

            Paul
            -----
            Paul Hodgetts -- CEO, Coach, Trainer, Consultant
            Agile Logic -- www.agilelogic.com
            Training, Coaching, Consulting -- Agile Processes/Scrum/Lean/XP
            Complete solutions for adopting agile processes, Scrum and XP.
          • Diana Larsen
            Clint, 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,
            Message 5 of 10 , Jan 4, 2006
            • 0 Attachment
              Clint, 

              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

              Diana Larsen

              www.futureworksconsulting.com   503-288-3550

              www.futureworksconsulting.com/blog/


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


              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!

               

              Clint

               
               


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



              SPONSORED LINKS
              Scrum


              YAHOO! GROUPS LINKS






            • Christopher Spiller
              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
              Message 6 of 10 , 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/>.
                >
                >
                > ------------------------------------------------------------------------
                >
              • Clinton Keith
                Thanks to everyone who gave feedback. Just to follow-up and summarize, we re going to do the following based on some of the advice: - Develop a new
                Message 7 of 10 , Jan 5, 2006
                • 0 Attachment

                  Thanks to everyone who gave feedback.

                   

                  Just to follow-up and summarize, we’re going to do the following based on some of the advice:

                  -          Develop a new release backlog (with the product owner) before any team changes are made.

                  -          Have an all-hands  team meeting where the release plan is discussed and teams are formed.

                  o        We’ll have an Agile coach present to facilitate.

                  o        Sign up sheets are a great idea, but depends on the coach’s approach.

                  o        The team will self organize into a teams which they feel best address the PO’s release desire.

                  o        The next Sprint’s backlog is defined.

                  -          We’ll also investigate have specialists Scrum once a day from across the teams (e.g. the AI programmer Scrum)

                   

                  I’ll let you know in a month or two how this is working out.


                  Thanks again!


                  Clint

                    

                   

                   

                   

                  -----Original Message-----
                  From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Clinton Keith
                  Sent: Wednesday, January 04, 2006 9: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!

                   

                  Clint

                   

                   


                • Dan Rawsthorne
                  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
                  Message 8 of 10 , Jan 6, 2006
                  • 0 Attachment
                    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
                    www.netobjectives.com
                    DrDan@...
                    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

                    Clint, 

                    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

                    Diana Larsen

                    www.futureworksconsulting.com   503-288-3550

                    www.futureworksconsulting.com/blog/


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


                    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!


                     

                    Clint


                     

                     


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



                    SPONSORED LINKS
                    Scrum


                    YAHOO! GROUPS LINKS







                    ______________________________________________________________________
                    This email has been scanned by the MessageLabs Email Security System.
                    For more information please visit http://www.messagelabs.com/email
                    ______________________________________________________________________
                  • Clinton Keith
                    Dan, 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
                    Message 9 of 10 , Jan 6, 2006
                    • 0 Attachment

                      Dan,

                       

                      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!

                       

                      Thanks!
                      Clint

                       

                      -----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
                      www.netobjectives.com
                      DrDan@...
                      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

                      Clint, 

                       

                      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

                       

                      Diana Larsen

                      www.futureworksconsulting.com   503-288-3550

                      www.futureworksconsulting.com/blog/

                       

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

                       

                       

                      Steve

                       


                      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!


                       

                      Clint


                       


                       



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


                      SPONSORED LINKS

                      Scrum

                       


                      YAHOO! GROUPS LINKS

                       

                       


                       



                       


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

                    • Diana Larsen
                      Gee Thanks, Guys! Affirmation feels good and warm on a rainy, dark Friday afternoon. Diana ... Gee Thanks, Guys! Affirmation feels good and warm on a rainy,
                      Message 10 of 10 , Jan 6, 2006
                      • 0 Attachment
                        Gee Thanks, Guys! Affirmation feels good and warm on a rainy, dark Friday afternoon. 

                        Diana

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

                        Dan,

                         

                        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!

                         

                        Thanks!
                        Clint

                         

                        -----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
                        www.netobjectives.com
                        DrDan@...
                        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

                        Clint, 

                         

                        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

                         
                        Diana Larsen
                        www.futureworksconsulting.com   503-288-3550
                        www.futureworksconsulting.com/blog/

                         

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

                         
                         

                        Steve

                         

                        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!


                         

                        Clint


                         


                         



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


                        SPONSORED LINKS

                        Scrum

                         

                        YAHOO! GROUPS LINKS

                         
                         

                         



                         


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




                        YAHOO! GROUPS LINKS

                      Your message has been successfully submitted and would be delivered to recipients shortly.