Gamasutra: The Art & Business of Making Gamesspacer
View All     RSS
October 26, 2014
arrowPress Releases
October 26, 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:

The Myth of Agile Empowerment
by Samuel Rantaeskola on 10/23/13 10:59: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.


The trend in game development is rapidly moving towards self-organizing, empowered feature teams with decentralized decision making.  When a studio is moving in that direction an (un)conscious trade-off will take place, the studio is sacrificing control for the hope that there will be an increased velocity and innovation. By pushing the power of decision making downwards, people closer to the problem will be able to devise smarter solutions than in the centralized structure. 

Lurking in this new structure there is a big problem: how are the teams going to collaborate? Game development is filled with dependencies, since the products are complex and in order to create a coherent experience everything need to jell. The teams cannot work in silos irrespective of each other; they will be dependent on each other to build the best possible game. The solution to this problem tends to fall back on centralized management methodologies; something needs to be managed, right?

Centralized management structures tend to value predictability and control, which has taken a hit. When the short-time planning efforts have been moved into the teams, the centralized thinking will hop into the product backlog. To increase the predictability of the deliveries the first natural step is to try to resolve the cross-team dependencies, essentially creating a high-level waterfall schedule that the team needs to follow in order for predictability and control needs to be fulfilled. 

With this approach we have not empowered the teams, all the key decisions will be made a level above the teams and the only power we have given the teams is to organize their short term tasks themselves. For true empowerment to happen the teams must also be trusted to identify and negotiate their dependencies with the other teams. They must be the owners of their backlog and to best resolve the logical order of development.

Salesforce has published an article on how the went about to tackle the problem with dependency management in a large agile environment. In the article they are (among others) saying that no one person can be expected to see the whole picture, and thus dependency management needs to be pushed down to the teams. They also realized that dependencies changes all the time so that the method of managing them must be continuous, but also facilitated to ensure that it happens.

So how do we manage cross-team dependencies? 

For studios that have been working with agile practices for a long time, this is probably handled by the teams in an effecient manner. However, in teams that are stuck in SCRUM-but, dependency resolution between teams might be a real problem.

First of all, we need to let go of old paradigms, such as mapping out all the dependencies early on will increase our predictability towards a great product. It might increase predictability towards a (not necessarily great) product, but it comes at the cost of a large initial investment and also at the reduction of innovation. The initial investment is the time it takes for the teams to go through and identify the chain of dependencies and the reduction of innovation because the amount of energy put into the product backlog makes people reluctant to change course.

If we can let go of the last bastion of centralized decision making, we can start looking at how the teams can own and collaborate in the product backlog continuously to clear out dependencies before they become blockers for progress.

Here are a few key elements for successfully empowering your teams to resolve their own dependencies:

1.    The cross-functional teams need to organized around features and contain all (most) competencies that are required to meet the goals in their part of the product backlog. Otherwise the amount of dependencies will be so large that teams will spend an immense amount of time trying to figure out where their dependencies are. (Hint, does not work in a discipline oriented organization).

2.    The product backlog needs to be goal-driven (not filled with tasks). A task-driven backlog will contain too much information to effectively identify dependencies.

3.    The teams need to have a clear ownership of their portion of the product backlog.

If the studio does not meet the three criteria listed above it is a stretch to say that the teams are empowered, and it might be an idea to look at how to get to this state before looking at the dependency resolution. In an earlier post Why cross-functional? I talk about the benefits of organizing around current goals.

With these conditions met one can run the following simple process:

1.    The teams sweep through their backlogs, for every goal that they cannot start working on due to some external dependency they take a note of that dependency.

2.    A regular meeting that happens at least once per sprint goes through the blocked goals with highest priority in each team’s backlog to discuss between the teams. 

3.    Teams will add new goals to their backlogs to cover for the identified and agreed dependencies. 

The process will probably be too simplistic for most places, but it is a starting point from which you can adapt and evolve something that works for your situation.

In my mind, being agile is about making the right decisions at the right level.  It goes without saying that there needs to be people maintaining an overall direction of the product, even with decentralized decision making in place. With empowered teams that are handling their own dependencies game direction can stop focusing on how to optimize from peoples’ time. Instead they can spend their time on developing the overall vision and supporting the teams with high-level direction.

Edit: I have written a more in depth process description at at

Related Jobs

Forio — San Francisco, California, United States

Project Manager / Producer (Games)
Yoh — Vancouver, British Columbia, Canada

Build & Test Engineer
Infinity Ward / Activision
Infinity Ward / Activision — Woodland Hills, California, United States

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

Multiplayer Level Designer - Treyarch


