Why cross-functional?

A lot of game studios today are to some degree organized by discipline. For example, the animators are sitting together in the animation department and the programmers are sitting in their respective offices in the engineering department. There usually exist some teams of mixed disciplines, but they all depend heavily on support from the different departments.

When it comes to planning in these organizations, most of the features in the backlog cannot be handled by a single team. This leads to breaking down the features into sub-components; each representing a portion that can be handled within a single discipline.

Let’s consider the following story:

Our example studio is organized by disciplines and looks like this:

None of the departments can develop the story solo. Management will have to break the feature down so that each sub-component can be handled within a department. Coordinating the completion of the feature will lie upon the production team. When tackling this, one approach is to break the feature down in to sub stories like these: 

More commonly, however, the story is broken into tasks already in the backlog, describing what work needs to be done. It might feel contrived to construct stories that represents HOW instead of WHAT.

In both cases, the organizational structure forces the backlog to grow rapidly; even in a rather small game. Another side-effect is that each feature requires a large amount of coordination between the departments, in order for the whole thing to work in harmony.

The reason for having a backlog is to have a good place to discuss prioritizations on a feature level and also have an understandable road map for the project. Ideally, a player reading your backlog should be excited by all the cool stuff you are going to put in your game. When the backlog becomes too large and too detailed the prioritization between features becomes impossible. All you are looking at is tasks/implementation details.

Implementing this broken-down feature in our example organization, we would do wisely to try to plan the work so that each department can complete their part of the work before the next department starts. The story components might flow through the sprints in the following manner:

It would take three sprints before the feature is at a state where we could start iterating on the initial design. Even without iterating on quality it would take five sprints to complete and verify the feature. Sure, there are ways of streamlining the process by starting concurrent work and cross team collaboration. But attempts like that will increase the complexity and likelihood of failed sprints. The more concurrency, the more need for coordination efforts.

The goal of a cross-functional organization is to give teams the tools to deliver complete goals with a minimum amount of external dependencies. With this, we also trust them to resolve their internal dependencies without much need of external coordination. 

In this example, if we had a team that consisted of a designer, an engineer, an animator, an effects artist, a modeler, a sound designer, and a QA they would have the resources needed to complete the work within one sprint. Shorter turn-around time leads to more iteration which should lead to a higher quality product. With less external dependencies we would also be decreasing the need for coordinators that exist outside of the teams to handle this complex process.

Finally, a cross-functional organization scales nicely. Adding a team does not increase the complexity as much as in a departmentalized organization. Since resolving dependencies is within the teams the management layer can be pretty thin. The need for additional layers of management will come a lot later than in “traditional” organization.

In short, a well-structured cross-functional organization has the following benefits: