27 Sprint反模式

TL;DR:阻碍Scrum团队的27个Sprint反模式

欢迎阅读我们关于Scrum反模式系列的Sprint反模式文章，这篇文章不仅涵盖了三个Scrum角色，还包括涉众和IT管理。

你想在收件箱里收到这篇文章吗?你可以在这里注册并加入其他2.5万订阅者．

27 Sprint反模式

这张臭名昭著的Sprint反模式列表适用于所有Scrum角色以及其他角色:产品负责人、开发团队、Scrum管理员、Scrum团队本身，以及利益相关者和IT管理层。

Sprint产品负责人的反模式

• 没有订单:产品负责人在Sprint的大部分时间都不在，不能回答开发团队的问题。(因为Sprint Backlog是紧急的，新的工作可能被认为是实现Sprint目标所必需的，这种态度可能会让开发团队处于黑暗之中，冒着Sprint目标完成的风险。)
• 执著于任务的PO:一旦产品待办事项列表项成为Sprint待办事项列表的一部分，产品负责人就不能放手。例如，产品负责人增加了需求的范围。或者，一旦团队将问题纳入Sprint Backlog，他或她就会改变接受标准。(有一条明确的界限:在产品待办事项列表项变成Sprint待办事项列表的一部分之前，产品负责人是负责任的。然而，一旦它从一个backlog转移到另一个backlog，开发团队就开始负责了。如果在Sprint期间变化变得非常严重，团队将协作决定如何处理它们。)
• 僵化的阿宝:产品负责人不能灵活调整验收标准。(如果一项任务的工作表明，商定的验收标准不再可实现或浪费，Scrum团队需要适应新的现实。盲目地遵循最初的计划违反了Scrum的核心原则。)
• 延迟订单:产品负责人不接受Sprint Backlog中完成的项目。相反，他或她会等到Sprint结束。(产品负责人应立即检查满足验收标准的任务。否则，产品负责人将在Sprint中创建一个人工队列，这将不必要地增加周期时间。这个习惯也会让实现冲刺目标处于危险之中。)
• 滥用Sprint取消:产品负责人取消sprint，将他或她的意愿强加给团队。(产品负责人有权取消sprint。但是，如果没有严重的原因，产品负责人不应该这样做。产品负责人也不应该在没有事先咨询开发团队的情况下中止Sprint。也许，团队已经知道如何挽救sprint。最后，滥用取消特权也表明存在严重的团队协作问题。)
• 不取消Sprint:产品负责人不会取消一个Sprint目标不能再实现的Sprint。(如果产品负责人确定了一个统一的Sprint目标，例如，集成一种新的支付方法，然后管理层在Sprint中期放弃了这种支付方法，继续在Sprint目标上工作将是一种浪费。在这种情况下，产品负责人应该考虑取消sprint。)

开发团队的反模式

• 无在制品限制:没有进行中的工作限制。Sprint的目的是交付一个潜在的可交付的产品增量，为客户提供价值，从而为组织提供价值。这个目标需要集中精力去完成在Sprint结束时达到Sprint目标所必需的工作。流程理论认为，在制品(WiP)的限制可以提高团队的生产力。在制品限制定义了开发团队可以同时处理的最大任务数量。超过这个WiP数量会导致创建额外的队列，从而降低开发团队的总体吞吐量。周期时间，即开始和完成一张票之间的时间，可以衡量这种效果。)
• 挑选:开发团队挑选工作。(这种影响通常与丢失的在制品问题重叠。人类的动机是短期的满足。解决黑板上的另一个难题感觉很好:编写一个新任务。与此相比多巴胺修复在代码审查期间，检查其他人如何解决另一个问题的回报就不那么高了。因此，例如，您经常会注意到在代码-评审列中排队的票据。这也是开发团队还没有完全自组织的标志。也要看看支持这一概念的每日Scrum事件，并在Sprint回顾期间解决这个问题。)
• 董事会过时的:团队没有及时更新Sprint板上的票来反映当前的状态。(Sprint板，无论是物理板还是数字板，不仅对协调开发团队的工作至关重要。它也是Scrum团队与涉众沟通的一个组成部分。一个不是最新的董事会将会影响涉众对Scrum团队的信任。信任恶化可能会导致利益相关者采取相应措施。因此，(管理)钟摆可能会回到传统方法。回到PRINCE II的路是用废弃的木板铺成的。)
• Side-gigs:开发团队正在处理董事会上不可见的问题。(虽然马虎是可以原谅的，但是抽走资源和绕过产品负责人(他对开发团队正在创建的投资回报负责)是不可接受的。这种行为也标志着“团队”内部的重大冲突。考虑到这种不信任的表现——为什么工程师不在Sprint计划期间或之前解决这个看似重要的问题——开发团队可能是一个相当大的群体。)
• 镀金技术:开发团队通过将不必要的工作添加到Sprint Backlog的产品待办事项项中来增加Sprint的范围。(这种效果通常被称为范围拉伸或镀金。开发团队忽略了与产品负责人的原始范围协议。无论出于何种原因，团队在没有事先咨询产品负责人的情况下扩大了任务。这种无知可能导致资源分配存在问题。然而，有一个简单的解决方案:开发人员和产品负责人需要更经常地相互交谈，从产品愿景到单个产品待办事项列表项，建立一个共同的理解，从而提高信任水平。如果产品负责人还没有和开发团队一起工作，那么现在就是重新考虑的时候了。)

