敏捷社区正在如火如荼地讨论什么情况下团队能真正地敏捷起来，又有哪些是实施敏捷的正确方法。Jason Little 撰写了博文《你干得比你认为的更出色》，分享了他的观点：面对敏捷实施的各种意见，我们该何去何从？
敏捷社区可以迅速地找出你队伍中的问题。你“Scrum 用得不对”，你在“照搬 (doing) 敏捷”，而没有“变得 (being)”敏捷，或者类似的一些废话。但你究竟有什么是做得对的呢？
他认为，敏捷不是“照搬敏捷”或者“变得敏捷”，而是意味着行动上的改变和进步。
我知道大家在进步，因为我看到了不一样的表现，这是几个月前不曾有过的。我感到大家在进步，因为大家给我讲了一年前的生活和现在的生活的种种不同，工作上的各种改进。
Jason 建议多关注做得好的地方，并引以为傲：
我不认为公司足够关注大家做得好的事情，因为各种权威总是指出大家做得不好的地方。……我现在所在的团队就为他们所取得的进步感到非常骄傲……昂首挺胸，我为你们骄傲。
Tommy Bryntse 写了一篇名为《什么是敏捷》的博客，其中他指出了团队可以号称敏捷的关键点。他阐述了他所理解的敏捷，以及什么情况下不算敏捷：
敏捷宣言是敏捷的灵魂。宣言中的十二法则充分诠释了敏捷。无须赘述……变得敏捷就是遵循宣言精神及其身后的法则。如果你没做到，不好意思：不能算敏捷！
他建议如果做不到，还是暂时不要说自己要做敏捷了，先做个列表出来，告诉自己“算不上敏捷”的原因。
请不要只因为开了日常站立会议，用白板记录故事、分派工作，就标榜自己在做敏捷开发。……要实现敏捷，你得先检查前面提到的“算不上敏捷”列表……如果榜上有名，你就不算敏捷。话虽这么说，我并不是让大家停止手中的实践。那些优秀实践可以帮助你交付更好的软件。只是如果你没有真正做到，就别说在做。
在 InfoQ 对 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 都是个实验，是个学习的机会。……公司从过去他们经常使用的开发增量产品的流程中学到新的东西。学到的经验可以进一步地改进流程。
评论