1. 技术负债在敏捷团队中会快速的膨胀。

　　是事实，但这并不是敏捷本身的问题，只不过是在敏捷导入和实施过程中没有引起足够的重视。经验丰富的敏捷教练往往十分重视工程类实践，会强调重构在迭代中的重要性。很多的敏捷实践(比如TDD，持续集成，重构)及很多敏捷开发者提倡的原则(比如S.O.L.I.D原则，Clean Code，Implementation Patterns )都能帮助敏捷团队避免过多的技术负债。Uncle Bob甚至认为应该在初的敏捷宣言中加入第五条原则“Craftsmanship over Crap”，来强调技术的对成功的敏捷项目的重要性。

　　2. 敏捷软件开发团队会想当然地认为每个团队成员都专业，称职并富有责任心。如果事实不是如此，项目开发很快会变得举步维艰。

　　是事实，但这恰恰又是敏捷的卖点。我们应该做到：谦虚有耐心；勇于承诺；团队成员互信互助，而不是互相指责批评；承认自己的能力不足，不断追求进步，需要的时候寻求团队成员的帮助。很多方法论认为只能通过审查监控的手段来确保项目的顺利运行，而敏捷团队更多的是依靠个人的责任心。在的敏捷团队中，能力较弱的的团队成员会感受到来自其他成员的压力，要不然尽力做好，要不然只有走人。

　　3. 由于对敏捷开发实践的错误理解，导致团队不合理地频繁交付，疲于奔命。

　　说老实话，在了解敏捷之前，研发团队才是疲于奔命。敏捷原理打破了传统的思维模式。人很容易犯错误，但是很多敏捷实践(结对编程，持续集成，TDD)能够帮助开发团队及早发现问题，纠正错误。因此敏捷反而把我们从传统的思想束缚中解脱出来。可能是由于对敏捷的过度宣传，导致大家对敏捷期望值过高，认为敏捷开发是解决所有问题的万灵药。其实我们导入敏捷也是受种种因素（客户环境，团队对敏捷的认识程度，成员的能力）限制的。如果能够从其他更成熟的敏捷团队或者敏捷教练那里吸取经验这样会更好，否则只能合理的逐步的导入实践。很多敏捷项目确实存在过于频繁的交付，那是由于人们迫于各种压力，“好大喜功”的天性而忽略了敏捷其实一直在强调的“根据每个迭代能够实际发布量”（也是真正能够达到Done标准的工作量）来调整下一个迭代工作量。如果团队不能自主调整工作量，这其实已经偏离了敏捷。

　　4. 实施敏捷的门槛太高，敏捷开发需要更强的团队和个人的纪律性，勇于承诺和高度的公开性，但对一个不成熟的组织来说这个门槛太高。

　　是事实。但是这并不意味着不能在不成熟的组织中导入敏捷实践。这类组织可以逐步地导入敏捷实践。很多人太过心急，想“一口吃一个胖子”，但这往往是不切实际的。当然，同时必须要注意的是，不能因为采取逐步导入的手段，而降低敏捷定义的门槛(Ron Jeffries有一篇文章"Agile Is， Not， Maybe")。

　　5. 绩效差的团队成员很难在高度公开的敏捷团队中掩饰自己能力的不足。好的团队往往能够采取一定的措施来帮助这类成员。但如果没有采取措施，这些成员往往会想方设法通过消极怠工来掩饰自己能力的不足。

　　是事实，敏捷需要勇气，但是这是好事。态度决定一切！敏捷团队所不能容忍的是那种故意偷懒的成员。每个人都会经历从学徒到专家的过程（获得技能的Dreyfus模型，及Apprenticeship Patterns: Guidance For The Aspiring Software Craftsman）。由于每个人的能力不同，背景不同，能达到的高度也是不一样的。团队成员应该承认个体差异，努力帮助较弱的团队成员，使其快速成长。

　　6. 敏捷团队容易过份关注眼前的短期目标，而忽视长期的战略目标。尽管在短期内能够取得成功，长期注定还是会失败。

　　可能是事实，但是这在非敏捷团队中也屡见不鲜。不可否认的是在敏捷项目中，很多人过分强调了YAGNI，因而在早期忽视了一些战略性的目标，尤其是业务需求目标，从而导致后期重构十分困难。YAGNI是很有用的，但是需要其他实践比如TDD和BDD（行为驱动设计）的支持。Kent Beck在极限编程一书中讲述了怎样借助TDD，实现演进式设计。另外需要注意的是，这其实在很大程度上是一个平衡的问题，怎样在YAGNI与预先设计之间做平衡。