规模化敏捷管理系统为什么在多团队里用不起来：4个组织原因

很多组织在单团队阶段运行顺畅，扩展到多个团队后，规模化敏捷管理系统也上线了，交付反而变慢：目标对不齐，依赖靠人催，评审会变成责任追究会。问题往往不在系统功能，而在组织仍用单团队的方式管理多团队。

这里说的系统，是承载多团队规划、依赖、度量和协作的管理平台，不等同于Scrum或SAFe框架。系统能把规则固化下来，却不能代替组织分配决策权、明确团队边界、改变考核方式。下面四个组织原因，解释它为什么在多团队里用不起来。

一、先判断：是系统难用，还是组织没准备好

1. 单团队管交付，多团队管关系

单团队敏捷的核心，是在稳定小队内形成计划、执行、检视的闭环；多团队规模化的核心，是让多个小队围绕同一价值目标协同。前者主要管事，后者主要管关系。关系没理顺，系统里再多看板，也只是把问题记录得更清楚。

2020版《Scrum指南》指出，Scrum团队应跨职能、自我管理，由组织授权自行决定谁做、何时做、怎么做。授权来自组织，不来自工具。

2. 四个信号说明问题在组织层

如果站会变成逐人汇报，迭代评审变成责任追究，跨团队依赖只能靠私下催促；或者系统里数据齐全，关键决策仍要层层上报，基本可以判断问题不在系统。

下表把常见症状、容易得出的误判和更可能的组织原因放在一起，便于初筛。

表格里的症状往往同时出现，指向的不是某个部门，而是同一套组织规则。

3. 先排除工具能力不足

如果系统本身不支持跨团队依赖对象、团队级权限或按端到端价值流汇总的报表，先补齐工具能力。工具能力不足和组织规则缺失，需要分开判断。这不是第五个原因，而是诊断前提。

二、四个组织原因，让规模化敏捷管理系统停在表面

四个原因分别对应决策、边界、依赖和度量四个维度，并且会互相强化：团队不稳定会放大依赖，局部度量又会加剧资源争夺。系统能让规则变得可见，不能替管理层做取舍。

四个原因可对照下图。

1. 原因一：只复制流程，没有重新分配决策权

最常见的做法，是把单团队的Scrum会议和流程复制到所有团队，再配置同样的流程模板。形式很快统一，但需求优先级、资源调配、发布窗口仍由原层级审批。团队名义上自我管理，实际只能对已定范围负责。

麦肯锡在《敏捷组织的形意神》一文中提出，架构、流程和人员要三管齐下，并建议企业先回答：敏捷小团队拥有哪些人事权、财务权和业务决策权。没有决策权，自我管理很容易退化为被动执行。

系统在这里的作用，是把已定规则固化为角色、权限和流程。规则不清，系统往往只能记录请示过程。

2. 原因二：团队是临时拼装的，不是稳定单元

多团队场景里，常见的安排是按职能管理的共享资源池：开发、测试、设计按项目临时抽调，一个人同时服务三四个团队。项目看似并行，实际成员的注意力被切碎，迭代承诺容易失真。

2020版《Scrum指南》指出，Scrum团队应跨职能、自我管理，通常不超过十人；团队过大时，应考虑重组为多个围绕同一产品目标的小团队，而不是在团队内再分层级。稳定团队往往是可预测交付的前提。

系统如果按项目建团队、按人员统计容量，成员跨项目复用后，容量数据会失真。组织要先确定团队边界、投入比例和长期目标，再谈跨团队协同。

3. 原因三：跨团队依赖没有被当作一等对象

单团队阶段，依赖可在站会上口头解决；多团队阶段，依赖会沿着架构、接口、环境和发布节奏扩散。A团队等B团队的接口，B团队等C团队的环境，最后所有团队都在等，却没有团队对整条依赖链负责。

SAFe官方文档通常将PI（规划间隔）设为8至12周一个周期，并通过PI规划让团队共同识别依赖、对齐目标并形成承诺。依赖管理的重点不是多开会，而是让每个依赖都有负责人、承诺时间和升级路径。

