敏捷社区正在如火如荼地讨论什么情况下团队能真正地敏捷起来，又有哪些是实施敏捷的正确方法。Jason Little撰写了博文《你干得比你认为的更出色》，分享了他的观点：面对敏捷实施的各种意见，我们该何去何从？

　　敏捷社区可以迅速地找出你队伍中的问题。你“Scrum用得不对”，你在“照搬(doing)敏捷”，而没有“变得(being)”敏捷，或者类似的一些废话。但你究竟有什么是做得对的呢？

　　他认为，敏捷不是“照搬敏捷”或者“变得敏捷”，而是意味着行动上的改变和进步。

　　我知道大家在进步，因为我看到了不一样的表现，这是几个月前不曾有过的。我感到大家在进步，因为大家给我讲了一年前的生活和现在的生活的种种不同，工作上的各种改进。

　　Jason建议多关注做得好的地方，并引以为傲：我不认为公司足够关注大家做得好的事情，因为各种权威总是指出大家做得不好的地方。……我现在所在的团队就为他们所取得的进步感到非常骄傲……昂首挺胸，我为你们骄傲。

　　Tommy Bryntse写了一篇名为《什么是敏捷》的博客，其中他指出了团队可以号称敏捷的关键点。他阐述了他所理解的敏捷，以及什么情况下不算敏捷：

　　敏捷宣言是敏捷的灵魂。宣言中的十二法则充分诠释了敏捷。无须赘述……变得敏捷就是遵循宣言精神及其身后的法则。如果你没做到，不好意思：不能算敏捷！

　　他建议如果做不到，还是暂时不要说自己要做敏捷了，先做个列表出来，告诉自己“算不上敏捷”的原因。

　　请不要只因为开了日常站立会议，用白板记录故事、分派工作，就标榜自己在做敏捷开发。……要实现敏捷，你得先检查前面提到的“算不上敏捷”列表……如果榜上有名，你就不算敏捷。话虽这么说，我并不是让大家停止手中的实践。那些优秀实践可以帮助你交付更好的软件。只是如果你没有真正做到，就别说在做。

　　在对Jeff Sutherland题为《敏捷团队真的敏捷吗？》的采访中，他回顾了敏捷宣言发布以来这十年的历程。他也就如何判断是不是敏捷发表了自己的观点：在Sprint结束时能够交付可运行的产品确实很有挑战，如果没有完善的敏捷团队很难做到，而正如我们所讨论的，这一点又是相当关键的基本原则，做不到就算不上敏捷。

　　Jeff还举了几个实施Scrum的正面和反面例子：有数据表明，做得好的Scrum效率要快10倍。

　　要做好Scrum，头一件事就是要在Sprint结束时交付可工作的软件。……另一件重要的事是Sprint所需要的Backlog：Backlog准备好了吗？是否清晰？是否每个待办项都大小合适？团队能够理解Backlog从而做出估算？是否有验收测试条件?

　　我和Ken发明并在软件开发中运用了Scrum，我们把能想到的软件知识都用上了，但结果是，如果Scrum不精益，就是糟糕的Scrum。一旦开始实施精益瘦身，就意味着要从系统中移除浪费。而Scrum就是致力于扫除障碍，和减少浪费一脉相承。

　　在名为《婴儿和洗澡水》的博文中，Jim York探讨了如何看待五花八门的敏捷实践、工具和技术。他就如何决定选用哪些敏捷实践给了些建议：

　　Scrum的一个基本前提是如果事情进展顺利，就继续做。反言之，如果什么事情进展不利，一定要及时改变。Scrum并没有规定哪些敏捷实践在它的框架之内，而是将做这个决定的权利留给了自组织团队自由发挥。而这个“自由发挥”往往是Scrum实施中最难的部分。

　　他认为团队应该通过了解哪些实践合适他们，哪些不合适来自己发掘敏捷的真谛：

　　我更愿意将Scrum看作是一个学习加速器。每个Sprint都是个实验，是个学习的机会。……公司从过去他们经常使用的开发增量产品的流程中学到新的东西。学到的经验可以进一步地改进流程。