团队级敏捷真的没你想的那么简单

• 团队阻力太大，各种抵抗！

• 不管敏捷教练在场的时候团队表现有多好，只要一撤场，团队就走样，甚至能回到解放前！

• 计划会应该这样开......

• 估算应该这样做......

• 迭代评审会要请这些人......

• 回顾会要......

际上，所有系统都坚持运用自己的创造力。他们从不接受强加的解决方案、预先确定的设计或在其他地方产生的清晰的计划。很多时候，我们把他们的拒绝理解为抵抗。我们说人们天生就抵制改变。但是我们从别人那里经历的抵制，并不是抵制改变本身，而是抵制“相信强加而不是创造”的改变过程。这是一个生命系统在抵制被视为无生命物体。这是在声明“系统有权利去创造”。生命坚持自己的首要责任是“自己去创造”。

也就是说，那些优秀的敏捷实践本身可能没有什么大问题，问题是你“如何”让大家采纳。你也许想要求大家机械地按照你说的去做。当然，你也可以尝试如下的选择：

• 组织一个工作坊，和大家共同探讨当前遇到的问题，敏捷教练负责主持工作坊，并提供结构化的讨论框架，主意都是大家出，结论都是大家下，如果团队卡住或者需要补充额外知识时，敏捷教练可以进行讲解，然而敏捷教练的意见仅供参考，不要强迫。这样做出来的行动计划是大家共同创造的，大家都买账，执行起来效果也会更好。

• 告诉大家，无论大家形成什么样的决议，迈出下一步都只是一个尝试，约定好时间，时间一到就收集大家的反馈，如果好就继续，如果不好，就调整。这样大家就不会有太多思想包袱，毕竟还有后悔药可以吃。这样大家就会更加愿意拥抱变化，勇于尝试。

有些团队似乎对于前面所说的“创造”这件事情并不敏感，他们和敏捷教练说：“教练，你就安排吧，我们都听你的！”然后他们就被动地等着，你让他们干啥，他们就干啥。他们不愿意花时间主动学习和思考敏捷的新思路到底怎么用才更有效，他们宁愿把时间都花在写代码上。所以当他们不喜欢敏捷教练的安排时，就会随便糊弄一下，走个过场，然后就该干啥干啥了。就这样，程序员以“实战派”自居，敏捷教练妥妥地成了“理论派”。

• 你说敏捷是为了更早交付有更价值的软件，团队说“这与我何干？我们只是完成业务人员提出的需求即可，价值是他们操心的事情。”所以如果开发和业务不能形成利益共同体，仍然秉持传统甲乙方的对立立场，敏捷必定效果不好。

• 你说每天要开站会，这样可以互通有无，及时识别阻碍，并根据实际情况调整当天的工作，以便更好完成迭代目标。团队说：“那都是领导的事情，我只负责让自己忙起来就好。”如果个人的绩效没有和团队的绩效绑定，那么没有人会在意团队整体绩效，没有人会关心大局。

• 你说每个迭代要安排一次演示，收集业务人员的反馈，及时调整。团队说：“这样不好吧，我就怕他们提意见，提了还得改，这不是自己给自己找活呢吗？我宁愿在发布前给业务人员做UAT，迫于上线时间压力，他们也不敢提太多，这多好！”所以如果在考核方面，研发人员对软件的业务成果不负责任的话，那么研发人员怎么会有动力关心所做的东西是不是用户真正想要的？

我听到最多的问题之一就是：“你让我们做的这个东西和考核挂钩吗？”如果不挂钩，那么团队成员就会认为是在做额外的东西，肯定不乐意。所以采用了新的工作方式，绩效考核就要及时跟上，与想要引导的方向保持一致，如果不一致，敏捷教练越使劲儿，团队的反作用力就越大，还不如不使劲儿。

敏捷首先要正视不确定性，根据实际情况不断调整期望，不断调整计划，在质量不妥协的情况下，通过范围的不断调整，达成价值最大化。如果领导还是坚持以前的思维模式，要求之前计划的工作要完成，后期增加的工作也要完成，那么团队就什么都顾不上了，他们唯一想做的就是证明给领导看：“我们已经把自己搞得很忙了，忙得都没时间做计划了，完不成可不能怪我”。

七、利益重新分配

敏捷的透明和全员的深度参与，客观上带来了利益的重新分配，不管你是否承认这一点。这就导致那些曾经利用信息的不对称而占据重要岗位的小伙伴深感自己即将要被分权，自己的价值感甚至是职业安全感被削弱或者被威胁。然而他们又不能明说，因此就用各种各样明里暗里的形式做出抵抗、阻挠甚至是挑战。就比如说项目经理或者与业务人员对接的单一接口人等，都是重灾区。他们是真忙，什么会议都需要他们参加，什么决定都需要他们下，恨不得三头六臂。他们在嘴里抱怨自己忙得连口水都喝不上，心里还是暗暗美滋滋地说：“你看我多重要，少了我还真不行！”

敏捷转型是一件非常复杂的事情，大多数公司都有不同程度的历史负担。敏捷转型不可能只是表面上实施一些成熟的敏捷实践就能达到目的。虽然敏捷实践的实施在短时间内确实能够看到一些效果，甚至是比较明显的效果，但如果上文所说的情况没有得到很好解决，迟早会反扑回来的。

因此，敏捷套路的实施只是开始，敏捷套路虽然能够立竿见影解决一些问题，然而更多的是暴露问题，敏捷教练要透过这些问题，看到背后系统性的问题（甚至是组织级的问题），然后去更大的层面推动问题的解决，然后再回来观察团队，继续调整，如此往复！当我们真正在团队身上看到了我们想看到的东西，就说明我们系统性的问题得到了真正的解决。这是需要时间和耐心的，很多时候也是要等待一个时机，即合适的人在合适的时间到了合适的位置的时机。

所以敏捷转型的工作，更多的是解决背后这些系统性问题的过程，而不是简单地给团队实施敏捷实践和框架的过程。

有些人说，我们公司不适合敏捷，没有敏捷的土壤，那只能理解为暂时还不支持敏捷思维的应用或者不允许实施某些敏捷实践。不要失望，敏捷转型的过程就是改变土壤的过程，而不是先有合适的土壤，后有敏捷转型。在有的组织中，敏捷转型是可以从中层开始起步的，公司高层会给下属一定程度的自由度，敏捷可以小范围搞起来，根据效果来决定是否要大面积铺开；有的组织是需要高层先有决心，高层不点头，下面的人谁也别轻举妄动。所以哪里是好的突破口，要考验敏捷教练的眼力了！