在软件开发中花了很多时间等待事情发生。这种形式的浪费很容易在大多数开发团队中被发现。新的Scrum团队发现自己在一个Sprint中等待很多事情，包括：
- 允许做某事
- 完成需要一个漫长的过程
- 从一个团队或个人中脱离
- 运行测试或者完成验证
- 访问所需要的资源
- 与团队之外的人员合作
比等待Scrum团队的效率低下更加糟糕的是客户和企业需要花费时间等待软件集成、打包和交付。这个问题随着开发组织的规模增长而增加。随着更多的开发人员或团队加入到一个项目中，他们的工作集成到单个产品的成本也随之而增加。
Scrum中最长的等待是Sprint迭代时间。作为所有Scrum活动的容器，对Sprint持续时间的唯一要求是一个月或更少。这就限制了等待软件的工作增量为不超过一个月的时间。大多数Scrum团队更频繁地交付可工作的软件增量。
一个公司有六个Scrum团队正在开发一个庞大而复杂的软件产品。每个Scrum团队专注于特定的功能，并通过主Product Backlog在协同工作。每个Sprint迭代周期是是三周，包括整合所有开发团队的工作。
在此之前，每一个Sprint迭代周期是两周，但是随着产品的功能不断增加，开发的复杂性越来越高了。随着新的Scrum团队的加入，他们需要更多的时间来工作，所以根据集成活动的需要Sprint迭代周期增加了。
三周现在被称作整合周。将新功能集成到主程序中是在此期间的主要活动。每一个整合周由每个开发团队的代表建立一个集成团队。他们指导整合活动的工作。
集成团队在集成周期间不接受新功能，尽管它们确实要求小的变更来解决集成问题。在集成周期间，由于集成团队的需要，这会导致大量的随机性的代码需要变更。
下面的图形显示了在一个Sprint中典型的配置管理过程。开发团队在每个Sprint开始时创建自己的开发分支。他们在第2周结束时合并代码。在第3周，开发团队根据需要根据集成团队的需要而为之服务。
虽然在Sprint中整合是必要的，六个Scrum团队的三分之一的工作能力目前用于完成整合。在这段时间里，团队的大部分能力都花在了Sprint以外的活动中。注意，在上面的例子中，团队5在整合周期间没有任何工作。
增加整合周使Scrum团队经常必须经常在流程切换过程中中断工作。有些团队在整个整合周中试图保持生产效率而私下创建和合并代码分支，这增加整体代码的复杂性和颠覆了需要做出更好决策的透明度。
团队的Scrum Master为找出替换方案而进行面谈。一个Scrum Master在每个Sprint迭代的前两周通过WIP限制而获得了巨大的成功。Scrum Master注意到如果每个团队在每次将WIP限制当做一个功能特性，那么当每个功能完成时它可以潜在的完成整合工作。
如果在所有开发团队使用这种实践，没有团队会在两周之后整合他们的工作产出时而需要等待。每个团队现在可以考虑整合到主程序时的DOD1的定义，而不是去考虑在整合新开发的功能时需要等待。
“完成”的定义是Scrum中的一个概念。在开发团队中，为了确保Product Backlog项目“完成”，每个团队都会在Sprint中为所选择的每个Product Backlog Item完成和交付达成一致。
在接下来的Sprint回顾，开发团队同意尝试整合工作完成每个开发功能。他们建立并遵守以下新规则：
1、每个开发团队一次将WIP限制为一个特性。
2、集成到主程序时功能必须开发完成。
3、在开始开发新功能之前，开发团队将更新他们的代码，并使用主分支的最新的代码。
由此产生的活动如图所示：
新规则使团队在功能交付时体验到更加流畅的工作流程。在没有整合周的情况下，开发团队不再需要在第三周的冲刺中闲置和中断。
在Sprint中最初花费在集成变更的时间是较多的，但是随着连续集成模型变得更加熟悉，每个开发团队的生产力增加。随着时间的推移，在每个Sprint中交付的功能增加了。
（连载四）