The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Fucntional vs Feature Teams in Game Development

http://www.agilegamedevelopment.com/2006/07/functional-vs-feature-teams.html

<quote>
Before we began using Agile, our project teams were mostly split into teams of programmers, designers and artists. This was great for disciplinary skill sets to be shared. However it increased the overhead of getting things working in the game. When we moved to using Agile, this became far more transparent and needed to be changed. There was initial resistance to this, and this affected our transition to feature teams.
</quote>

Good article on real world issues. Almost by definition when you create different groups you are creating different code bases.
son of parnas
Friday, August 18, 2006
 
 
With functional teams they were seeing "architectural progress and not real game value progress after each iteration" but with feature teams "the technology development fractured into multiple directions."

The article does not explain their solution very clearly but it sounds like they used scrum masters to lead discipline teams that cross-cut the feature teams, i.e. both types of teams at once. I agree that the feature teams need to be the primary unit while associations between people of the same discipline across teams is also very important, and the scrum/scheduling/story aspect is an interesting way of implementing that.

Great post. Thanks.
Ben Bryant
Monday, August 21, 2006
 
 
> agree that the feature teams need to be the primary
> unit while associations between people of the
> same discipline across teams is also very important

This the evolution I have seen happen at several places. Nothing really works well, but to get a release out you need a specific responsible team accountable to management.

Yet you also need a more unifying vision across groups, products, and releases. So that's a team too. They may overlap a lot of course.

I don't know of a better way except don't allow the problem grow outside of what can be handled by a small group.
son of parnas
Monday, August 21, 2006
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz