当敏捷不能善始善终之时

作者 Vikas Hazrati 译者 金毅 发布于 2009年12月16日

领域

过程 & 实践

主题

企业级敏捷 ,

敏捷 ,

敏捷实施

标签

最佳实践 ,

回顾

通常认为，一旦敏捷试点团队获得成功，敏捷流程实施就算是上正轨了。Dave Nicolette则在此分享了他引人入胜的经历，籍此洞察为何即使在极成功的敏捷试点之后，敏捷实施还是会失败。

在第一个案例中，Dave注意到：即使试点团队获得了巨大成功，并且团队已经达到了“超级高效”的境界，然而接下来，难以想象的情况还是发生了。

IT管理层毫不犹豫，立即“接管了”敏捷团队。一周之内，他们就（a）取消了让本地技术团队去内部客户那边现场工作这一实践；（b）在这家传统公司中，把敏捷实践分子分散开，以此来减少他们的影响；（c）企图在绩效考核上给拥护敏捷的关键人士差评，从而“鼓励”他们离开公司；有些人会被处以“缓刑”，从而迫使他们离开；（d）发配一些最为出色的敏捷分子去费心照顾那些毫无出路但又不重要的遗留系统，这是另外一种鼓励他们离开的方式；（e）重建瀑布流程（披着敏捷的羊皮），并将其视为为内部客户交付项目的唯一方法。一年以后，“敏捷”在他们那里就只存在于词典之中了。

与之类似，在Dave的第二个例子中，他提到：一旦敏捷教练或者顾问离开了，公司内部的敏捷专家又开始重走老路，继续遵循以前的老实践，而这些实践是在敏捷咨询顾问进入公司帮助团队进入“超级高效”境界之前他们所采取的。内部专家们感受到了威胁，他们认为这些威胁来自外部咨询顾问，这些顾问对于试点项目的成功作出了贡献，内部专家想要在咨询顾问走后立刻重回老套路。

类似地，Dave举了另外一个例子：他和一个样板客户合作完成了一个非常成功的项目，但这个客户再也没回来继续他们的合作。没有继续的理由发人深省：

我们团队的生产力太高了，客户公司远远跟不上我们。客户很难做到迅速更新backlog，从而难以让我们的团队有足够的活儿可干。他们匆匆忙忙地把user story扔过来，这样他们就不会按小时给我们付了钱，而我们还无所事事，等着活儿来干。这种经历对他们来说压力太大了，所以他们觉得自己并不合适敏捷，转而使用传统方法和一些传统公司合作。

那么到底为什么只是试点成功，而不能善始善终呢？

Dave提出以下两个主要原因：

• 局部流程优化 —— 试点团队往往和公司其他团队隔离开来。相对于公司其他团队，他们在一个独立的环境中工作。一旦试点结束，敏捷的东西也就石沉大海了。改变更多地在局部范围被实施，想要推广就会在公司其他团队中引起很多摩擦。
• 被忽略的情感因素——顾问们忽略了来自那些本该对持续成功能起作用的人或者部门的支持。结果，一旦顾问们离开，这些支持部门聚集在一起，就又重回老路了。

他们的做法很常见：投入时间直到能消除敏捷余孽，出手迅速而且坚定。他们“教育不懂规矩的人”，确保每个曾经是敏捷团队一部分的人，要么妥协闭嘴，要么离开公司。

Dave认为：成功的秘诀在于——要能够根据客户应对变化的能力，调整实施变化的速度以及对于协作程度的要求。这种情况下，先期的项目可能需要更多时间才能成功，然而，敏捷转变却能长久成功。

毕竟，剑走偏锋而忽略了实施敏捷的人力成本并不能算成功。小心敏捷顾问带来的不仅仅是“超级高效”这一个礼物。

查看英文原文：When Agile Success is Eventually a Failure

译者 金毅 多年来服务于欧美软件外包行业从事管理工作，对软件工程、方法学等在外包业的运用和CMMI实施略有感悟。

1. 返回顶部

   文化的改变才是最困难的

   发表人 Jun Ran

   任何时候，要想在一个企业内部发动一些变革都是很困难的事情。尤其是像敏捷这种涉及的更多是思想文化层面的改变，难度更是可想而知。
   
   推广敏捷不如采取先小步优化，然后再水到渠成地系统化引进的策略，一下子就带一个相对全新的东西到别人公司中，自然难以持续。

   回复

2. 返回顶部

   似乎也是一把手工程

   发表人 侯 伯薇

   只有这种情况：
   老大说，要实施敏捷，
   于是整个团队便实施了敏捷。
   哈哈哈。

   回复

3. 返回顶部

   高处不胜寒?

   发表人 高 德翔

   文章大意如题。

   回复

4. 返回顶部

   Re: 文化的改变才是最困难的

   发表人 Chan Jackei

   同意。最终还是会牵扯到企业文化，或者更准确的说是老板或者老板的老板对这件事情的态度。所以工作久了，想做些自己的事情的时候，环境和文化真的很重要──这也是很多职业经理人在离职是的隐痛。

   回复

5. 返回顶部

   还是文化

   发表人 Chan Jackei

   1. 如果抛开”敏捷“这两个字，仅仅关注于如何不断提高项目的效率和质量以及客户满意度，不断的尝试改进和推广，而不是过多关注”敏捷“作为价值观的传播，会不会轻松些，乐观些？
   2. 如果IT行业的流动性没有那么大，如果把5年为一个周期进行组织改进作为常态──而不是半年或者一年，会不会不再那么容易焦虑？
   3. 如果不把”敏捷“当成解决一切问题的灵丹妙药，大家接受起来会不会更容易一些？
   
   就如软件质量的深层问题在于企业的文化一样，软件开发过程中还有很多问题都与企业文化有关，或者更准确的说是老板或者老板的老板对这件事情的态度有关。所以工作久了，想做些自己的事情的时候，要么幸运的碰到一个非常适合的环境和文化，要么有能力去影响这种环境和文化──或者，能有一个自己可控的势力范围，营造自己的小环境和文化。

   回复

• 更早的 >