Scrum敏捷项目管理

将异常管理应用于敏捷团队

包含在 敏捷软件开发宣言 对于敏捷团队来说可能是不错的选择,但是组织中的大多数高级管理人员都希望有一个明确的解决方案,详细的计划和应遵循的预算。本文讨论如何使这两种不同的方法一起工作。

作者: TCGen的John Carter, //www.tcgen.com/

您的开发团队可能很敏捷,但是您的管理团队可能不是。高层管理人员生活在一个已知且预算有限且对投资质量负责的世界中。在一家上市公司中,他们已承诺要在一定的时间范围内按规格执行金融市场。

我们已经与多个组织一起试用了一种模型,该模型在敏捷开发团队和高级管理层之间建立了桥梁。这座桥建在 异常管理.

并非每个问题都有一个敏捷的解决方案

敏捷是一种更快地交付更多功能的好方法,但并非所有问题都将敏捷作为其解决方案。这些较大的问题通常在团队外部。它们有可能对组织造成严重损害。需要敏捷之外的解决方案的问题包括:

  • 资金超过初始分配额的2倍
  • 质量太低,会影响品牌认知度
  • 导致一个或多个团队失败的依赖性
  • 降级效果如此剧烈,以至于损害项目论据
  • 监管问题(法律,贸易,安全,隐私)

在团队和管理层之间达成协议

我们在敏捷团队和管理层之间的桥梁通过在项目开始时创建的相互同意的框架解决了这类问题。每个项目都始于开发团队和高层管理人员,并与管理层达成协议。开发团队和管理层就MVP达成共识。他们通过创建3到5个参数来定义项目,以定义项目的成功。通常,这些因素包括产品的各个方面,例如功能,成本,时间和质量。该协议为每个参数定义了定量阈值。

建立边界条件

在以下来自家庭安全技术公司的物联网示例​​中,一家公司同意以下参数:产品和项目成本,功能,质量和进度。然后,他们同意每个参数的定量阈值。管理层与团队之间的协议规定,团队不得超过这些阈值。

为Scrum团队建立边界条件

建立了这些参数以及与每个参数相关联的度量之后,团队便可以使用带有故事点,冲刺等的敏捷流程,以商定的度量为目标。只要团队期望实现其目标,高级团队就可以让团队工作而不会受到干扰。它不会干扰要求达成协议的团队进行审查和更新。管理层仅在有例外的情况下才介入,即团队报告说他们有危险超过一个或多个这些阈值。

升级过程

我们的模型还包括 升级过程 看起来团队似乎超出了商定的指标范围。这种升级过程始于团队通知管理层潜在的边界中断。团队指定他们可能越过哪个边界,并且团队还建议解决边界突破的方法。

然后,管理团队会在几小时或几天内回复开发团队–不是几周或几个月。如果高层管理人员同意团队推荐的解决方案,那么团队将立即实施该解决方案。如果管理层不同意团队的解决方案,或者需要重新协商量化目标,那么他们将召开面对面的会议和管理层,团队将根据需要就项目的新指标达成一致。

敏捷团队的升级流程

在敏捷与高级团队之间架起一座桥梁

已经发现,这种异常管理方法对于敏捷团队非常有效,因为敏捷团队的重点是增强能力和自力更生。这种方法满足了高层管理人员对可预测性和可靠性的要求,同时支持敏捷性和增强团队能力,从而鼓励了团队创新和问责制。

异常管理与清晰快速的升级流程相结合,在敏捷团队与具有外部承诺的上市公司中必要的更传统的计划方法之间架起了桥梁。它在瀑布环境中嵌入了敏捷。我们发现,这些混合流程不仅功能完善。他们是一流的。

关于作者

约翰·卡特 是技术公司广受尊敬的顾问,并且是``更快地创新产品:加速产品开发的图形工具''的作者。他是TCGen Inc.的创始人兼负责人。他曾为世界上一些最受尊敬的技术公司提供建议,包括苹果,亚马逊,思科,惠普,IBM和罗氏。