一个典型的“敏捷开发”团队。（图片来源：Metro-Goldwyn-Mayer）
这称作“Scrum”的东西是普遍存在的，也是一种压迫性的工具，用于微观管理。它完全是关于故事点和速度。它已经让开发者，设计师，产品经理和中层管理者一致感到鄙视。令人难以忍受的是，所有这些问题都有众所周知的解决方案，这些解决方案可以在一本简洁的14页文档《Scrum指南》中找到。
指南对什么是Scrum和什么不是Scrum说得一清二楚：
Scrum框架如上所述是不可更改的。虽然只实施Scrum的部分是可能的，但是那就不算是Scrum了。
我们很少有人真正按照《Scrum指南》定义的方式在一个Scrum团队工作过，但很多人却在一个Scrum形式主义环境中工作过。
仅仅跟随 Scrum 本身并不能体现美德。灵活性 是重要的，但 Scrum 只是实现这一目标的一种方式。但几乎每一个声称“采用 Scrum”的人，在他们开始第一个冲刺之前，就已经去除了使 Scrum 起作用的至关重要的元素。这并不是对《Scrum 指南》中的每一个字句的宗教般的虔诚，而是简单地理解它是如何运作的。这就是为什么我们使用“cargo cult”的比喻，因为我们最终只是在模仿系统的表面现象，同时移除了使其能够有效运作的关键部分。
这引发了一个更深层次的问题：为什么我们所有人都遵循所谓的Scrum，但实际上没有人真正按照Scrum指南中的定义去执行Scrum？
在敏捷转型过程中会遇到许多问题，但我发现《Scrum指南》中有两个段落经常被提到，这两个段落经常出现在讨论中。
Scrum团队是多功能的，这意味着团队成员拥有在每个Sprint（冲刺周期）中创造价值所需的各种技能。同时，它们也是自我管理的，团队内部自行决定每个人的任务、时间和方式。
：
这个增量 zhège zēngliàng整个Scrum团队成员确保每个Sprint创造出有价值的增量。
尽管上述引文将第二段和第一段的开头生硬地分开，但它们应该连在一起。
- Scrum团队是多功能的，意味着成员拥有在每个冲刺中创造价值所需的所有技能。
- 整个Scrum团队对每个冲刺中创造有价值的增量全权负责。
你需要一个跨职能的团队来确保每轮冲刺都能产出有价值和用处的增量。如果团队是按职能划分的，那么需要UX团队先于开发团队工作（正如尼尔森诺曼集团建议的那样），但这意味着UX团队无法在每个冲刺中交付增量，而只是为开发团队创建待办事项。这可能也让开发团队难以在每个冲刺中产出有价值的增量。如果我们不能用可工作的软件作为进展的主要衡量标准，那么除了依赖估算之外，我们还能做什么？这就是为什么Scrum团队会更关注故事点和速度，而不是客户和价值。但正如敏捷软件开发宣言的第一个原则所说：
我们最高优先的是通过尽早和持续交付有价值的软件来满足客户的需求。
这意味着如果你不能持续为客户提供有价值的软件，那你做的就不是敏捷的。如果一个Scrum团队不能在每个冲刺中交付有价值的、有用的增量，那它就不是真正的Scrum团队。在他的关于“暗Scrum”的文章中，Ron Jeffries（也就是之前提到的宣言中的Ron Jeffries）指出了增量所起的关键作用，以及我们所了解和厌恶的大部分“Scrum”的压迫性正是由于缺少增量而导致的。
…我们的产品增量越真实，就越能促使人们更加关注现实，并依据实际情况进行管理。与我们通常的假设不同，我们的领导者并不是愚蠢的。他们正尽最大努力利用现有信息。如果我们能提供给他们更好的信息，比如可工作的软件，他们将开始使用这些信息。通过利用这些信息，他们将减少不必要的压力和滥用。
我们有理由不去这样做。其中一个原因是组织问题：我们被划分成了职能团队，这从操作上（或政治上）使得组建跨职能团队变得非常困难，甚至是不可能的。另一个原因是正如Jason Godesky在他的文章中所提到的，将大型项目切割成垂直切片实际上是非常困难的。另一个原因是即使我们做到了这一点，正如Ron Jeffries在同一篇文章中写的那样。
…功能增量必须真正有效。它必须经过测试、集成，准备好发布，包含我们承诺完成的所有待办任务。
这是 Scrum 挑战我们常规工作方式的部分，所以我们不改变我们做事的方式；而是告诉自己我们不一样。这在其他地方可能行得通，但对我们来说可能不行，所以我们只能妥协。实际上，这种情况几乎从不属实。我们假设那些已采用这种方法的组织这样做只是因为对他们而言相对简单，而不是承认事实：这对他们同样困难，但他们仍然这样做以实现他们的目标。
《Scrum指南》并没有深入解释增量为什么重要；它只是告诉你需要遵守指南里的所有规定，其中部分内容相当简略，但这点容易被忽略。这是框架中最关键的一点，可以说是整个框架的心脏，但从一次简单的阅读中，你可能会忽略这一点。为了保持这份14页指南的简洁，《Scrum指南》期望读者能够认真对待这份文档，并通过多次实践来理解其背后的逻辑和如何配合工作，但由于很少有组织会组建跨职能团队，并期望在每个冲刺结束时都能得到一个可以实际运作的增量，因此，很少有人能够真正体验到这一切是如何运作的。
自管团队我们有时会听到关于自我管理在加班修复程序错误或应对服务器故障时的重要性，但 Scrum 团队决定在冲刺期间减少新功能的开发，以便专注于编写更多单元测试，或者偿还一些累积的技术债务，这又有多常见呢？团队决定雇佣新成员或移除某个成员，这又有多常见呢？
在许多敏捷转型中最大的问题之一是经理们在Scrum中的角色。他们是Scrum大师，还是产品负责人？《Scrum指南》实际上对这个问题有明确的说明。
[Scrum 团队]也是自我管理的，这意味着他们自己决定谁做什么，何时做这件事，以及如何做这件事。
Allen Holub 是我最喜欢的 Scrum 的批评者。他写过并且谈论过这个问题很多次，解释了 Scrum 为什么经常失败。经理们认为敏捷是对他们的一种生存威胁，因此他们会自然地联合起来破坏敏捷。有时这是故意的，但更常见的是无意识的行为。他们在寻找自己在新秩序中的位置，调整流程来适应自己。他们甚至可能说服自己，这样可以减轻开发人员的负担，让他们更专注于工作。正如 Mike Cohn 所说，
敏捷不是关于微观管理，而是团队自我管理和自我服务，且是为了他们自己的利益。
尽管管理者希望有所帮助，通过卸下团队成员的管理任务，他们实际上剥夺了团队的自主权，从而使管理过程变成了压迫性的控制工具。
Allen Holub 强调，如果敏捷转型意味着管理层将全部失业的话，那么我们就确保了转型的失败。要成功，转型需要为所有当前角色将被取消的人提供一个未来。他说，在一个以人为核心的公司里，他们会寻找方法让管理者根据自己的技能和兴趣，转变成 Scrum 主管、产品负责人或团队成员。如果这意味着需要新的培训，公司可以提供。而且，如果他们不想成为新敏捷未来的部分，公司应该继续支付他们的工资和福利，同时帮助他们找到更合适的新职位。
没有这样的人性化措施，管理就会成为阻碍敏捷性的顽固障碍，反而与我们的努力背道而驰，只为自保。一种导致组织内部派系对立的转型不太可能成功——尤其是当对立最激烈的一方正是掌握所有决策权力的一方。
大卫·马奎特 提倡“领导者-领导者”的领导方式，其原则是尽可能让最了解情况的人来做决定。这通常指的是实际做工作的人，而不是经理或高管。Scrum 通过定义自管理的 Scrum 团队来推动这种领导方式。在每个冲刺中交付有价值和有用的增量是一项重要责任。如果我们不赋予 Scrum 团队做出必要决策的权力，我们也不能期望他们承担起这一责任。你无法做到敏捷，因为存在一个命令和控制机制，你需要通过该机制批准你的决定，这会增加延迟，使检查和适应的循环更长。如果你的工作由某人管理，那么你就不再是自管理团队的一员——因此，根据 Scrum 指南，你的团队无论是什么，它都不是一个 Scrum 团队。
猴子爪子与Scrum的问题根据一项调查由Parabol发布，企业尝试提高灵活性的主要原因有：
- 更快地将商品送到客户手中 (83%)
- 提升生产效率 (76%)
- 提高透明度和可预测性 (70%)
- 提升效率 (69%)
- 改进工作组织方式 (68%)
Scrum 主要被看作是一种增加产出的工具，以及仅对软件开发团队相关的事项。如果软件开发需要一名 Scrum 主持人，则经理可以担任这一角色；如果需要一个产品负责人，项目经理可以担任这一角色。我们可以轻松地将现有的角色和流程映射到 Scrum 的术语中。我们可以设置 Jira 实例，并安排冲刺审查和每日站会。所有这些都不会给我们的日常工作带来重大障碍。但是，一个跨职能团队可能会打破公司现有的部门划分（以及围绕这些部门建立的报告层级）。自我管理的团队可能会威胁到整个组织的管理层。这样的建议超出了敏捷转型的范围，因为真正的目标并不是将组织转变为一个更敏捷的组织，而是将开发团队转变为一个能够产出更多成果的团队。
这就是为什么组织常常对敏捷转型的动荡初期阶段（在Tuckman模型中的“动荡”和早期的“规范”阶段）感到不耐烦，当新的变化扰乱工作流程时。这时许多组织会介入，要求对Scrum进行修改，使其“更具问责性”或“适应性更强”以“更好地符合”他们的工作。这通常意味着更加关注故事点、速度和其他指标，以确保业务能够维持团队的输出水平。戈德哈特法则开始生效，当团队变得擅长生产他们负责的指标时，即使这些指标与实际产出无关，即使他们生产的实际工作软件并没有比以前多。
Scrum 无处不在的原因也是它失败的原因。它获得了作为组织快速增加开发团队产出的简单方法的声誉。但由于它被视为增加开发团队产出的快速且相对无痛的方式，组织常常抵制这样的建议，即 Scrum 不仅仅涉及开发团队，或者对于那些不是快速或无痛的变更，或者如果这意味着产出暂时下降。正如我们之前所说，组织常常忽略的 Scrum 指南中的两个关键部分，正是那些超出开发团队范围并要求组织进行真正变革的部分。再次引用 Allen Holub 的话：
敏捷性超越Scrum我希望Scrum联盟不会因为我讲了这句话就吊销我的认证，但我觉得Scrum可能已经过时了。Scrum的核心在于检查和适应的循环。正如我经常引用的Dave Thomas所说，敏捷性的基本原理是：
- 弄清楚你现在的位置。
- 朝着你的目标迈出一小步。
- 根据学到的东西调整你的理解。
- 回到第一步。
《Scrum指南》中描述的Scrum确实做到了这一点，但它被市场推广为万能药，以至于企业忽视了让Scrum成功运作的关键部分。正如Tim ‘敏捷水獭’ Ottinger在他的博客中提到的：
问题的起点在于，我们意识到几乎所有的软件开发政策与流程都是为了防止软件发布。
所以当组织决定采用或舍弃哪些Scrum部分时，他们更倾向于他们熟悉和理解的过程——这些过程主要是为了防止软件发布。这使得我们算法中的第二步执行起来更加困难，这一步会延长周期，使得整个过程变得更长，最终侵蚀了整个练习的目的。
当它在20世纪90年代开发时，每两周向客户交付有价值的软件是一个激进的想法。Scrum提供了一种快速检视与调整的周期。如今，持续交付意味着我们通常每天多次向客户交付有价值的软件。
持续交付让Scrum变得不再必要。敏捷性——即如果你认真对待这些价值观和原则，你将采取的工作方法——仍然和以往一样重要。Scrum本可以成为一股巨大的正面力量；遗憾的是，它却变成了一个压迫和滥用的工具。更讽刺的是，解决这些问题的方法仍然存在——在Scrum指南本身中——到了这个时候，是否还有希望拯救Scrum脱离敏捷工业复合体？
也许现在是时候研究超越Scrum的敏捷性了。持续交付这个名字来源于宣言中提到的第一个原则，将这一前提推进到一个在2001年看来几乎是不可能的程度。它使我们能够采取更小的步骤，小得可以每天多次执行Dave的算法。
在前面提到的《更快且更可预测》这篇文章中，Tim Ottinger 建议了一种在不牺牲我们对质量标准的情况下摆脱我们通常的软件交付流程中的循环、队列和延迟的方法来提高软件交付效率。
把那些原本会分工的人员召集起来，让他们一起合作完成一个项目，并进行边做边审。这包括开发人员、测试人员、用户体验、用户界面、安全等方面的人员。
最重要的要保留下来的一点是我们几乎在尝试之前就放弃的部分：自主的、多功能的、跨职能的团队。事实上，我们需要做得更进一步。仅仅组建这样的团队是不够的，我们还需要让集体开发成为常态。这是一种特别好地互补持续交付的技术。
宣言中只有一项规定的行为，那就是最后一条规定。
每隔一段时间，团队会反思如何提高效率，然后根据情况进行调整。
并不需要一个框架才能变得敏捷。你需要一个有决心变得更敏捷的团队，需要一个愿意尝试新方法的组织，还需要定期的回顾会议。如果你有这些，那么一个好的回顾会议将产出你所需的流程和实践，创造一个适合你工作特点的敏捷方法。