克鲁姆的5个空白
我最近在一个企业社区实践活动上发表了讲话。我的会议提出了一个有用的模型来识别系统中的指标，以预测系统的失败。首先，我们将该模型应用到每个人都可能涉及的日常系统中。接下来，我让与会者绘制他们自己的系统。当我一步一步地向他们介绍我的模型时，我使用Scrum作为我的示例系统。完成工作表后(见下面我完成的工作表)，与会者能够看到是否有任何“空白”他们的系统。间隙提供了一个指示，相应的系统有失败的风险。
澄清一下，在交付团队层面上，我认为Scrum框架是管理产品开发的可靠方法。但是在整个交付组织中Scrum又如何呢?使用这两种要改变任何规模的组织，你需要知道的三件事和我的模特，我在更广泛的背景下看Scrum。有了这个，我注意到了5个主要差距。
Scrum中的5个空隙是什么？
我的模型将将任何系统分为5个区域：明晰、承诺、仪式、进步和习惯。下面我要指出的空白是Scrum指南中没有提到的。
差距1：清晰度
在Scrum团队之上的组织结构(项目组合、程序、产品)是什么样的?我们需要有共同的理解。在Scrum团队之上的组织治理(预算、依赖关系、风险、质量等等)是什么样的?Scrum团队之上的组织有哪些必要的度量标准和工具?有些组织非常庞大，分布非常广泛。你将如何衡量整个交付系统的健康程度?
差距2:承诺
在迈克他把这称为责任。考虑到我的模型的广泛适用性，我更愿意称之为承诺。承诺可以是任何资源。那么，对企业内所有的领导和Scrum团队进行Scrum培训需要多少资金和时间呢?采购、安装和培训用于管理和报告交付系统健康状况的工具可能需要多少资金和时间?最后，我们需要领导团队同意遵循Scrum框架(或者更确切地说，Scrum团队正在遵循它)。
差距3:进步
正如我在我的帖子中注意到生产力模式，如果你缺乏进步，你就会失去动力。如果你失去动力（或者应该如此大胆地说速度或吞吐量），你将失去对系统的承诺。那些资助努力的人（Scrum团队之外的人）需要了解进展的进展是在某种方式对他们重要的。有价值的时间是多少？Scrum团队是否可预测释放级别（发布烧纳/烧限图）？我们甚至建立正确的东西吗？（产品合适）我们是否正确地建立了什么？（质量）
差距4:仪式
仪式可以是活动或会议，作为您交付系统的一部分。首先，让我们从产品愿景开始。Scrum团队有几周的地平线（Sprint）。在几个月，季度或年内观看或实现愿景。阅读Scrum指南，您不会看到想象提到了一次。Scrum指南中也没有组合或发布计划的概念。除非你有一个交付能力，允许你在每个sprint结束时发布产品，否则我不能足够支持发布计划。除此之外，良好的项目组合规划确保我们有一个平衡的交付系统，并确保我们有能力根据路线图做出承诺。
差距5：习惯
考虑到我上面列出的例行公事，你应该养成定期进行愿景回顾的习惯，定期计划投资组合计划/回顾，并确保你坚持执行发布计划。
结论
我并不是建议您放弃Scrum。但是当你看到我上面列出的突出的差距后，在一个比单个Scrum团队更大的交付系统中，你应该考虑到Scrum指南中的多个。
评论（6）
Mike Dwyer.
你在这里和其他工作中引用的是scrumguidelines（www.scrumguide.org）定义scrum的内容。“Scrum不是建筑产品的过程或技术;相反，它是一个框架，您可以使用各种过程和技术。Scrum明确了您的产品管理和开发实践的相对功效，以便您可以改进。“
因此，真正的问题成为人们如何对本文的推移，并使用它们来提高您和您组织正在做的事情的效果。
简短的形式简单。好消息，我们发现了一个洞，我们如何使用它来变得更好。
此致
Mike Dwyer.
迈克，谢谢你的评论。我真的很喜欢你的问题，“所以真正的问题成为一个人如何接受这篇文章的一般性，并用它们来提高你和你的组织在做什么的效果。”我的回答是我们使用总体来激发对话。我们用它们作为我们可以锚定的东西，以了解人员和组织的问题正在努力解决。我知道太多的人引用Scrum指南，就像它是福音一样。当我要求探究有关在指南中没有明确写入的事情的问题时，我有时会得到一个空白的凝视。我想强迫（尊重）的思想交流。再次感谢你。最好的问候，德里克
Sunish Chabba.
嗨Derek，
我一直在关注你在系统设计画布上的工作，当我看到这篇文章时，它自然而然地激起了我的兴趣。是否只有我或者你也注意到这些差距揭示了Scrum(在Scrum指南中甚至在其他早期文本中定义的)从未试图提供答案的伸缩性问题。
产品管理、预算、治理和变更管理是我从上述差距中看到的其他主题，这是一个很好的开始，可以与客户开始对话，而不会让他们因谈论SAFe和其他伸缩框架而不知所措。
问候，
撒
Sunish，是的，我也观察到这一点。我认为Scrum框架的美丽是它是一个框架。它简单足以将其应用于许多情况和环境。我看到的挑战很多想要买和安装敏捷。你不能仅仅抓住货架并将其放入组织中。您必须通过较大的挑战思考，组织面临的（如您所指出的那样：...预算，改变管理）。我认为这就是为什么安全和其他缩放框架是卖这么好。你写了一些真正谐波的东西，这适用于这篇文章的另一个评论。“这是一个良好的启动与客户谈话的起点”。对对对！我看到使用我的画布（和这篇文章）作为一个简单的工具，以促进关于“其他一切”的尊重。最好的问候，德里克
杰夫斯特伊特马特
这是对迈克“三件事”讨论的绝佳赞美。组织可以采用Scrum来组织他们的交付团队，但是必须有一个框架以相同的方式使组合和产品工作过程保持一致。这就是敏捷与企业大规模实施敏捷的现实之间的差距。
谢谢杰夫！如我谈话（以及工作表）所指出的，交付团队之外的许多东西都可以杀死他们为组织产生价值的能力。如果我们希望Scrum不成为本组织的下一个失败的实验，我们需要有更多关于这些事情的对话。