最近，敏捷教练 Morgan Ahlström 在邮件列表“敏捷教练支持（Agile Coach Support）”上求助：有的客户声称想要更多地从敏捷中获益，但实际行为却与该目标背道而驰，如何面对这种窘况？
下面是他所描述的情况：
你是否受雇担任敏捷教练，结果做的事情名不副实？你是否偏离了任务方向？你是否在兢兢业业帮人实现敏捷，只因为自己拿了这份钱，即使对方根本不想改变？你是否得一面搞改革，一面服从潜规则？你是否要借助于其他什么头衔来推动大家走出泥潭？实际工作中你还有其他什么可行的方法？
D. André Dhondt 的想法：
在我看来，改进和敏捷是两码事。我会专注于对方想要改善的地方，或者对方感觉难受的地方，把“敏捷”放在一边。我仍然要做沟通、互动，以人为本，但不会拘泥于敏捷这个术语。
Peter Green 跟帖说：
每次有机会做教练，我们都指望能改变世界。经常落入的误区是：如果客户没把敏捷贯彻到底，就是我们的失职。不管怎么说，事情还得一步一步来，采取持续改善（Kaizen）的方式——不积跬步，无以至千里；不积小流，无以成江海。
团队和组织的改革，包括很多细致入微的工作，我们可以带动大家一起向着敏捷前进。其过程的漫长会令人沮丧，但缓慢的改变仍然是改变。
Tim Ottinger 从历史眼光看待问题，同时提出警告：
我正在酝酿的一个口号：“形象工程”是“不断实现”的大敌。
按照一套框框来做事，并非早期 XP 和 Scrum 的要求，也不是达成它们的手段。它们改变了团队合作中一些深远的东西，它们来自对真正高质量软件开发的尝试。因为它们看起来真的很牛。XP 是为了实现更多、更好、更快、更安全、更干净的一套深层次变革，而被大家所采用。我们正在悬崖边上，“敏捷”现在几乎成了拦路虎，而不是快车道。大家为了守规则而守规则，而不是从团结中获益。
稍后他又补充说：
我曾经面对的尴尬是，程序员和经理们就在那消磨时间，等着我什么时候走人，等着“敏捷”的风头什么时候过去。太可怕了。
另一方面，如果你真触动了少数几个人，那也算没白忙。如果能接近旧有套路的切入点，你就可能促成一些改变，并点亮星星之火。别搞混了，“挫折”与“失败”不能同日而语。
Lior Friedman 的选择：
压力一旦增加时，人们通常会重拾旧的习惯。名义上采取哪种流程，并不重要，我只要做到让事情 100％可见，确定让每个人明白团队正处在什么位置，以及接下来朝哪里走。任何一点能促成的进步，都会让我喜悦。
我也会实事求是地评估自己，如果对我的 ROI 投资回报率是正值的话，就继续在这个岗位上，基于现有条件，努力做到最好。
George Dinwiddie 对务实精神有共鸣：
尽管我的工作大多是训练团队朝着“敏捷”过渡，最终目标却不是“达成敏捷”，而是帮助人们更有效率地开发软件和其他系统。
“帮助”是让对方得到好处，提供他们想要的，不是我想要的。如果我在这没有帮助，就是该离开的时候了。当然离开也会有其他原因。
Tim Ottinger 充实了讨论内容，链接内容是他和 Jeff Langr 写的一篇文章，标题为“敏捷的误区（What Agile is Not）”。
Java 避坑指南：Java 高手笔记代码篇
本迷你书包括 86 个业务开发中常见踩坑点。每一个知识点都相当的实用，是程序员业务开发中的必备避坑指南...
评论