Gamasutra: The Art & Business of Making Gamesspacer
View All     RSS
October 30, 2014
arrowPress Releases
October 30, 2014
PR Newswire
View All
View All     Submit Event





If you enjoy reading this site, you might also want to check out these UBM Tech sites:


 
Why cross-functional?
by Samuel Rantaeskola on 01/25/13 05:26:00 am   Expert Blogs   Featured Blogs

The following blog post, unless otherwise noted, was written by a member of Gamasutra’s community.
The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company.

 

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:

Story

In this example we conclude that the story consists of components such as shotgun design, gun mechanics code and zombie death animation amongst other things.

Developing the feature will require a designer, an engineer, an animator, an effects artist, a modeler, a sound designer, and a QA. For simplicity, let’s assume that it can be completed by a team consisting of the above people within a sprint of two weeks.

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

 Organization structure

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: 

Substories 

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.

Subtasks 

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:

 Sprintchain

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:

Summary


Related Jobs

Infinity Ward / Activision
Infinity Ward / Activision — Woodland Hills, California, United States
[10.30.14]

Senior Sound Designer - Infinity Ward
Treyarch / Activision
Treyarch / Activision — Santa Monica, California, United States
[10.30.14]

Multiplayer Level Designer - Treyarch
Petroglyph Games
Petroglyph Games — Las Vegas, Nevada, United States
[10.29.14]

Producer
InnoGames GmbH
InnoGames GmbH — Hamburg, Germany
[10.29.14]

Community Manager The West and Tribal Wars (m/f) on -site






Comments


Laura Bularca
profile image
Great article as always!

Cross-functional teams are the way to go, but how do you go about creating this process? I would very much like to know your advice on that, considering that a studio has a number of designers, artists, coders, audio designers and QA so the teams should constantly shift based on the task. For example, when "zombie killing with super awesome gun" is ready, the artist might start on "super healing animations" while the designer might move on to "make zombies drop awesome guns", which means that (1) the teams physically shift from desk to desk as tasks are ready, (2) an artist might not benefit from other artists "help through chatter" because he is not in an art environment and finally (3) sometimes a feature is ready very fast from a design perspective, so what does the designer do, stays until the feature is validated by QA or moves to another team with another feature that needs design?

While is is easily fixable in small studios (where you are all usually in the same room) it gets harder to manage in large studios so I am very interested to learn how this can be done for larger teams. The only studio I know has managed this cross-functional model is Valve, and they have desks with wheels and physical support so people can move so easy, plus a good management philosophy in place which is understood and respected by all. But I am sure they got there after years of work, and the Valve way is not something a studio can simply adopt. So what is your advice?

Samuel Rantaeskola
profile image
I think there are quite a few keys to successfully implementing a cross-functional organization.

The absolute number one thing to mentally let go off is the term resource optimization. The production focused mind tends to look at a production as a big jig-saw puzzle where you need to fill in the holes with tasks to make best use of the team. With that mindset we are taking away the control from the teams to best organize themselves around their goals.

Secondly, ideally the team has more than one feature to focus on during a sprint and that way they can balance their efforts among the features. For that to work the order in which things should start has to be a bit flexible. With flexibility in ordering the team can choose items from the backlog smartly to balance their team.

I think the biggest impediment currently is management mind-set. The focus is still on individual optimization rather than seeing teams as the smallest unit in a larger organization. It's a big leap of faith where the mindset needs to change.

Valve is a good a example of a studio where the management have embraced (pioneered) the concept. But there are more studios that have gotten quite far.

However, I know from personal experience that it's very hard to implement this in an existing organization. There are so many "old ways" that needs to change, and change causes a sudden drop in productivity which studios rarely can pay for.

If I would give one advice it would be: Start small, make it work in one team before you move on and roll it out to the next team. My second advice would be: Have patience!

Andrew Grapsas
profile image
Ah, I'm so conflicted! Yes, I agree with crossfunctional teams for certain aspects of development. But, it's important to note that this is all dependent on the types of tasks being handled.

If, given your example, we now need to generate 100 shotgun variants, is the best approach to use the crossX team? Or, instead, generate an art pipeline to kick out the assets? Of course it's to use the pipeline (Let's Kanban it, man!).

I guess, my summary is: anyone that hasn't been exposed to crossX (Scrum is a solid example of a development methodology that focuses on crossX) should know that it's not a magic bullet, it solves certain types of problems -- like the one you offered above. But, again, it's just one tool in the arsenal of a well versed process engineer.

Edit: and I don't want to imply that you're saying it's a magic bullet :) I just want to make sure people that are reading this without the appropriate experience realize you're talking about a specific tool to solve a specific problem.

Samuel Rantaeskola
profile image
Good point! And there is no such thing as a magic bullet, any development method will require a lot of work and discipline.

I probably should have mentioned somewhere that this is focused on iterative development. As you mention there are smarter approaches when it comes to churning out for example environment assets with few dependencies.

Arly Rampen
profile image
Nice article! I totally agree with this one as I myself is currently applying it. For example, the mythical man-month can only happen if I increase the size of one department, but not the whole team on a project. I can add more people on arts/animations department as required but not on the programming team. For me its applicable on either waterfall or iterative development model. Its quicker, and each can deal with design changes separately and in parallel.

If there is somewhere I have to wait on artists' art/animation, a quick placeholders would help, so while the programmer can go on using the placeholders, the artists can go on finishing and polishing the demanded arts/animation based on the design.

Thanks Samuel!

Michael Rooney
profile image
"For example, the mythical man-month can only happen if I increase the size of one department, but not the whole team on a project."

That's not what the mythical man month is. The mythical man month phenomenon happens any time you increase the size of your team generally, regardless of where they are added. It has to do with communication dependencies rather than deliverable dependencies.


none
 
Comment: