The Myth of Agile Empowerment

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 hansoft.com at http://www.hansoft.com/expertblog/manage-cross-team-dependencies/