如果系统里只有任务状态，没有依赖对象、被依赖方和约定时间，所谓并行计划，往往只是看似并行、实际互相等待。组织需要把依赖登记为正式工作项，在固定节奏里检视和升级。

依赖治理可参考下图。

4. 原因四：度量仍奖励局部最优

规模化后容易出现一种偏差：每个团队的故事点完成率（团队内部估算工作量的完成比例）都不错，整体交付周期却没有下降。因为组织考核的是团队产出量，不是端到端价值流动。于是大家倾向于接容易的任务、守住自己的资源、把协作视为额外负担。

麦肯锡在文中还提醒，企业需要回答敏捷小团队如何衡量价值创造，以及新衡量逻辑与既有体系的差异。如果考核只按部门产出和人员利用率计算，协作就容易失去动力。

系统可以提供端到端价值流动效率、依赖解决时长、迭代目标达成率等数据，但采用哪些指标、如何与绩效挂钩，由组织决定。指标选错，系统越精细，局部最优的问题可能越明显。

两类指标可对照下图。

三、修复顺序：先动组织，再调系统

四个原因不宜同时改造。更稳妥的顺序是：先定团队和决策权，再建依赖治理，最后调整度量。顺序颠倒，系统会越配越复杂，组织行为却不变。

1. 第一步：划定团队边界与决策权

先选一条从需求到交付的端到端价值流，明确团队负责什么、不负责什么，成员投入比例是多少，哪些决策团队可以自己做。把这些内容写成治理规则，再映射到系统角色和权限。至少写清四件事：需求优先级、资源调配、发布窗口、质量把关分别由谁拍板。先有规则，再有配置。

多团队分属多个项目集时，先梳理项目集边界和依赖，再映射到项目集管理视图。

2. 第二步：建立依赖治理节奏

以PI或季度为周期，要求每个团队在计划阶段列出对外依赖，明确被依赖方、约定时间和升级条件。计划后每周只检视高风险依赖，避免把所有协作都搬进例会。系统里的依赖项应能追溯到责任人和状态。

3. 第三步：换掉局部最优的度量

把团队考核从单一产出量，调整为团队目标达成、端到端交付周期、依赖按时解决率等组合指标。指标不宜多，关键是让团队知道：协作被看见、阻塞被解决，比单独追求产出量更重要。

在工具层面，禅道规模化敏捷支持跨职能团队、ART（敏捷发布火车）和PI管理，能把团队、目标、依赖和风险放进同一套节奏；但这类系统只是承载规则的工具，前提是组织先把规则定清楚。

四、验证：什么信号说明开始运转

第一章的四个信号用于初筛，这里的四个信号用于验证修复效果。修复是否有效，不看系统上线多少模块，而看组织行为有没有变化。可以先记录一个月左右的基线，再做月度检查：

• 决策信号：团队能否不层层请示就调整迭代范围，产品负责人对优先级的决定是否被尊重。
• 边界信号：成员的项目切换次数是否下降，投入比例是否稳定。
• 依赖信号：跨团队依赖是否有明确负责人和承诺时间，平均解决时长是否缩短。
• 度量信号：考核是否从单人产出转向团队目标与端到端流动。

如果只有系统使用率上升，其他三项没有变化，可能仍停留在工具层。此时继续加模块，往往只会增加管理成本。

系统用不起来，往往不是系统本身不能用，而是组织还没有为它准备好可执行的规则。

五、常见问题解答

1. 试点团队效果不错，为什么一推广就变慢？

试点往往拿到更强的成员、更多关注和更少审批；推广后这些条件消失，跨团队依赖和组织规则的问题才暴露。先复制团队边界、决策权和依赖治理，再复制会议和模板。

2. 团队数量不多，但跨团队依赖很重，要不要上规模化框架？

不宜只按团队数量做决定。若依赖已经影响交付节奏，靠例会无法解决，可以先引入轻量的统一规划节奏和依赖登记，再判断是否需要完整框架；过早引入重流程也可能增加负担。

3. 中层管理者不配合，是意识问题还是考核问题？

很多时候并非不懂敏捷，而是他们的考核仍按部门产出和资源控制计算，协作会被看成削弱自己的资源控制权。先调整考核和决策边界，再谈意识和培训，通常更有效。