基于团队的Scrum失败模式

我认为，当你在角色，仪式和神器方面停止思考scrum ...它开辟了谈话，看看你挣扎的scrum实现真正发生的事情。我们不再哀叹缺乏产品所有者......我们可以讨论为什么本组织发现这么难以阐明一个明确定义的团队的积压。我们不再谈论如何获得更好的烧毁图表......我们可以讨论我们的团队结构使其无法制定和符合冲刺的承诺。我们不是在谈论更好的Sprint计划的规则......我们可以谈谈为什么该团队正在努力获得足够的共享理解，以便每隔几周提供产品的工作测试增量。

在某些时候，我将在活动和结果之间写下界定的帖子，但我认为我们在这里玩得更广的社会问题。通过Scrum，我们知道我们需要清晰，问责制和衡量频繁间隔进展的能力。在某些方面，杰夫和肯实例化了一套帮助人们获得这些结果的规则。一旦Scrum开始主流，所有人似乎都记得是规则。他们忘记了规则背后的意义。我说这是一个社会问题，因为我认为人们在很多不同的地区这样做...不仅仅是工作......不仅仅是敏捷。想想你生命中的所有领域，因为没有任何真正了解他们想要完成的事情的情况，才能经历动议。

规则很重要。没有意义的规则毫无意义。

这给我们带来了什么呢?今天我想谈谈Scrum中一些比较常见的失败模式。这些就是我看到的人们在尝试执行Scrum时不断失败的方式。正如这篇文章的精神，我不想谈论每天的站立会议是如何变得糟糕的，或者人们是如何搞砸用户故事的，或者为什么Dev Manager同时也是ScrumMaster是一个问题。我想谈谈一些潜在的模式，我认为这些模式在团队之间是一致的，并且让Scrum变得更加困难。

积压

在我的经验中，未能制作一个良好的优先考虑的产品积压是近几次Scrum团队的根源。让我们从Sprint的尽头开始，看看一个糟糕的积压将对A的所有事情Scrum团队。在sprint结束时未能交付、糟糕的sprint评审、糟糕的回顾几乎总是与不明确的待办事项安排联系在一起。如果团队不能理解他们应该构建什么，他们通常不会完成任何事情，在sprint结束时也不会有任何工作。

那个呢冲刺吗?低效的日常站立会议，无法聚集，无法在sprint中直线燃烧……所有这些都是糟糕的计划会议的结果。你会问，为什么我们的会议安排得很糟糕?这就把我们带到了冲刺的开始。糟糕的计划会议几乎是由糟糕的积压造成的。如果在sprint计划会议上没有明确待办事项，团队就会花太多时间去创造“是什么”，而没有足够的时间去创造“如何”。

不理解“如何”，承诺是非常困难的。如果没有“如何'，那么难以弄清楚我们如何共同努力或合作。如果我们没有合作，每个人都在致力于自己的故事。如果每个人都在努力自己的故事，他们就没有在冲刺早期完成。如果我们没有早点完成，我们正在推迟到冲刺的尽头。延迟完成使得难以进行测试，从产品所有者获得反馈，我们最终遗漏了故事。缺少的故事导致速度不稳定，团队不可预测。

错过了故事，为错过承诺，坏演示，甚至更糟糕的回顾。这都是互联的。如果积压不在那里，Scrum工作中的任何东西都没有。许多球队根本没有积压。有些团队有一个充满了他们创造自己的技术任务的积压。有些团队有积压，充满了差不多近乎定义的大型模糊的用户故事。有些团队有积压，不符合所有投资标准。所有这些都使Scrum几乎不可能做得好。

糟糕的积压下面是什么?有时这是因为产品负责人的缺席，但即使有了产品负责人，这些问题仍然猖獗。解决这个问题的关键在于找出组织中谁拥有分解工作的知识和技能，做出权衡，并帮助团队开发对产品的共同理解。有时候是因为组织没有战略或者外部承诺太多。有时解决方案是一个好的产品负责人，有时是更好的规划和投资组合管理，有时我们需要更好的执行领导。解决这个问题可以有很多不同的层次。

团队

团队组成是在大多数组织中实施Scrum的另一个大问题。当我在VersionOne工作时，我对这个问题充满了热情。我一个接一个地培训客户，看到人们被划分在多个团队中，有大量外部依赖关系的团队，以及缺乏主题专业知识的团队……基本上，这些团队没有所有的东西来交付经过测试的产品增量。如果你不能建立正确的Scrum团队，我建议你找一种不同的方法来构建软件。它是那么重要!

