就这样，C项目组糊里糊涂的开始了敏捷之旅。在第一个迭代完成后：
基本情况
2011年2月21日-3月4日，项目组成员每天站在白板前进行每日站立会议。如果发现了需要讨论的话题，就在会后进行讨论。
2011年3月4日，项目组进行了第一次回顾会议。没有评审会议了，因为项目组仅完成了预估工作的不到一半，仅提供了一个Demo。
第一次回顾会议
团队在白板前进行第一次迭代回顾，会议总耗时一个小时。会议结果如下：
1. 做得好的
a) 成功完成Demo，所有Bug都修复了。
b) 每日站立会议对团队有很大帮助，可以清楚知道团队其他成员在做什么。团队协作比以前更好了。
c) 感谢美国团队的及时响应。
d) 感谢团队成员的认真负责，开发和QA联手解决了浏览器兼容问题，开发把Silverlight的单元测试集成到每日构建中。
2. 需要改进的
a) UI是个瓶颈，开发流程不顺畅，有时会等待。
b) 没有完成工作计划。
c) 会议太多，时间太长。
3. 改进计划
暂略。
分析与思考
纠结的目标
第一次迭代是相当纠结的一个迭代。完成既定的任务，遵照Scrum的流程和建立自组织团队，这三个目标交织在一起。在其中还混杂着，证明敏捷优于以前模式的压力，这部分压力承载了证明自己的期许，公司管理层的期待和团队参与者们的期望。
残酷的现实
从很多方面来看，第一次迭代都不能算成成功。团队承诺的过多，甚至算不上团队承诺，而且不能顺利完成。工作流程中暴露出很多问题，瓶颈变得显而易见。
从乐观的角度看，也有些进步。团队在持续解决工作中出现的问题，合作与沟通也在进步中。
怎么办？
很多团队都是在第一、二次迭代中不能顶住压力，最后只好回归以前的工作方式。
1. 意识灌输
在暴露出的各种问题面前，团队显得无助，怀疑论正在成长。作为敏捷推动者，要知道“坏消息就是好消息”，不停询问团队“这样的问题在以前的模式中能够发现和解决吗？”让这些问题暴露出来，这本身就是敏捷实施的成果。
2. 顶住压力
不管怎样，项目交付的压力持续存在，而管理层因实施敏捷对团队的关注，导致压力持续增大。作为敏捷推动者，在这时候要顶住压力。一个好办法是告诉团队，管理层对团队当前的工作进度并不满意，让我们一起来想想办法解决这个问题。
3. 培养信心
作为敏捷推动者，不要过于强调我有好办法，要注意发掘团队的闪光点。这是培养自组织团队最有效的一种办法，认可和表扬团队的闪光点，培养团队自主改进的信心。