Jason Bentley
profile image
"The Myth of Agile Empowerment"
I don't understand the title. In Agile development decision making IS pushed down as much as possible. What part is the 'Myth'?

"1. The teams sweep through their backlogs...
2. A regular meeting that happens at least once per sprint...
3. ...add new goals to their backlogs to cover ... dependencies."

I would suggest "Agile Game Development With Scrum". It's an excellent book and these three goals are corner stones of his process. Clinton Keith, the author, is on here regularly and I'm interested to hear his thoughts as well.

Samuel Rantaeskola
profile image
The myth refers to that the empowerment that has happened in most teams are just that they plan the sprints, whereas the backlog is still kept under centralized control. The practices (scheduled) applied to map out dependencies essentially nullifies any empowerment. Hence the myth..

Jason Bentley
profile image
I would disagree because Agile is intended to give the decision making of "HOW" to get things done to the people who will actually be doing it, while it is intentionally left to management to decide "WHAT" gets priority.

I can't imagine a situation working, in the long run, where the development team gets to decide the course of a project.

I don't see a Myth. As I understand Agile, it's intention is to minimize context switching and maximize expert decision making; this is achieved through a backlog and empowerment. Empowerment is not the goal; it's a part of the process to improve your process.

Samuel Rantaeskola
profile image
In regards to the process, it and similar methods are mentioned in a wide variety of agile litterature. The point is not what the process exactly should look like, but that it should be owned by teams and adapted to the situation. Not the BDUF way.

Samuel Rantaeskola
profile image
I definitely agree with you that management should be giving direction about the high level priorities and the teams filling in the blanks. It was not my intention to across otherwise.
However, what I wanted (perhaps clumsily) to get through is that often the direction goes so deep that they are actually resolving dependencies when setting priorities. A better delegation of ownership of high-level targets allows teams to operate within that framework and identify the best way of working.

As I see it there is no clear cut line between HOW and WHAT, it's a gray zone. I think that zone lies within the backlog. In a perfect situation the directors would "seed" the teams backlogs with high-level goals that they from there on break down into sub goals. The prioritization of the sub goals needs to be a combination of product value and logical implementation order, where the teams are experts on the latter.

Empowerment is not a goal as you say, but it is a very powerful tool create a positive environment where great things happen.

Joel Capperella
profile image
I'm a little confused by the headline. . . it seems that what you describe is not an issue with Agile development methodologies, such as SCRUM for instance, but will applying the methodologies correctly. The prescription offered reads like a 'how to' for implementing agile - planning the sprint, identifying obstacles early, empowering team to address obstacles immediately. Might a better headline here be "Poor Implementation of Agile can minimize empowerment" ?

Samuel Rantaeskola
profile image
That's probably a better title. Sorry for the confusion!

Arnold Hendrick
profile image
In using Agile for almost a decade in game development, I've noticed that discipline-oriented studios have the biggest problems, since at least one department will strongly resist the creation of cross-functional teams.

However, once that problem is removed, a more sigificant one emerges. Even the best team takes 2-3 sprints to become efficient and fully productive as they progress through the usual "forming, storming, norming, performing" stages. In today's shorter-cycle game projects, I've noticed that each release cycle is typically 3-6 sprints. For each new release, at least some teams need to trade members, or be significantly reorganized, to pursue new goals.

The culprit, of course, is the wide variety of specialized knowledge and skills needed to make a game. Keeping sprints to 2 weeks can help, but I've found that despite the best intentions of scrum theory, shorter sprints do yield more overhead time. Furthermore, even with 2-week sprints, today's shorter-cycle projects don't leave you that many sprints if you sync up releases with major development phases like concept, pre-production, production, testing, and live.

More than once I've caught myself trying to revise release and project goals simply to maintain the existing mix of high-performing teams. Inevitably, various compromise solutions were found. But I do wish there was a "better way" to keep teams together while meeting all the varied needs of successful game production.

Samuel Rantaeskola
profile image
In the environments I'm coming from rigid milestone schedules was the biggest culprit. There's nothing more destructive to a working process than a important milestone delivery. It brings out bad habits ...

Matheus Motta
profile image
Nice post Samuel, would be great to have this post 3 years ago.

We at Critical Studio had a hard time figuring out how to deal with dependencies and sometimes we would go for weeks without putting presentable work toghether because we could not figure out what should be done first. A lot of rework was done.

We happened to learn by practice and came with a solution on the same line as yours. =)

Clinton Keith
profile image
Sorry if I'm late to the conversation. Samuel pointed me here.

Dealing with longer term dependencies is trickier than the ones that cross-discipline teams deal with within a sprint. I wrote about how teams handle them in the release cycle here: