Scrum框架的局限性在哪里？

By 老彦

September 28, 2020

By Mark Levison

Posted on January 29, 2019Posted on January 29, 2019

我经常在研讨会上被问到：“我们在哪里不应该使用Scrum？” 精简的回答是，在很多情况下Scrum框架都不适合。但是，要对这个问题给出更完整和有效的回答，首先，我们需要知道Scrum为什么和什么时候有效以及成功的关键条件是什么。然后，我们可以拿出不适合的示例。

Scrum在哪里适用？

Scrum是一种工具，用于建立能够成功应对不断变化的业务环境的自治，自组织，高绩效团队和组织。人们通常选择使用Scrum的原因，是因为他们想要更高的质量或更快的速度，而不明白这其实是高绩效团队的成果，而不是Scrum本身。

Scrum已在各行各业的团队中得到有效利用，包括软件开发（其成长起来的行业），硬件开发，制造，市场营销，人力资源…甚至战斗机和天然气厂设计！这些截然不同的行业的共同点是它们依赖一种知识工作形式，这可以被理解为主要涉及的非常规问题解决的工作，而这些问题通常需要创造性思维。知识工作得益于协作，这是Scrum团队的主要重点，因此Scrum非常适合这些行业也就不足为奇了。

由于团队是Scrum的核心工作单位，因此Scrum的许多局限性源于组织的团队结构。

Scrum良好运行的关键条件

现在了解Scrum在哪里有效，我们可以考虑在给定的工作环境中Scrum正常运行需要哪些结构基础。

知识工作–看起来似乎显而易见，但值得说明的是：组织（包括大多数零售和服务行业）基于日常任务的执行而无需执行复杂的问题解决或创造性思维，就不会从使用Scrum框架中受益。

共同目标–一群人只有在有共同目标时才成为一个“团队”。在软件开发中，共同的目标来自产品愿景和策略。在营销团队中，这可能以品牌策略或营销活动计划的形式出现。无论从事哪个行业，这个目标必须使所有团队成员的工作团结在一起，比他们各自的做出的贡献更重要。没有一个共同的目标，就没有真正的凝聚力团队，凝聚力是关键。

足够的挑战–与“共同目标”并驾齐驱的是问题必须具有足够的挑战性，以至于人们独自一人无法完成工作。如果人们可以在不与他人互动的情况下工作并且仍然实现自己的目标，那么他们通常会选择这样做。问题的难度必须保证使用团队，否则Scrum只是不必要的开销而已。

专注的团队成员关系–在许多场合下多任务处理的成本已显而易见，并且不再像从前那样被视为一种理想的技能。指派人员到一个以上的团队中工作会迫使他们执行多项任务，从而降低他们的生产力。任何形式的多任务处理都会使人们减少产能。将他们分配给多个团队是最糟糕的事情。由于他们从一种工作环境切换到另一种环境时的延误和重新集中精力的消耗而降低了他们的产能，并且团队在等待该人员投入工作前将遇到瓶颈。最终，犯错误的数量将增加，部分原因是这些人切换环境时候会忘记关键细节。证据表明，人员专注在一个团队（只有一个团队）会使所有相关团队的吞吐量提高一倍。没有专注的团队成员关系，所有群体注定会降低生产力，而真正的团队（还不算指高绩效团队）就永远不会成立。在这种环境下，Scrum将受到极大的束缚。

稳定的团队成员关系–有效的团队需要时间才能组建。新团队需要6到8个月的时间才能形成真正有效的凝聚力。此外，每次成员变更时，团队的生产力都会暂时下降。几个月后，他们可能会恢复实力，甚至可能最终有所提高，但是有些团队永远都无法恢复。在团队成员频繁更换的情况下，团队将始终处于较低的绩效水平。

较低的变更成本–敏捷的时代已来临，因为软件变更的成本已大大降低。多年来的许多工作都集中在进一步降低进行变更的成本上-从持续集成和测试驱动开发，到DevOps和行为驱动开发。现代软件开发工作中的变更成本不是零，但比绿色屏幕和大型机要低得多。为了使任何口味的敏捷都能在新环境中取得成功，降低变更成本（甚至是在后期）必须成为重中之重。如果进行变更，在工作中会产生大量成本，那么敏捷/ Scrum就不太实用了。

可计划的– Scrum团队通常以两周的Sprint进行工作，因此他们需要至少能够提前计划那么长时间的工作并允许进行小的更改。例如，一个软件开发团队拥有足够的灵活性，可以在sprint中期解决一个生产支持问题，而不会影响Sprint的主要工作。营销团队可以根据收到的有关客户行为的新数据来调整其营销活动。实际的限制是至少有一半的团队工作是可计划的。整个业务模式都是为了响应不可预测的客户需求的公司，如果使用Scrum来组织未来的工作，无法从中受益。注意：在维修行业之外，很少有企业能够在纯粹的基于响应的业务上长期生存。

被赋权的–团队只有在团队成员感到自治的情况下才能组建。 Scrum通过将团队建立为自组织的方式明确了这一点。希望这绝不是缺少的关键条件，但是，如果确实如此，尝试应用Scrum并不会帮助团队变得自组织和高效，但可能会暴露出问题，因此可以先解决此问题，然后再继续进行。

跨技能是可能的– Scrum（和看板团队）通过共享技能消除瓶颈，直到多个团队成员始终能够解决延迟。瓶颈是实现高性能的根本上重要的障碍，组织最终必须解决它们。丰田的方法是向人们支付更多报酬，以便能够处理多个工作站。在医疗保健领域，有些司法管辖区开始通过允许以前仅由医生完成的某些工作现在由护士或执业护士来解决此问题。同时，在某些工作环境中，由于法规，法律或根本不同的技能领域（例如，艺术家和金属工人），跨技能的适用性或价值可能受到限制，Scrum的价值也受到限制。

早期交付和测试–在Scrum中，我们不认为对用户需求的期望是正确的。相反，我们希望尽早交付产品并收集反馈。我们在产品发现而非创造的方式中工作。在无法在每个Sprint结束时交付有效产品的环境中，我们无法收集反馈。解决方案是在每个Sprint的末尾找到要展示的内容并获得反馈。

一起办公–将所有团队成员都放在同一房间仍然是最佳选择。人类已经经历了数百万年的面对面互动，因此这仍然是组建协作团队的最佳方法。尽管远程工作和分布式团队目前在许多企业中很流行，但这些所带来的挑战却是巨大的，并导致高性能团队需要更长的成长时间。如果绝对不可避免地要采用分布式的团队，则应用Scrum做法（例如每日站立）将更具挑战性，需要适应过程。在分散的团队中仍然可以有效地实践Scrum –只是难度要大得多。

Scrum应用不理想的例子

因此，既然我们了解了Scrum的工作原理以及成功的条件，以下我们的排序是从Scrum最不可能提供帮助的团队到虽有挑战性但仍然可以受益的团队。

建筑施工–当一个团队负责浇筑混凝土或铺路时，变更的成本实际上就是工程成本。总体而言，敏捷方法仍然可以使用，但是会增加成本。考虑精益建设，帝国大厦和伦敦碎片是这类方法的例子。

服务台和维修服务–组织中的人员提供数字或基于电话的支持服务时，他们的工作确实涉及“知识工作”的关键条件，但这完全是由中断引起的。他们可以开始处理一个问题，但是当打来的电话涉及到更重要的问题时，他们必须进行切换。这种模式在一天中可能会重复多次。这不符合“可计划的”条件，因此Scrum在这种情况下将无效。考虑使用其他工具（例如看板）来改善通过任何系统的流程。这也可能适用于其他组织和服务-基本上在知识是主要要求但工作不可计划的任何地方。

后台操作–许多组织都有从事所有后台工作的小组，例如财务和其他相关部门。其中大部分工作（发票，费用跟踪和其他簿记工作）都是由独立工作的个人有效完成的。尽管这项工作是基于知识的，但它通常是重复性的，因此不会具有挑战性。这些小组通常缺乏清晰的愿景或共同目标。我们仍然考虑使用看板而不是Scrum，作为更好地了解这些小组内部工作流程的工具。

