Saturday, July 08, 2006

Functional vs Feature Teams

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.

Initially we formed "Functional Teams" that were dominated by one discipline. One example of this would be an AI or Artificial Intelligence" team* that was mostly composed of programmers. After a few months of this, problems emerged. The main problem was that the team was creating AI in a vacuum. The requirements of AI was not being explored in a real game being iterated, but being developed by a programmer dominated team that was focused on delivering an architecture that all AI dependent teams would need. We were seeing architectural progress and not real game value progress after each iteration.

The next step for the teams was to move to "Functional Teams" to "Feature Teams". Feature Teams focus on a vertical slice of game-play (such as a shooting or driving mechanic" and requires a more highly mixed group of developers. The goal is to have a self-contained team that can address every part of development required to iterate on their vertical slice of game.

As we moved from Functional Teams to Feature Teams, the development of core areas of technology became highly distributed. For example, work on AI shifted from one Functional Team creating all of the AI for the project to one or two programmers on each Feature Team. This created problems. The first and foremost was that the technology development fractured into multiple directions. While this fine for early exploration, it was apparent that this would create problems in the future. We were making one game, but with the Features Teams acting independently, we were behaving as through we were creating three separate games. We would eventually need one AI system for the entire game. Also, we saw that feature teams would compete with one another for resources. This did not help create the sense that all three teams were part of one game development project.

The solution was to have teams form around each discipline (in addition to the feature teams). For example, the programmers formed a team with a Scrum Master that met at least once a week (or more often if needed) to discuss the direction of the technical effort of the team. The programming Scrum Master would also meet with the Scrum Master of the other disciplines (art and design) to discuss and come to a consensus on the vision for development for the game. If one feature team needed resources, they were to insure that those resources could be shared for the benefit of the entire team.

* I only use the AI team as an example because it’s clear to relate in a more general way. All teams had this problem.


jonathanlindsay said...

Just to clarify - you still have feature teams but individuals in these teams also make up cross feature discipline teams which meet weekly?

Clinton Keith said...


Clinton Keith said...

I've updated the entry to reflect that. Thanks!

jonathanlindsay said...

About the discipline Scrum Masters, are they the Leads? i.e. the art scrum master is the Art Lead etc.

JustJunebug said...

i found your blog by searching for information on agile development. what i was wondering is if you could recommend a book that would give me information sorta like "agile for dummies"? .... Thanks!

Dave Nicolette said...

It's amazing to see how similar things are in the game development world and the corporate IT world. While our disciplines are different - database design, network administration, and security instead of AI, physics, and art - the challenges of team dynamics, whether to divvy up the work by function or feature, and maintaining a common overarching vision of the end product across multiple teams are all the same.

Clinton Keith said...


The discipline Scrum Masters are not considered the leads. They are the "sheepdogs" for the disciplines. E.g. I would like the entire programming team to agree on technical issues. This SM's job is to insure that this happens and coach the individuals on the team. Much of this overlaps with the job of a lead anyways, but attempts to not take participation and too much ownership from the team.

Have a look at Mike Cohn's web site (see the links on )

Anonymous said...

My Firefox Sage plugin can't read your RSS XML feed:

XML Parsing Error: prefix not bound to a namespace
Line Number 30, Column 536:

Clinton Keith said...

Should be fixed now. I republished the entire blog from blogger and it works for me to (I don't use Sage, but I tried it and saw the same thing). Glad it worked because I have no other control over teh output from blogger!