敏捷很火热，大家都在谈敏捷；但不是所有团队都适合敏捷！
需要等待时机，时机成熟了，才推！
什么时候算时机成熟呢？
我们的经验是需要两点：
一、团队有三名或以上的研发工程师 ；
二、 团队内有一名合适的Scrum Master 。
刚开始的时候，一个开发团队可能只有一名或者两名研发工程师。这时候并没有全面推行scrum的必要 ，而可以借鉴scrum中的一些做法。
当Web团队只有一名研发工程师时，我们就尽可能地尊重他的工作方式。同时为了保证项目进度可控，我们引入了scrum的sprint机制–以sprint为开发周期，每个sprint进行一次Web产品演示。
这不但能够让工程师有一个以sprint为期限的压力，还能够让其他同事即时地了解项目的进展，以便做出相应调整。
当Web团队扩充为两名工程师时，我们又引入了结对编程、持续集成、相互代码审核等做法。
直到Web团队的规模进一步扩张时，我们才开始考虑全面启用scrum。
当团队内无法找到合适的Scrum Master时，不要轻易推行敏捷。
如果你的团队是由新人组成，或者即使有资深员工但是他并不了解或认同敏捷开发的话，那么你需要等待合适的Scrum Master出现。
合适的Scrum Master需要具备几个特质：
首先，他要认可敏捷开发这种方式；
其次，他要熟悉业务，起到教练的作用，能带领团队走正确的流程；
并且，当团队遇到问题时，他要有能力和担当引导团队做出决定，在团队成员遇到困难时，他要协助成员解决；
最后，他要能识别重要和紧急的事情，而并不是事无巨细的反馈到Product Owner那里。
敏捷开发虽然希望团队自我管理，但是这需要一个过程，开始的时候，一个合适的Scrum Master至关重要。
依据我们的经验，最胜任Scrum Master的人选是Tech Lead。我们也曾尝试过让产品经理担任Scrum Master，但是由于产品经理本身往往担当Product Owner，兼任Scrum Master会影响他在产品机会和产品体验等方面的投入。