将敏捷交付或连续交付集成到企业中的问题之一是周期的差异。公司倾向于按年度预算周期，较长的战略计划周期运行，尽管两者之间有时并不总是紧密协作。产品管理往往以产品周期为依据-根据产品类型的不同，周期可能长达数月至数年（例如，对于飞机而言）。项目倾向于分阶段（传统项目）或发布和迭代（敏捷）运行。反映高层管理人员需求的项目管理办公室，按月，按季度和按年度运行。
所有这些周期都存在一些潜在的问题：
- 周期不能很好地协调
- 每个人都希望其他人遵守自己的周期
- 财务，尤其是对于上市公司而言，似乎在推动其他人的周期
- 不同种类的项目和业务计划需要不同的周期
项目周期总是与财务周期发生冲突，因为项目不会自然地在12月完成。传统上，项目的成本方面是按日历报告的，但是在项目完成之前，价值方面通常是没有开始的。不兼容的周期困扰着开发人员和会计师，例如，每两周的工资单与每月的财务报告就不太匹配。
大多数周期不匹配与时间有关，但还有其他类型。例如，敏捷周期在2周的迭代中交付了部分结果。我说的是部分结果-工作的软件，但仅仅是应用程序的一部分；建筑作品，而不是整个建筑；要求，但仅提供迭代过程中完成的故事的详细信息。但是，许多公司治理周期都是围绕完成的结果构建的—完整的需求文档，完整的测试计划，完整的数据库设计。基于后一种模型构建的治理系统-由于周期不匹配，使敏捷项目难以在这些组织中“治理”。
在我的前世中，作为瀑布方法学家（是的，我承认），在1980年代，我使用了一种称为Warnier-Orr方法的方法，其中包括一种称为Warnier-Orr图的方括号样式图。解决周期冲突的方法论的一部分是确定“最低公分母”。例如，在工资系统中，需要生成按周的薪水和每月的财务报表，最低的公分母是天。尽管这是一个简单的示例，但令人惊讶的是，有多少系统将数据保持在错误的详细信息级别，然后无法生成不同周期的所有必需信息。
许多敏捷组织正在使用图形显示的3层模型进行开发-迭代（2周），发布（3-6个月）和路线图（6-18个月），但可交付成果的粒度（故事）不同，功能）。如果整个企业都使用这种“短期”模型来实际运营企业怎么办？如果每个人都使用2周的迭代进行同步怎么办？如果每个人都专注于两周交付部分完成的产品，文档，业务计划，计划和其他业务工件，该怎么办？我最近在与一位遇到循环啮合问题的客户谈话，他们的产品管理小组与敏捷交付团队的同步性不是很好。在其他公司中，Devops计划正尝试与交付团队的发布更紧密地同步操作和发布管理。
当公司认真对待企业敏捷性时，将需要进行重大变革的一个领域正在从财务周期转变为驱动程序，以专注于产品驱动的（交付品）``短期''模型（确实提供了所需的财务信息，但没有提供）受财务周期的驱动），使其更适应不断变化的情况。
