你好，我是宋宁。

今天这节课我来给你讲讲敏捷实践中你会遇到的一些问题以及解决方案。

理想很丰满，现实很骨感。敏捷听起来那么美好，它的推进策略和推进路线貌似也有迹可循，但现实却往往事与愿违。在敏捷实践过程中，我经常听到有这样一些问题：

  1. 团队刚开始做敏捷时就遇到了很强的阻碍，因此不热衷于敏捷；
  2. 敏捷做着做着就流于形式，大家慢慢地就偃旗息鼓了；
  3. 开发测试人员干得很苦，然而只是他们自己在忙活，他们的上游产品却游离在外不给力。

如果你也遇到过这些问题，并且不知道该怎么办，那么今天我就带你来看看 A 公司的敏捷实践历程，结合他们在推进敏捷时遇到的一些坑，给你讲讲相应的填坑策略吧。

我先来简单介绍一下 A 公司的情况。A 公司是一家国有企业，是业界排名前几的保险公司，研发团队有一千多人，前些年因为受到互联网冲击，业绩压力比较大，加之他们在研发效率提升、研发透明度方面有诉求，因此就准备通过推进敏捷改良现状。

前期他们没有自己的敏捷教练，也没有向外聘请敏捷教练，自己分步推进，磕磕碰碰地实践了接近两年，结果遇到了很多问题和困难。无奈之下，他们只好找专家组来帮忙。

专家组来到现场后，慢慢地梳理了他们的问题，并给出了解决方案，亲自示范；在专家组驻场一段时间以后，团队最终把敏捷推进成功。作为专家组中的首席敏捷教练，我经历了这个过程，现在就来分享给你。

坑一：团队说他们不想做敏捷

当我进入该公司做咨询时，他们请我帮忙诊断一个团队，据说是个难啃的骨头，因为这个团队不想做敏捷。他们的领导希望能够引进敏捷做一些改进，然而团队对此并不感冒，在推进敏捷这个问题上阳奉阴违。

在进入这个团队之前，我先跟这个团队的同事做了一次约谈，在这期间团队的 leader 对我说：“我们已经很忙了，没有时间做敏捷。”看来马上就要吃闭门羹，这时我该怎么办呢？

以我的经验来分析，团队不想做敏捷的原因有很多方面，不能只看表面，必须深层次挖掘，比如：

  1. 团队没有真正理解到底什么是敏捷、敏捷能给他们带来什么切实有效的帮助；
  2. 团队真的很忙（当然“忙”要分情况应对，是否是有效的忙碌也是一个值得探讨和挖掘的方面）；
  3. 团队中有人一言堂，这个人的意见不改变，其他人不敢动。

如上例，我在进行了调研之后发现，这个团队之所以很忙，其实是因为资深老员工不够信任新员工，凡事都要亲力亲为。那么我是怎么发现这一原因的呢？

在并不太被接受的情况下，我跟这个团队的 leader 说，我不影响你们工作，只坐在你们旁边可以吗？他表示赞同。

就这样我坐在他们团队旁边，观察他们的一举一动，没几天我就发现了这个团队的小情况。该团队有 2 名资深员工，其他 5 位都是新人。其中一位资深员工经常在团队工作中一言堂，与此同时，他不信任新员工，对新员工做的很多工作都不放心，于是基本上所有核心一点的工作都是这两位老员工在做，其他同事最多打打杂，这样他们不忙才怪呢。结果就是，两位老员工忙的脚打后脑勺，新员工却没什么大事儿可做，每天也不开心，总觉得自己被边缘化。

在分析了团队不想做敏捷的根本原因后，我制定了以下对策。

我决定从这位资深老员工下手，慢慢地解决问题。首先，我先找他分享了我的观察，谈了一些基本管理技巧；其次，我鼓励他试着慢慢放手，让其他团队成员参与进来，并定期做代码 Review。这样几轮迭代以后，他们的工作变得均衡了，老员工不那么累，新人也成长起来了，团队整体的满意度也提升了。在此基础上我们再引进敏捷的新思想和实践，也就无人反对了。

总而言之一句话，不了解和分析现状就直接推进敏捷是非常不靠谱的，必须看清现实，摸清项目的痛点，在解决痛点的基础上导入并推进敏捷才是可行的。

坑二：不理解敏捷实践背后的意义，把敏捷当作一种新的流程，而忘记敏捷的核心是持续改进

上面我们解决了团队不想做敏捷的情况，在实际工作中还有一种情况是：即使公司已在推进敏捷，但对于很多并不深刻理解敏捷的员工来说，他会说敏捷不就是一套新的流程或一种新的工具么？

我在调研 A 公司的员工时，发现大概有一半以上的员工认为“敏捷就是一种替代瀑布的新流程”，他们一直在开 Scrum 中的五个会议，已经开得烦闷而枯燥，也没看到更多显而易见的好处，但迫于高层的压力，不敢停下来。

