先敏捷再规范，先做到再写到，先短期利益再长远利益，先实效再完备。
这个策略源于实践。因为一步到位直接采用规范的方法，阻力比较大，效果难以持久，很可能事倍功半，敏捷方法以其短期内可以见效、对已有的开发过程调整幅度小等特点易于开发人员接受，所以可以先敏捷再规范，将敏捷作为通向规范的一个阶段。
芸芸众生，大都是凡人。凡人都是注重短期利益的。只有那些领袖、那些思想家才是目光如炬，站的高看的远。过程改进要从凡人做起，凡人是体系的执行者，所以首先要满足凡人的需求，让凡人看到好处，否则，群众的力量是无穷的，这力量可以建设的力量也可以破坏的力量。
敏捷的方法是适应变化的一种方法，因时、因势、因事调整计划，它可以处理近期内即将发生或已经发生的变化，它不赞成去为未来的变化太多花费时间，变化会导致近期计划的调整，也使长期的计划难以预期。
采用敏捷的方法并不意味着没有规矩，没有文档、没有计划、没有跟踪与控制并不意味着就是敏捷。敏捷方法在落实其规矩时和重量级的方法有所不同：
1 敏捷方法减少了中间结果的记录、减少了管理与支持类的文档；
敏捷方法中最常见的是3种角色：教练、客户、程序员。教练起到了项目经理和过程指导者的作用，客户实时执行确认与验证的动作，程序员去实现产品。敏捷方法减少了管理与支持文档的工作量，但并不意味着没有做管理，只是做的少、文档也少。比如敏捷方法也要做计划、也要估算项目的工作量、也要和项目组的成员沟通计划的可能性、也要获得项目组成员的承诺，只是这些管理活动可能只有最终的计划书，而没有中间结果的记录。在敏捷方法中很少看到关于质量保证活动、度量分析活动的系统要求。
2 敏捷方法强调通过面对面的口头交流减少书面的文字交流；
文档是沟通的一种方式，口头交流也是一种沟通的方式。在重量级的管理方法中强调了文档的重要性，而敏捷方法并非没有文档，只是它认为口头交流更重要，口头交流效率更高，因此可以编写简单的设计文档，设计的思想可以通过口头交流进行评审，用口头交流弥补文档简化的不足，因为文档简单，将来的变化也就少，维护的工作量也相应减少。
3 敏捷方法强调最终的交付物而忽略了中间产物。
关注最终交付物的质量而不是中间结果的质量，采用诸如单元测试、结对编程、代码重构、持续集成、代码规范等手段确保源程序的质量，采用迭代的方法尽早进入编程，在过程中通过沟通进行设计的实时评审、代码的实时评审，以便于尽早发现交付代码的缺陷，尽早修复缺陷。作为开发过程的中间产物需求与设计等文档则进行了简化。代码是必须交付的，所以要采用一切手段规范之，既然要交付，就要保证其质量。而需求与设计文档并非是必须交付的，而需求和设计也是经常变化的，既然不交付，既然始终变化，干脆就不去花时间去写。
4 高效的人比规范的过程更重要。
一群精英如果能配合默契的合作，则不需要去监督他们是否按照标准规范去执行了，这个团队是自我管理的，大家有着共同的价值观，彼此能快速协同，互补合作，最终走向成功。是英雄创造了历史，还是人民群众创造了历史？结论不言而喻，但是如果没有英雄呢？如果各位都是英雄呢？
以上种种思想，反应了敏捷方法的实用主义哲学。如果一家企业的项目大都在10人以下的开发团队完全可以从敏捷方法开始着手进行过程改进。但是，软件开发是一种非规模经济的现象，随着团队规模的增加，上述的手段可能很快就失效，还要回到重量级方法上来。