就這樣，C項目組糊里糊涂的開始了敏捷之旅。在第一個迭代完成后：
基本情況
2011年2月21日-3月4日，項目組成員每天站在白板前進行每日站立會議。如果發(fā)現了需要討論的話題，就在會后進行討論。
2011年3月4日，項目組進行了第一次回顧會議。沒有評審會議了，因為項目組僅完成了預估工作的不到一半，僅提供了一個Demo。
第一次回顧會議
團隊在白板前進行第一次迭代回顧，會議總耗時一個小時。會議結果如下：
1. 做得好的
a) 成功完成Demo，所有Bug都修復了。
b) 每日站立會議對團隊有很大幫助，可以清楚知道團隊其他成員在做什么。團隊協(xié)作比以前更好了。
c) 感謝美國團隊的及時響應。
d) 感謝團隊成員的認真負責，開發(fā)和QA聯(lián)手解決了瀏覽器兼容問題，開發(fā)把Silverlight的單元測試集成到每日構建中。
2. 需要改進的
a) UI是個瓶頸，開發(fā)流程不順暢，有時會等待。
b) 沒有完成工作計劃。
c) 會議太多，時間太長。
3. 改進計劃
暫略。
分析與思考
糾結的目標
第一次迭代是相當糾結的一個迭代。完成既定的任務，遵照Scrum的流程和建立自組織團隊，這三個目標交織在一起。在其中還混雜著，證明敏捷優(yōu)于以前模式的壓力，這部分壓力承載了證明自己的期許，公司管理層的期待和團隊參與者們的期望。
殘酷的現實
從很多方面來看，第一次迭代都不能算成成功。團隊承諾的過多，甚至算不上團隊承諾，而且不能順利完成。工作流程中暴露出很多問題，瓶頸變得顯而易見。
從樂觀的角度看，也有些進步。團隊在持續(xù)解決工作中出現的問題，合作與溝通也在進步中。
怎么辦？
很多團隊都是在第一、二次迭代中不能頂住壓力，最后只好回歸以前的工作方式。
1. 意識灌輸
在暴露出的各種問題面前，團隊顯得無助，懷疑論正在成長。作為敏捷推動者，要知道“壞消息就是好消息”，不停詢問團隊“這樣的問題在以前的模式中能夠發(fā)現和解決嗎？”讓這些問題暴露出來，這本身就是敏捷實施的成果。
2. 頂住壓力
不管怎樣，項目交付的壓力持續(xù)存在，而管理層因實施敏捷對團隊的關注，導致壓力持續(xù)增大。作為敏捷推動者，在這時候要頂住壓力。一個好辦法是告訴團隊，管理層對團隊當前的工作進度并不滿意，讓我們一起來想想辦法解決這個問題。
3. 培養(yǎng)信心
作為敏捷推動者，不要過于強調我有好辦法，要注意發(fā)掘團隊的閃光點。這是培養(yǎng)自組織團隊最有效的一種辦法，認可和表揚團隊的閃光點，培養(yǎng)團隊自主改進的信心。