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.