Scrum Master的Sprint反模式

• 流中断:Scrum Master允许涉众在Sprint期间中断Scrum团队的流程。在sprint期间，涉众如何打断团队的流程有几种可能性。任何一个例子都将阻碍团队的生产力，并可能危及Sprint目标。Scrum Master必须防止它们出现:
  • Scrum Master在访问开发团队方面有一个自由放任的政策。特别是，他或她没有教育涉众关于中断的负面影响，以及这些影响如何危及Sprint目标的完成。
  • Scrum Master不反对部门经理将团队成员从团队中抽调出去，分配其他任务。
  • 最后，Scrum Master允许涉众或经理将每日Scrum转变为报告会议。这种行为会破坏开发团队的自组织，通过后门重新引入命令和控制，从而阻碍开发团队的生产力。)
• 缺乏支持:Scrum Master不支持在任务中需要帮助的团队成员。通常，开发团队创建的任务工程师可以在一天内完成。然而，如果有人在这样的工作中挣扎了超过两天，而没有表示他或她需要支持，Scrum Master应该解决这个问题并提供他或她的支持。顺便说一下，这也是为什么如果任务没有移动到下一列，就要每天在物理Sprint板上用红点标记任务的原因。(换句话说:我们正在跟踪工作项的年龄。)
• 微观管理:Scrum Master不阻止产品负责人(或其他任何人)向工程师分配任务。开发团队在没有外部干预的情况下组织自己。在这方面，Scrum Master是团队的盾牌。)
• # NoRetro:没有回顾，因为团队认为没有什么需要改进的。(没有所谓的“敏捷天堂”，在那里一切都是完美的。正如人们所说:变得敏捷是一段旅程，而不是终点，总有需要改进的地方。)

请注意:我不相信Scrum Master的任务是在Sprint板上移动票。如果开发团队成员认为这样做有帮助的话，他们应该在每日Scrum中这样做。Scrum Master也没有责任更新在线板以反映相应物理板的状态。最后，如果开发团队认为燃尽图表有帮助，那么团队成员也应该自己更新图表。# justsaying # scrummasterisnotascribeorsecretary

Scrum团队的Sprint反模式

• 特立独行者与Sprint Backlog:有人在没有事先咨询开发团队的情况下向Sprint Backlog中添加了一个项目。(开发团队对Sprint Backlog的控制——在工作负载的意义上——是使团队能够做出预测的核心。因此，范围本身在Sprint期间是不可触及的。Sprint Backlog的组成可能会发生变化，例如，当Sprint开始后出现一个关键的错误时。然而，将这样一个问题添加到Sprint Backlog中需要得到开发团队的批准，并且可能需要一定程度的补偿。另一个类似规模的任务可能需要回到产品待办事项列表。所有这些例外都有一个共同点，即开发团队集体拥有最终决定权。Scrum团队中的任何一个成员都不能单独地向Sprint Backlog中添加或删除一个项目。)
• 硬化冲刺:Scrum团队决定进行一次强化或清理冲刺。(这很简单:在Scrum中不存在所谓的强化冲刺。Sprint的目标是交付有价值的潜在可交付的产品增量。出于这个目的，开发团队创建了“完成”的定义，以确保每个人都理解产品增量“可交付”给客户所需的质量级别。因此，声明有bug的任务“已经完成”违反了Scrum协作的核心原则。强化冲刺通常是团队或组织采用敏捷原则程度较低的标志。这可能是因为团队还不具备跨职能。或者质量保证仍然由产品交付组织的一个功能性的、非敏捷的竖井来处理。或者，开发团队可能会感到交付的压力，以满足(任意的)截止日期，他们决定通过降低质量来偷工减料。不管是什么原因，在这种情况下，Scrum Master都有很多工作要做。)
• 发送Y而不是X:产品负责人相信得到x，开发团队正在处理y(这不仅仅是劣质产品待办事项列表细化的结果。这个反模式表明Scrum团队未能创建一个共享的理解。出现这种情况的原因有很多，下面就列举几个:
  • 产品负责人和开发团队成员在Sprint期间没有进行足够的交谈。(产品负责人太忙了，没有时间回答团队的问题或参加每日Scrum。或者，团队不在同一地点，等等)
  • 没有开发团队成员参与过用户测试或客户访谈。工程师们对用户的问题缺乏了解。(这就是为什么工程师也应该定期采访用户的原因。)
  • 产品负责人提供了一个过于细粒度的用户故事，而开发团队中没有人足够关心去彻底地查看。用户故事似乎已经准备好了。
  • 可能，用户故事完全缺少验收标准，或者现有的验收标准忽略了问题。不管是什么原因，Scrum团队都应该在下次回顾中解决这个问题。)
