我们如何在6个月内将周期时间从164天减少到8天
背景
2020年12月，我的朋友Adrian Galarza我还在Scrum.org上做了一次Scrum Pulse网络研讨会-一个周期时间旅程:6个月164至8天总结了Adrian的Scrum团队的旅程。我们在网络研讨会上讨论的一些关键主题是……
- 在我们的上下文中，我们如何定义“周期时间”?
- 为什么企业应该关心缩短周期时间?
- 在为期4年的敏捷实施过程中，整个组织做了哪些调整?
- 当这个旅程开始时，这个特定的敏捷团队面临着什么挑战?
- 这个案例研究的具体敏捷团队做了哪4组关键的调整?
- 减少周期时间的7个主要结果是什么?
- 除了缩短周期时间外，在提高预测可靠性和吞吐量方面还做了哪些可衡量的改进?
- 使这些改进成为可能的7个关键角色和社区是谁?
- 如果您想在您的环境中创造类似的结果，我们希望您考虑的6个关键建议是什么?
- 你怎样才能了解更多呢?
由于我的时间管理很糟糕，我们无法在网络研讨会上回答所有的问题，所以我们在这个博客中回答。如果你看了视频并复习了网络研讨会页面上的幻灯片，你可能会从阅读这篇博客中获得更多的价值-一个周期时间旅程:6个月164至8天
我们将与会者的问题分为3大类，并回答如下:
组织变革领导
愿景:改善这个周期的任务和愿景是什么?
我们试着让每个人都遵循敏捷价值观、敏捷宣言，并改进整个系统的流程。这些更像是指引我们的北极星，而不是具体的愿景或任务。
指标:你使用了什么指标?
我们使用标准指标，比如……
- 速度——“完成”的故事点数量(国防部包括在生产中部署和可用)
- 周期时间——一个Sprint准备好的PBI从活动到“完成”所需的营业天数
- 缺陷计数-开放缺陷的累积计数
- 在制品老化-已开始但未完成的pbi的平均寿命
- 速度达到-实际速度为目标速度的%。
执行报告:如何将进度报告给习惯于甘特图类型报告的执行管理层?
我们在sprint评审中评审进度，我们的涉众几乎总是会参加。我认为这是最重要的。
我们还建立了按需指示板，其中包括高管们最关心的指标趋势……
- 发布燃尽
- 带不确定性锥的发布预测
- 开放的缺陷
- 开放的障碍
最重要的是，我们已经建立了一种心理安全、透明和定期、可衡量的改进的文化，这为我们的团队赢得了利益相关者的信任。
利益相关方参与:scrum主管如何让团队之外的涉众参与进来并进行更多的合作?
这需要在Sprint评审中进行多次对话，以及与利益相关者进行一对一的讨论。此外，它还需要各级领导的一致和一致的信息。
改变电阻:你是如何克服那些想要采用传统瀑布式工作方式的人的阻力的?
这需要我们所有领导之间的一致，以及他们向所有团队传递的信息的一致性。这也将我们的部署从变更控制团队中分散出来，并给予scrum团队更多的自主权。我们还将遗留的部署流程简化为CI/CD管道，从而消除了频繁部署的痛苦摩擦。
角色和职责
博:产品负责人应该在IT部门还是业务部门?
在我看来，我会首先寻找订单中的定义特征。我会寻找那些能够融入团队、对角色有积极性、受到利益相关者信任、能够快速学习的人。除此之外，你还可以对你的产品相关的业务流程有深入的了解。这篇博客可能会帮助你为这个角色选择合适的人专业Scrum产品负责人:初级工作描述
芭:你是如何克服英航不理解系统如何构建的挑战的?
以前扮演BA角色的人通过帮助改进backlog重新解释了她的角色。我们没有一种文化，认为像英航这样的人应该知道系统如何构建的所有答案。相反，我们建立了一种文化，专注于提出正确的问题，让团队成员能够安全地表现出脆弱，承认他们不知道答案，让团队成员能够安全地请求和接受帮助。
测试人员:你在上下文中使用了“测试者”这个词。Scrum允许测试员吗?
我使用这个词是在他们当时所执行的功能的上下文中，而不是作为一个角色或头衔。在我的团队中，我们以手动和自动的方式进行功能测试和回归测试。我们的开发人员、中小企业、产品所有者和最终用户也在做这些工作。
UAT:你是如何克服由于老式的UAT方式(例如在开发、QA、UAT等环境中)而导致的周期时间延迟的?
为了缩短反馈循环并降低风险，我们的业务涉众是Scrum团队的一部分，并在Sprint中执行UAT。UAT是国防部的一部分。
节奏和可靠性
节奏:你们一开始的冲刺节奏是怎样的?改进后的可持续节奏是什么?
我们的团队一直保持着两周的冲刺。除了所有5个scrum事件之外，我们还在sprint的中途添加了一个预先计划会议，以展望下一个sprint。这让我们了解到接下来会发生什么。虽然大多数用于下一个sprint的pbi已经细化了，但预先计划给了我们一个机会，看看我们是否需要调整或进一步细化下一个sprint中出现的任何pbi。
可靠性:你如何帮助团队创建可靠的sprint预测?我的团队经常过度投入，通常会在某些点上拖延。
在团队发展的早期，我们也过度投入。这与领导层在信息传递方面保持一致。
所有领导始终如一地向团队传递了两条信息……
- 成功的最终衡量标准是交付有价值的、高质量的工作软件，而不是在Sprint计划结束时最大化预测的故事点。
- 重要的是尽量减少在制品和在制品年限。
我们创建了随需应变的仪表板，任何人都可以在任何时候使用它来可视化这些指标的趋势，我们在每次Sprint评审中检查这些趋势。
由于团队从领导那里得到了关于重要事情的一致信息，我们讨论了障碍并进行了调整。正如彼得·德鲁克所说，“被衡量的东西就会被管理。”
结论
请记住，组织是复杂的适应系统，由这些讨厌的、奇怪的、不可预测的有机体组成，这些有机体被称为像我这样的人类。盲目地复制粘贴在我们的环境中起作用的东西到你的环境中，并期望我们的结果可能会导致灾难。正如网络研讨会中提到的，了解指导我们的基本原则和价值观，并找到适合您的实践。为失败和失望做好准备。坚持，检查和适应，直到你做对为止。这是值得的。