基础架构和技术–大多数组织还拥有配置笔记本电脑，服务器，安全性，网络，防火墙和其他技术基础架构的人员。与后勤工作相比，这项知识工作没有那么重复，而且更具挑战性，并且它可以从协作中受益，因为问题通常需要多个技能来解决。这些小组通常也有一个共同目标（例如，保持内部用户的生产力和安全性）。但是在许多情况下，他们的计划外工作超出了计划内工作。但是，Scrum可以通过关注团队的计划外工作量，从而帮助他们投入工作以减少这些工作。

现有的商业应用–组织经常将许多后端软件（例如Gmail，QuickBooks，Expensify）外包给云供应商。这很好，不过最终，会有足够多的应用程序需要偶尔更改（新用户，新记帐规则等）。这些应用程序都不需要一全职个人来维护，因此最终可能需要6-7个人来维护10-15个单独的应用程序。缺乏明确的共同目标，该小组不太可能成为一个团队。 Scrum可以工作，但价值可能有限。对于基础架构和团队而言，挑战在于他们的知识可能会分散，因为人们没有理由学习另一位团队成员所在的领域。无论团队选择Scrum，看板还是其他框架，这将仍然是一个问题。考虑问问该小组是否可以重组以创建一个可能实现共同目标的空间。另一种选择是，团队可以根据自己的情况来制定目标。这些灵感来自与Petri Heiramo的对话：

鉴于他们工作的“产品”显然不足以团结他们，因此讨论需要转移到比他们正在做的工作更伟大的事情上。他们想成为有史以来最好的支持团队吗？他们愿意有一半的时间做自己想做的事情吗？他们是否想不用做他们的工作，并尝试使其尽可能自动化？他们是否知道自己正在改善别人的生活，他们是否可以为此目的制定一些有价值的目标？

一种可能是问他们工作的快乐程度。如果他们不快乐，那么下一个问题可能是他们愿意努力使自己快乐。毕竟，他们的三个主要选择是：1）继续做自己在做的事情，并仍然不快乐； 2）做一些使自己更快乐，为自己的工作感到自豪的事情，或3）离开公司去做其他事情。显然，3是不理想的，也不是一个很好的起点，因此选择实际上应该在1到2之间。然后下一步是问他们是什么使他们对工作感到高兴和自豪，是什么使他们对工作感到不快乐和羞愧。这可以帮助他们建立共同的目标，使他们变得更快乐，并找到纠正措施的起点。可能会讨论如何衡量幸福和自豪感（即如何知道他们正在朝着自己的目标迈进）。只要他们在工作上取得了一些引以为傲的具体进展，他们可能会达成一些自我奖励的约定（例如星期五的啤酒），进展可以是：

消除最深层的信息瓶颈，那些能让他们在休假的时候还要带着工作压力的阻碍。
清除他们最严重的技术问题。
使脾气暴躁的客户对其团队/服务感到满意甚至高兴。
建立一些新的实践来提高生产率或减少反馈周期。

单独的工作-任何没有合作前景的业务问题（每个人或公司都孤立工作），也不会直接从Scrum中受益。毕竟，没有团队可以成长。在这种情况下，请考虑“个人敏捷”和“个人看板”。

团队成员分布在多个团队，没有稳定的成员关系– 这让我无法想象能有一个理想的业务环境。如果是这种情况，Scrum能非常有效地工作以突出组织上的障碍，但不会帮助解决问题。在每个研讨会中，我们都讨论Scrum是发现问题的工具这一事实。从长远来看，当组织认真对待去解决Scrum发现的此类问题（而不仅仅是管理它们）时，Scrum就能成功。

我们对Scrum的应用会有不少限制，但是它们比大多数人想象的要广泛得多。

感谢Petri Heiramo为现有商业应用维护团队提供的建议和远见卓识。

原文链接：https://agilepainrelief.com/blog/what-are-the-limits-of-the-scrum-framework.html