于是整个团队每天都在机械地重复着，回顾会议里回顾的问题也就是反反复复的那几条，而这些问题基本上又是自己内部不能解决、需要别的团队协同或者高级管理层来协助解决的，但没有人去推动，问题就日复一日的挂在那里。团队里渐渐怨声载道，觉得敏捷只是凭空增加了很多会议，并没有带来什么新的好处。

面对这种情况，我认为他们犯了两个错误：

  1. 公司敏捷实践的基础导入工作没有做好，连敏捷究竟是什么，以及为什么要做敏捷都没给团队讲清楚；
  2. 缺乏一名强有力的敏捷教练做引导，在持续改进方面欠缺较大。

那么，如何能让整个团队更清晰地理解、接受敏捷实践呢？我认为可以通过两种方法来解决：

  1. **基础培训、基础培训、基础培训，重要的事情说三遍。**有很多公司舍不得投入前期的基础教学时间，大家对敏捷的理解一知半解时，就开始让大家照猫画虎、迅速铺开实践，这就造成大家在做各种实践之前根本不知道这样做的背后有什么意义，从而导致整个程序的僵化。通常来说，敏捷推进会经历三个阶段：做敏捷（doing agile）、思考敏捷（thinking agile）和思想敏捷（being agile），但如果只停留在“做敏捷”的阶段，就会出现这样的问题。
  2. **找一个靠谱的敏捷教练陪伴。**敏捷本身是一种变革，是从指挥和控制到协作的、以团队为中心的结构性转变，它也涉及到人的头脑和习惯上的改变，归根结底不是那么容易的。因此这种转变需要一个有丰富敏捷经验和有影响力的人来持续引导敏捷实践，敏捷教练就是这样的角色。敏捷教练不仅负责组织一个敏捷团队，还通过敏捷帮助公司进行企业文化层面上的转变。因此在推进敏捷过程中，你需要一位甚至几位敏捷教练的陪伴。

坑三：Scrum 过程被严重缩减，只剩下每日站会

在团队认识到敏捷会带来好处并开始推进敏捷后，是不是就可以顺利推进了呢？其实不然，在推进过程中你仍然会遇见各种各样的问题。

有一天，一个负责理赔服务研发的团队 leader 找到我，对我说：“宋宁老师，你快过来看看我们团队吧，我们的敏捷现在很尴尬，只剩下站会了……”我很诧异，因为这个团队之前做得还是很不错的，怎么就变成这个样子了呢？带着种种疑惑，我到团队进行了调研和观察，我发现该团队采纳的敏捷方法是 Scrum，但团队很默契地剪掉了里面几乎所有的会议，只留下了站会。

但是，先不着急下结论、给建议，在了解了该团队的敏捷实践经历后，我发现该团队在 A 公司整体的转型中导入敏捷较晚，刚开始大家还很有激情，每个 Scrum 的实践都做到了，将敏捷做得有声有色。但等他们的导入者走后，会议渐渐没人张罗，会议过程也无人关心、无人引导，慢慢地大家就开始觉得这些事情没有做下去的必要了。

再到后来，大家觉得聚到一起开会无话可谈、倍显尴尬，就自然省掉了这些流程，还美其名曰为了提高效率。半年以后，当他们发觉自己的敏捷有问题再请我去看时，整个敏捷实践已然是病态的了，前期的实践成果基本前功尽弃，我需要再花多出一倍的时间帮大家重新建立信心，重新燃起敏捷的火种。

那么这个团队的问题在哪呢？在我看来，最重要的问题是他们没有培养出属于自己的合格的 Scrum Master，这导致敏捷教练或咨询师撤场以后，敏捷的火种无人守候，敏捷的纪律无人看管。敏捷的效果在短期内并不容易显现，因此在团队的敏捷习惯刚刚养成还没有固化时，一旦敏捷教练或 Scrum Master 不在场，大家很容易迅速回到引入敏捷前的状态，使敏捷的成果付之一炬。

那么我们该如何解决这一问题呢？

**首先，你一定要认识到 Scrum Master 在敏捷实践中的重要性。**在团队还不成熟的时候，他负责宣讲敏捷的价值观、理念，也负责具体实践的导入和守护。一个好的 Scrum Master 在引导（facilitation）、教育（teaching）、辅导（mentoring）、教练（coaching）这四个方面都有很强的能力，并能根据具体的情景选择使用哪种能力来帮助团队体验敏捷带来的益处，坚定维持团队新养成的敏捷习惯。在领导力方面，他具有服务型领导的理念，是团队的主心骨，在构建敏捷文化等方面对推进敏捷具有很大的意义。