• 没有紧迫感:在Sprint的末尾没有潜在的可交付的产品增量。也没有理由取消Sprint。这只是一次普通的Sprint。(这表明Scrum团队缺乏在Sprint结束时交付的紧迫感。如果在Sprint结束时不能交付价值是可以接受的，那么Scrum背后的整个思想就会受到质疑。记住，Scrum团队将预测纳入决策、自主权和自组织。创建一个低级别的时间框看板并将其称为“Scrum”将不遵守这一协议。因此，Scrum团队的最佳利益是使每个Sprint的结果可发布，即使该发布不会实现。)
• 新入行的人:在Sprint期间，Scrum团队欢迎一个新的团队成员。他们还忘记在Sprint计划期间解决这个问题，从而导致过度扩展。(虽然在Sprint期间欢迎新队友是可以接受的，但团队需要在Sprint计划期间考虑到由此产生的入职工作并调整其容量。新的团队成员不应该是一个惊喜。然而，如果新员工让人感到意外，那么这是一种组织反模式。)
• 可变冲刺长度:Scrum团队将Sprint的长度延长了几天，以满足Sprint目标。(这只是制作敏捷书籍以匹配目标或度量的另一种方式。这不是敏捷;这是无关紧要的。停止对自己撒谎，解决团队结果没有达到Sprint目标的潜在问题。请注意:我不认为在年底的假期期间偏离Sprint长度是反模式。)

IT管理的Sprint反模式

• 在没有Scrum的情况下，所有人都要全力以赴:管理层在危急情况下会暂时放弃Scrum。(这是一种典型的不相信敏捷实践的表现，被命令和控制思维所滋养。最有可能的是，取消sprint并召集Scrum团队也可以解决手头的问题。)
• 重新分配团队成员:管理层定期将一个Scrum团队的团队成员分配给另一个团队。(只有在Scrum团队成员之间建立信任时，Scrum才能发挥其潜力。因此，团队的寿命至关重要。相反，在团队之间调动人员反映了一种具有项目意识的管理思想，这种思想植根于工业范式的团队成员级别的利用优化。它还忽略了Scrum团队应该自己选择的首选团队建设实践。所有成员都必须自愿加入一个团队。如果团队成员被强迫服务，Scrum很少会起作用。请注意:但是，如果Scrum团队决定临时交换队友，这不是一个反模式。专家以这种方式传播知识或指导其他同事是一种既定的做法。)
• 特种部队:经理直接将特定的任务分配给工程师，这样就绕过了产品负责人，忽略了开发团队自组织的特权。或者，经理从团队中移出一名工程师来处理这样的任务。(这种行为不仅违反了Scrum的核心原则。它还表明管理者不能放弃命令和控制实践。他或她继续微观管理下属，尽管Scrum团队可以以自组织的方式完成任务。这种行为表明了一种无知的程度，可能需要更高管理级别的Scrum Master来处理。)

Sprint涉众的反模式

• 向开发人员:涉众试图通过将小任务直接提交给开发人员来偷偷摸摸地执行。(第一个尝试不错。)
• 一切都是bug:涉众试图通过将他们的任务重新标记为“严重错误”来加速交付。(第2次尝试不错。特殊情况是修复错误和其他紧急问题的“快速通道”。根据我的经验，每个涉众都会尝试让他或她的任务符合这条快速通道。)
• 扰乱流动:涉众破坏了Scrum团队的流程。(参见上面的Scrum Master部分。)

结论

尽管Sprint本身只是所有其他Scrum事件的容器，但是有很多Sprint反模式值得观察。其中很多问题都很容易被Scrum团队或Scrum Master解决。然而，一些sprint反模式指出组织问题，这些问题可能需要不止一次sprint回顾来改变。

Sprint反模式缺少什么?请在评论中与我们分享。

✋不要错过:加入6800多强大的“动手敏捷”Slack团队

我邀请你加入“动手敏捷”Slack团队并享受来自世界各地快速增长的、充满活力的敏捷从业者社区带来的好处。亚博一百送一百

如果你现在想加入，你现在要做的就是通过谷歌表格提供您的证书，我会帮你注册的。顺便说一下，这是免费的。

相关的帖子

Scrum: 19 Sprint计划反模式。

28产品待办事项列表反模式

免费下载Scrum反模式指南．