在这本书中写到，他们曾经一起从事过一个项目，团队将这个项目从近在眼前的湮灭中挽救出来。在第一次发布临近的一段时间，大家心里都很清楚我们尽量不要错过发布的时间。一天他们开了一个碰头会来讨论这个问题，他们轮流回答“什么阻碍着我们投产？”这个问题，回答很是一致。“我的时间不够。”“我的时间不够。”“我的时间不够。”没有任何人会有足够的时间，但是没有任何摆明的答案。
在我们的开发过程中，这个问题也比较明显，对于时间问题，往往问到做了什么的时候，都说没有时间，才没有做工作，一个工程就一直往后拖，直到最后也拖，最后完不成任务的时候，又把责任推来推去，每个人分的任务都是一定的，但是思想觉悟不一样，根本没有团队的意识，给他安排了任务都不主动的完成，每次都等着催，然后还不完成，很是令人生气，现在开始后悔当时的决定了。
当你处于项目结尾时，你实际上只知道自己的位置。因此你需要每几周结束项目——那就是我们使用迭代的原因。迭代迫使我们每几周看一下时间控制杆，以便我们不可避免的看到更改范围的结果。我们需要这样的计划风格：保持程序员的信息，计划是可行的；保持客户的信息，他们所获得的和他们能获得的一样多；执行起来花费尽可能的小。
当然，在实际开发过程中，也确实有这样的现象，承诺了很多，但是却不能按时完成自己承诺过的任务，这其实是很严重的事情，团队商量好要在什么时候要进行功能测试，可是在规定时间里你并没有完成自己承诺的事情，那么，团队的进度就会被拖掉，原本的计划也会被打乱。