其次，要想将敏捷推进到底，必须在基层留有敏捷的火种。因而在推进敏捷实践之初，团队就应该计划一系列 Scrum Master 的培养活动，识别出优秀的 Scrum Master，然后相互配合着推进敏捷；每周举办 Scrum Master 工作研讨会，让 Scrum Master 学习和实践上文讲的 4 种能力。在敏捷实践后期，由 Scrum Master 来负责进行团队引导等工作，并听取敏捷教练的反馈意见，这样在敏捷教练离开之后，培养好的 Scrum Master 就会接过敏捷的大旗，专心引导和辅导团队，在团队遇到困难时及时帮助解决。与此同时，跟随着团队推进敏捷的步伐，引入新的合适的实践。

坑四：筒仓中的敏捷

所谓筒仓，原指贮存散装物料的仓库，用在研发领域，指的是部门各自为政，不好协同。A 公司的敏捷实践进行了一段时间后，这样的问题也出现了。

在 A 公司，开发测试部门的副总最先意识到敏捷的价值，他带着一腔热情，撸胳膊挽袖子，将开发测试部门敏捷了，然而敏捷的火种却并没有传播到其他支持协同部门，除了开发和测试部门以外，其他各部门之间还是各自为战，形成严重的筒仓。比如：

  1. 产品业务部门没有协同，因此对需求的分析理解还是极其缓慢，每次到迭代开始时，需求都准备不好，打乱开发的节奏；
  2. 上线运维部门也与开发测试部门割裂，导致虽然开发测试做得很快，然而到了上线那一步又变慢了，最终拖慢了整个进程。

因为研发管理的全链条没有打通，开发测试部门也不能真正感受到敏捷带来的好处，最后推动无力，大家越来越没有信心，敏捷遂在大家的愤懑中偃旗息鼓，人人不愿再提“敏捷”二字。

针对上面的状况，我们如何来解决呢？

仅就这个问题本身来讲，我认为前期应该多宣讲敏捷的本质和好处，尤其应该推**动对高管层面的宣讲，并成立更高级别的敏捷实践督导团队。**当高管层面理解到敏捷的好处和他们应该做的事情之后，就不会成为推进敏捷的桎梏，而能及时为敏捷提供必要的帮助，这尤其适用在一些大型的控制型传统企业中。

以 A 公司为例，现阶段要想实现“需求 - 开发 - 测试 - 运维”的全链条协同，必须推动组织变革。但该公司是一家大型国有企业，从某种意义上说，推动组织变革尤其是大部门的组织、合并、重组并不容易，必须由高层领导认可并推动才能完成。在经过谨慎的思考后，我鼓起勇气将这个问题提到了他们总经理办公会上，并跟总经理约到半个小时的访谈时间，借由这个机会向他宣导敏捷。最终的结果很让人满意，他们的高管高度重视这件事且推动了事情的进展。在咨询结束后大概几个月，当我做回访时，惊讶地听到他们已经做完了组织重组，并按照之前我们的规划进行了研发全链条的协同，不仅提升了研发效率也提升了研发的整体满意度。

就这个问题再深层次地挖掘一下，我认为：

**第一，推进敏捷时要通盘考虑整个链条应该怎么推进。**组织全功能团队，除了一个一个的研发敏捷小团队以外，还要考虑需求管理怎么推进，并想好推进策略。

**第二，敏捷可以分步推进，但是推进过程中一旦识别出新的阻碍，应及时去除。**像在本案例中，我相信当产品团队没有跟随一起推进敏捷实践时，整个敏捷流程很快就会有新的问题浮现出来，例如每个迭代前，需求条目都准备不好，在这种情况下，这个障碍就应该及时去除。

总结

好啦，我们今天的课到这里就要结束了，结合我给出的敏捷实践中的填坑策略，现在我来总结一下。

敏捷是个整体工程，需要从全局上来考虑怎样去推进。在前期，要做好诊断和规划，在解决痛点的基础上导入适合自己的敏捷方法；推进过程可以分步进行，要及时排查每一步中出现的新的阻碍；要加强协作，打通研发管理的全链条，必要时要成立高层参与的敏捷督导团队，请高层领导帮忙推动；在整个敏捷实践过程中都需要有能力的敏捷教练陪伴，并在推进过程中培养出适合自己团队的 Scrum Master。

从今天的文章你可以看出，推进敏捷确实不是一件容易的事儿，在推进过程中你会踩到很多坑，而在填坑时既要有方法的甄选，又离不开人力的支持，很多公司和团队之所以会遇到各式各样的问题，也是由于他们或是浅尝辄止，或是急于求成，没有把敏捷实践真正落实好。所以我相信，只要你稳扎稳打，踏实、耐心、正确地完成敏捷推进中的每一步，夯实基础、持续改进，再多的问题都会迎刃而解；你更会举一反三，成为一个真正的“填坑专家”。

思考题

我想请你思考下在推进敏捷过程中你踩到过哪些坑呢？除了文章中提到的方法，你还有更好的填坑方法吗？