想想一个崩溃的Scrum团队在Scrum中所破坏的所有东西。让我们假设您已经解决了产品待办事项列表问题，那么sprint计划是什么样的呢?你想在没人在场的情况下理解故事情节吗?你想把工作分解，却不让每个人都去解决问题?当你没有完成所有的外部依赖关系，也没有共享所有权时，你正在尝试冲刺?面对所有这些不确定因素，你如何进行评估，无论你多么努力都无法完成。

一旦我们离开计划会议，团队成员就会神秘地在sprint期间与其他团队一起工作。当团队需要他们的时候，他们却不在那里。团队成员在等待他们没有的东西，但是交付一个工作测试增量所必需的东西。当一个团队不具备成功所需的一切条件时，它就会削弱完成任务的紧迫感。速度不稳定，没人关心。没有人对产品的进展负责，团队成为受害者。

我认为我们没有花足够的时间作为一个社区来指导组织如何组建团队。当然，我们有一个完整的、跨职能团队的概念……但这在大企业中意味着什么呢?当我们需要许多团队来构建产品时，我们如何形成大规模的团队?我们如何在团队之间进行协调?当我们需要组建功能团队和组件团队时，我们该怎么做，我们围绕什么来组建他们。我想我说过这是我下一篇文章的主题。现在有许多好时光;-)

我想再说一遍，如果我们想正确地使用Scrum，我们真的、真的、真的必须认真地组建团队。如果你问我什么更重要——完成一个好的待办事项列表还是组建团队，我会觉得很为难。它们都是如此常见的失败模式……LeadingAgile已经达到了这样的一点，即任何参与的第一步都是在任何事情开始之前，帮助组织定义团队和定义待办事项创建过程。在没有积压的情况下培训错误的团队是徒劳的。

产品增量

我把产品增量留到最后，因为我相信如果你能解决前两个问题，那么解决第三个问题就会容易得多。我的经验是，一个完整的跨职能团队，如果对他们正在构建的东西有一个非常好的想法，如果有一个非常清晰的待办事项安排，那么他们几乎可以解决任何其他问题。他们可能需要被授权去做正确的事情，因为他们觉得自己没有时间去测试，或者在构建环境中工作，分支策略……但这是一个可以解决的问题。

如果我们假设一下,我们有一个良好的积压,我们有一个完整的Scrum团队,该集团还* *难以产生增量sprint结束时测试工作,这是当你开始研究技术实践和团队动力。我不是技术实践方面的专家，但我通常发现，如果我们能够获得接近每日构建的内容，让测试人员与开发人员一起工作(不管是否自动化)，让开发人员每天一起工作以交付用户故事，你就有机会了。

同样，假设有一个良好的待办事项列表，一个形成良好的Scrum团队，并且可能只有最少的技术实践。最常见的挑战是让人们一起工作，尽早交付产品，并且经常在sprint期间交付产品。许多开发者喜欢独立工作。许多人不想与同行和客户合作。没完没了地讨论如何执行这些计划会让人感到沮丧。人们只想躲到角落里编码。

在Sprint期间一起工作允许团队获得更多的事情，而不是以一堆仅部分完成的一堆东西结束冲刺。团队协作导致更令人预测的冲刺，更稳定的速度，开发的软件可以进行测试，可以进行成品，可以发出的反馈，并提供产品如何进展。所有这些都导致成就感和团队中的所有权感和戏剧感。

概括

这些是解决......和这种共同的失败模式的重要挑战......我不能保证这将是我围绕这一点的最后一件事。我觉得我可以永远继续。我真的希望我们所有人都可以停止专注于仪式，文物和Scrum的规则。我希望我们能够停止专注于10个提示，是一个更好的克拉克斯托斯特，或完美产品所有者的5个基本品质。我希望我们能够阻止专注于Scrum的规则和教条，并重新重组我们真正努力实现的目标。

在我看来，这都是关于我们将建立什么共享的理解。这一切都是关于拥有交付工作测试产品增量所需的一切的团队。这一切都是关于团队产生工作测试增量，而不携带技术债务和缺陷，使产品无法推出。这不是关于我们在Scrum中做什么或者谁来做……从根本上讲，这是关于所有这些事情最初的目标是什么。

这就是从长远来看的根本帮助我们成功的原因。

看看下一篇文章，大型敏捷团队中的结构、治理和度量标准。
看看之前的帖子，基于团队的Scrum的基础机制。