通常认为，一旦敏捷试点团队获得成功，敏捷流程实施就算是上正轨了。 Dave Nicolette 则在此分享了他引人入胜的经历，籍此洞察为何即使在极成功的敏捷试点之后，敏捷实施还是会失败。
在第一个案例中，Dave 注意到：即使试点团队获得了巨大成功，并且团队已经达到了“超级高效”的境界，然而接下来，难以想象的情况还是发生了。
IT 管理层毫不犹豫，立即“接管了”敏捷团队。一周之内，他们就（a）取消了让本地技术团队去内部客户那边现场工作这一实践；（b）在这家传统公司中，把敏捷实践分子分散开，以此来减少他们的影响；（c）企图在绩效考核上给拥护敏捷的关键人士差评，从而“鼓励”他们离开公司；有些人会被处以“缓刑”，从而迫使他们离开；（d）发配一些最为出色的敏捷分子去费心照顾那些毫无出路但又不重要的遗留系统，这是另外一种鼓励他们离开的方式；（e）重建瀑布流程（披着敏捷的羊皮），并将其视为为内部客户交付项目的唯一方法。一年以后，“敏捷”在他们那里就只存在于词典之中了。
与之类似，在 Dave 的第二个例子中，他提到：一旦敏捷教练或者顾问离开了，公司内部的敏捷专家又开始重走老路，继续遵循以前的老实践，而这些实践是在敏捷咨询顾问进入公司帮助团队进入“超级高效”境界之前他们所采取的。内部专家们感受到了威胁，他们认为这些威胁来自外部咨询顾问，这些顾问对于试点项目的成功作出了贡献，内部专家想要在咨询顾问走后立刻重回老套路。
类似地，Dave 举了另外一个例子：他和一个样板客户合作完成了一个非常成功的项目，但这个客户再也没回来继续他们的合作。没有继续的理由发人深省：
我们团队的生产力太高了，客户公司远远跟不上我们。客户很难做到迅速更新 backlog，从而难以让我们的团队有足够的活儿可干。他们匆匆忙忙地把 user story 扔过来，这样他们就不会按小时给我们付了钱，而我们还无所事事，等着活儿来干。这种经历对他们来说压力太大了，所以他们觉得自己并不合适敏捷，转而使用传统方法和一些传统公司合作。
那么到底为什么只是试点成功，而不能善始善终呢？
Dave 提出以下两个主要原因：
- 局部流程优化 —— 试点团队往往和公司其他团队隔离开来。相对于公司其他团队，他们在一个独立的环境中工作。一旦试点结束，敏捷的东西也就石沉大海了。改变更多地在局部范围被实施，想要推广就会在公司其他团队中引起很多摩擦。
- 被忽略的情感因素——顾问们忽略了来自那些本该对持续成功能起作用的人或者部门的支持。结果，一旦顾问们离开，这些支持部门聚集在一起，就又重回老路了。
他们的做法很常见：投入时间直到能消除敏捷余孽，出手迅速而且坚定。他们“教育不懂规矩的人”，确保每个曾经是敏捷团队一部分的人，要么妥协闭嘴，要么离开公司。
Dave 认为：成功的秘诀在于——要能够根据客户应对变化的能力，调整实施变化的速度以及对于协作程度的要求。这种情况下，先期的项目可能需要更多时间才能成功，然而，敏捷转变却能长久成功。
毕竟，剑走偏锋而忽略了实施敏捷的人力成本并不能算成功。小心敏捷顾问带来的不仅仅是“超级高效”这一个礼物。
暂无签名
Java 避坑指南：Java 高手笔记代码篇
本迷你书包括 86 个业务开发中常见踩坑点。每一个知识点都相当的实用，是程序员业务开发中的必备避坑指南...
评论