当我们在尝试应用敏捷开发时，Scrum方法是最容易实施的。但是如果要想使敏捷开发进行下去，第一个试点的Scrum项目要尽量成功，这样会得到管理层更多的支持。以下是我们在实践中的一些具体做法：
a. 选择一个试点项目
1）这个项目是对企业的business有一定影响（但不是最影响的），这样一方面可以得到管理层的支持，如果成功有很强的示范效应，同时由于新方法最初的采纳期间会出现各种各样的问题，有失败或者延期的风险，试点团队不会由于Business的压力重新回到以往熟悉的开发方式上以完成任务。
2）建议项目周期在5~6个月。这样可以保证有6个左右的迭代周期，试点团队可以由最初2个迭代的了解和尝试，再有2个迭代的适应，最后2个迭代会看到不错的效果。周期太短团队还无法真正了解Scrum，周期太长相关干系人会失去耐性，团队也会流失热情。
b. 试点Scrum团队的选择
1) Scrum的团队成员首先是乐于接受新鲜理念的。Scrum对传统的开发方式有较大的改变，乐于接受新鲜事物的成员更适合试点的Scrum团队
2) 试点的Scrum团队成员相对要资深一些，团队成员结构是跨职能的（cross－functional）
3) 一定要有一个有实践经验的ScrumMaster，同时最好是有一个管理层的人可以参与到试点的过程中
4) 试点的Scrum团队成员要在一起工作，而且是全职在本试点项目中
c. 试点的策略
1) 试点的目的不是将Scrum进行的尽善尽美（事实上试点的周期内也做不到），而是通过试点展示Scrum带给团队和公司的变化。建议试点团队的底线目标是：
1.1 每4周以内提交可以工作的，经过测试的软件；
1.2 提交的功能是最具有商业价值的；
1.3 过程在持续改进
2) 由于是试点新的方法，各种项目干系人对此保有希望，同时也会有怀疑。所以在试点过程中一定要做到项目的透明，包括进度、问题、解决的方案、下一次迭代的改进、本次迭代实现的目标。及时有效的沟通会减少很多干扰，增加很多支持。
3) 在迭代中不要高估自己真正可以交付的能力。因为Scrum中迭代是一个time－boxed的周期，即使完成95%的任务也不会被认为是“Done”的状态。如果团队没有适应这个变化，在最初的几个迭代中不能按时交付，很容易降低信任感。
4) 不要想“一口吃个胖子”。一般有两个切入口：一个是目前遇到的最大问题，以这个问题的解决方案作为最初的切入；另一个是从最容易的开始，例如每日会议、Sprint Planning、回顾会议等
5) 适当和其他的敏捷方法结合，特别在工程实践上，例如结对、持续集成等