敏捷转型通常被分为团队级敏捷、产品级敏捷和组织级敏捷。其中，团队级敏捷通常被认为是敏捷转型的第一步，也是基本功，然而很多敏捷教练在支持团队级敏捷的时候，体验却通常不怎么好。

总结起来有两点最为突出：

团队阻力太大，各种抵抗!

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

其实敏捷教练不在的时候，能在团队中留下的东西才是他们真正认可的东西。敏捷教练在的时候团队能做的那么好，要么是迫于压力，要么是给你面子，敏捷教练真应该感谢团队当面的不杀之恩!

听起来确实有点儿残酷，然而这也是敏捷教练不得不面对的现实。本文尝试从更多的角度，剖析背后可能的原因，供大家参考，也欢迎大家在评论区中补充。

一、团队认为敏捷教练没有把他们当活物

回想一下，敏捷教练是不是曾经像老师一样给大家讲授敏捷的玩法，要求大家一定要怎样做，并且还要保持好队形?

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

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

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

回顾会要......

Weatley, M.J. 和 KellnerRogers, M. 在“A Simpler Way”一书中有这么一段话：

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

也就是说，那些优秀的敏捷实践本身可能没有什么大问题，问题是你“如何”让大家采纳。

你也许想要求大家机械地按照你说的去做。当然，你也可以尝试如下的选择：

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

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

二、敏捷教练单方面方案不见得适合团队

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

所以，敏捷教练一定要让团队知道我们非常愿意和大家共同探讨，最重要的是，团队也一定要花时间来一起讨论，我们的目的是一致的，就是让大家能够工作得更好：工作更开心、更有效率、工作质量更高，不做不必要的事情，减少各种浪费......，所以每个人的意见都是非常重要的，大家共同创造属于大家的工作方式!

三、不顾敏捷实践的前提假设

每个敏捷实践要想起作用，都是有前提假设的：

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

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

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

四、团队认知负担过重

敏捷实践真的是不少，一口气改变太多，团队成员不但吃不消，还会打击大家的改变欲望。

可以考虑每次只改变一两处，并且只要有点儿进步，就及时鼓励或庆祝，增强大家的信心，同时引导大家做进一步的改变。

五、考核失配

我听到最多的问题之一就是：“你让我们做的这个东西和考核挂钩吗?”如果不挂钩，那么团队成员就会认为是在做额外的东西，肯定不乐意。

所以采用了新的工作方式，绩效考核就要及时跟上，与想要引导的方向保持一致，如果不一致，敏捷教练越使劲儿，团队的反作用力就越大，还不如不使劲儿。

六、领导思维没转变

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

所以这种情况，领导的思维转变是关键，我们需要花时间在领导身上，通过工作的透明性，让领导能够对项目有掌控感，同时，要让领导意识到，我们虽然在范围上可能随时做出调整，但是我们始终是基于当前的情况选择做最重要的事情，解决最需要解决的问题，他是可以从中受益的!

七、利益重新分配

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

所以妥善帮助受影响的小伙伴进行新的定位，帮助他们尽快适应新的工作方式，解决他们的后顾之忧，是我们需要花时间做的非常重要的工作。这个工作非常有挑战，很多时候会带来很大的情绪反应。然而这是未来的一个趋势，虽然短时间内可能他也想不通，毕竟这么多年的心智模式不是说变就能变的!

八、解决的不是主要矛盾

我们不是为了实施敏捷而实施敏捷，我们是要解决问题的。当你使用的招数不能帮助团队解决他们认为的最主要矛盾，他们就一定会觉得你是吃饱了撑的，即使你能够帮他们解决一些非主要矛盾。他们也会觉得你帮他们做敏捷是为了你自己，不是为了他们。

所以效果最好的方法就是你始终在支持他们解决他们认为(而不是你认为)最需要解决的问题，这叫做雪中送炭!

总结

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

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

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

有些人说，我们公司不适合敏捷，没有敏捷的土壤，那只能理解为暂时还不支持敏捷思维的应用或者不允许实施某些敏捷实践。不要失望，敏捷转型的过程就是改变土壤的过程，而不是先有合适的土壤，后有敏捷转型。

在有的组织中，敏捷转型是可以从中层开始起步的，公司高层会给下属一定程度的自由度，敏捷可以小范围搞起来，根据效果来决定是否要大面积铺开;有的组织是需要高层先有决心，高层不点头，下面的人谁也别轻举妄动。所以哪里是好的突破口，要考验敏捷教练的眼力了!

总之，敏捷转型是一个复杂的系统化工程，需要时间的积累，需要技术，更需要艺术，需要硬实力，更需要软实力，需要理性，更需要感性。我想，这个过程，短则3-5年，长则5-10年甚至更长，我们才能到达一个新的境界，然而这是一条没有终点的路，我们还要勇往直前，永不停歇!