作者：Samuel Rantaeskola

游戏开发的团队组织形式正在迅速转向自主组织、向下赋权、分散决策。当工作室朝这个趋势发展时，必然发生有（无）意识的交换；牺牲控制权以换取效率和创新能力。通过决策权下放，接近这个问题的人得以想出比集中式结构更明智的解决方法。

但这个新结构潜伏着一个大问题：这种团队如何合作？游戏开发充满相关性，因为产品是复杂的，且为了创造连贯的体验，一切者必须凝结为一体。团队无法各自为政；为了做出好游戏，他们必须互相依赖。这个问题的解决办法往往是集中管理方法论：有些东西总是必须管理的，对吧？

集中管理结构通常注重可预测性和控制。当短期计划布置到团队中去时，集中式思路会反映在产品待办事项中。为了增加交付的可预测性，第一步就是解决跨团队相关性问题，特别是，为了实现预测性和控制，制定要求团队必须遵守的高度瀑布式的时间表。

采用这种方法时，我们没有授权给团队，所有关键决策都是团队之上的管理层做出的，我们下放给团队的唯一权力就是让他们自己组织短期任务。为了真正实现权力下放，管理层必须信任团队能够自己协商与其他团队的相关性。他们必须是自己的工作的主人，能够自己决定开发的逻辑顺序。

Salesforce.com上发表了一篇关于如何用敏捷环境中的相关性管理解解决这个问题的文章。在文章中，作者表示没有人可以看到事情的全貌，因此相关性管理必须有团队的参与。作者还提出，相关性始终在变化，所以管理相关性的方法必须是连续的，而且要保证是连续的。

team_celebration(from keepingagilesimple)

那么我们如何管理跨团队的相关性？

首先，我们必须放弃旧的范式，例如提前映射所有相关性以增加我们对产品的预测性。这么做可能增加产品（未必是好产品）的预测性，付出的代价是，大量初期投入和创新能力下降。初期投入是团队经历和鉴定一连串相关性所需的时间和创新能力下降，因为当人们在产品待办事项上花掉大量精力后，往往很不愿意做出改变。

如果我们可以放弃集中决策这个最后的堡垒，那么我们就可以开始看看团队如何拥有产品待办事项和持续合作以提前清除相关性问题，防患于未然。

为了把权力真正地下放给团队，以便他们自己解决相关性问题，你要做到以下几点：

1、跨职能团队必须根据特征来组织，且具有完成他们的产品待办事项上的目标所必需的所有（几乎）能力。否则，相关性太大，将迫使团队将花大量时间思考他们的相关性在哪里。（提示，不要采用学科导向型的组织方式）

2、产品待办事项必须是目标导向型的（而不是充满任务）。任务导向型的待办事项往往包含太多信息，以至于无法有效地确定相关性。

3、团队对产品待办事项中属于自己的部分，必须有明确的主导权。

如果工作室不能满足以上三个指标，那么就不能说管理层把权力下放给团队了，在看相关性解决方案前，最好看看如何达到这个状态。

达到这些条件后，工作室可以进行以下简单的步骤：

1、团队浏览他们的待办事项，对任何一个因外部相关性而无法展开工作的标都要把这个相关性记下来。

2、每一次冲刺待办事项的目标前都要进行至少一次例会，团队之间要讨论各自的最优先级任务。

3、团队在待办事项中新增目标时，要考虑到确定的和一致的相关性。

这个过程可能太简单了，但是一个好的起点。

在我看来，敏捷意味着在正确的程度上做出正确的决策，当然必须有人控制产品的整体方向，甚至对于分散决策结构也是一样。把权力下放给团队，使成员自己处理他们的相关性问题，可以避免管理层太过专注于思考如何优化成员的时间。相反地，管理层可以把时间放在掌握大方向和支持团队上。（本文为游戏邦/gamerboom.com编译，拒绝任何不保留版权的转载，如需转载请联系：游戏邦）

The Myth of Agile Empowerment

by Samuel Rantaeskola

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?

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.(source:gamasutra)