敏捷教练的进退之道

作者 Todd Charron 译者 大胖 发布于 2011年6月12日

领域

过程 & 实践

主题

沟通 ,

分布式团队 ,

教练 ,

极限编程 ,

敏捷实施 ,

教练和指导 ,

团队工作 ,

企业级敏捷 ,

Scrum ,

结对编程 ,

敏捷

分享到

最近，敏捷教练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）”。

查看英文原文：When to Cease Being an Agile Coach?

1. 返回顶部

   没有银弹，必须承认不是任何团队都适用敏捷开发！

   发表人 高 翌翔

   敏捷适用于何种人群或团队？他们是否需要具备某些基本素质？

   回复