10986Re: Reforming teams based on Product Owner priorities
- Jan 4, 2006There 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.
- 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.
Agile Project Management for Distributed Teams
--- In email@example.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.
- << Previous post in topic Next post in topic >>