讨论到敏捷或DevOps转型，很多人都会问这个问题，在敏捷转型的过程中，团队经理应该扮演什么样的角色，是不是需要先接受培训？经理不懂敏捷的话团队还能转型么？很多情况下，经理们可能都是团队里最忙的人，要想抽出两三天时间参加敏捷培训非常困难，想通过自学变成敏捷教练也不现实。那么就把转型的任务交给其他人吧，指定一个负责人或教练，让此人全权代办，岂不省事。这么做到底行不行呢？从我的经验来讲，是不推荐的。
其实，为一项工作或一个项目指定负责人的做法是很正常的，任何团队里都不可能靠一个经理管着所有事，那敏捷转型有什么特殊之处，为什么不适合这么做呢？其实刚开始，我自己也有这样“偷懒”的想法，既然自己不大懂，又没空学，最简单的法子就是交给组里的积极分子，授权给他们来做，而我只要定期了解下情况，提供一些帮助就行。
做着做着，问题就来了。敏捷转型不但耗时长，执行起来也颇复杂，几乎不可能照搬现成的案例，必须要根据团队自身的情况制定计划，并随时调整。转型本身也是小步快走的敏捷过程，不能期望做好了瀑布式的规划就可以按部就班地执行。在这个过程中，转型负责人肯定需要和作为经理的我讨论计划、调整方案、争取支持和帮助。如果我自己并不了解敏捷，该怎么决断呢？其实这样的问题在工作中也不少见，很多时候我们的决策都依赖于其他更专业的人士，自己不懂没问题，只要交给懂的人做就行。如果我找到的负责人足够靠谱，提出的计划跟办法都是对的，而我要做的事只是表示支持，让他放手执行就好，这听起来多么容易，会有什么不妥呢？
不妥之处就在于，敏捷转型跟其他项目不一样，它牵涉到团队的方方面面，从团队文化、沟通风格、考评指标，到具体的任务分配与执行，可能都需要做出一些调整和改变。让一个团队改变既有习惯，培养新的做事方式，本就是非常不易的一件事，在这个过程当中必须投入很多精力引导大家，发现问题及时纠正，有了进步随时鼓励，还要能捕捉到每个人抵制或赞同背后的原因，因势利导。如果团队经理在这个过程中帮不上忙，只能依赖教练，那么难度本身就会增加。更差的情况是，如果团队经理自己的思路没转换，仍以旧方式指导团队工作，没让大家看到变化，那么其他人就更没有改变的动力了，转型的具体操作也就更难推动。
指定一个转型项目的负责人并不错，能有外部或内部的敏捷教练帮忙更好，但最能带动团队积极性的，其实还是经理。要想促进团队敏捷转型成功，经理一定要做到身体力行，先从自己开始学习和改变。只有让团队看到经理的做事方式发生了改变，大家才能更有动力跟上来，也更愿意发挥主观能动性，为转型的过程出谋划策。如果经理本身既不学习也不实践，只做个“精神支持”，那么转型这件事，在大家眼中就很容易变成一项不明就里的任务，只会被动地配合而已。
诚然，并不是每个经理都得先变成敏捷教练，才能带领团队走好敏捷之路。但在一个好的团队里，必须达到从上到下一致的认识。敏捷转型不是一部分人的事，必须是整个团队共同的目标，而团队经理，是完成这个目标必不可少的一环，自己不改变，很快就会成为阻碍转型的瓶颈，而不是整个团队的加速器。
