你好，我是宋宁。
在前两节课中，我讲了如何做团队敏捷试点，这节课我就给你说说怎么把试点成功的经验做规模化推广。
试点不是目的，做试点是为了在我们的环境中探索敏捷实践的可行性，积累经验，若是确认敏捷在我们的环境中是好用的，我们就要根据试点结果，把这个过程中积累的成功方法推广到更多团队中。
那么其他的团队该怎么使用试点团队的成功经验呢？是不是把它们直接复制过来就大功告成了呢？
在我做咨询的经历中，我发现很多人都认为“规模化推广敏捷就是复制试点成功经验”，但其实这个说法只对了一半。
没错，我们是做了试点，试点中的经验教训也是可以拿来给后面的推广做参考，但如果直接复制未免有点简单粗暴。
举个例子。某个试点团队成功使用了Scrum，于是领导一拍脑袋，也不管其他团队能不能吃得消，直接让所有团队一股脑儿在一个月内全部上马Scrum。结果，有的团队导入Scrum比较顺利，而有的团队却遇到了很多困难。
其中，一个团队做的是运维类的项目，由于运维类项目开发的内容通常来自客户的建议或生产上的Bug，比较零散，没有一定的规划性，所以对于他们来说使用Scrum并不合适，他们其实更适合使用看板；还有一个近百人的团队，产品本身比较大，团队拆分后有十几个小团队，只使用Scrum却没有解决好团队间的协同问题，效果同样不佳。
从这个例子你可以看出，上面这位领导除了拍脑袋和一刀切做决策，在推广敏捷时也只是机械地简单复制试点的成功经验，这非但没有给其他团队带来好处，对于他们来说反而成了一种桎梏。
此外，试点涉及的主要是团队内部的敏捷，而规模化推广还要涉及团队间的敏捷。
在做试点时，我们更多解决的是小团队内部的敏捷怎么用，所以对于单一小团队来说，借鉴试点中的经验更为便利有效。
而当你想规模化推广敏捷时，一旦小团队的数量多于两个，就会牵涉到团队与团队之间的协同问题。当然，在多个团队一起开发同一个产品的情况下，试点可能就是在多个团队中同时进行的，那么团队间的管理你也多少会涉及到。
当小团队数量多于5个时，如果你用的是Spotify这个组织模式，那小团队的管理就上升到部落（Tribe）级别，这时就要考虑部落内的管理了；而如果你的团队数量超过一个部落的范畴，你还需要考虑部落与部落间的管理。所以说当团队足够大时，它在管理上也就更复杂，使用管理小团队的方法就不够用了。
所以，从试点到规模化推广，是要从团队内敏捷扩充到团队间敏捷的过程。由于牵涉到团队间的协同管理，团队间的敏捷较之团队内的敏捷更为复杂，因为你要开始考虑让各个团队方向一致而不是互相羁绊，还要考虑跨多个迭代、多个团队、多个产品的情况下推进计划和安排优先级，更要考虑团队间的依赖、更大规模地沟通协调、多团队版本控制等一系列的问题，所以要想做好规模化推广，直接复制团队内敏捷的成功经验远远不够。
关于怎么做敏捷的规模化推广，当前有两个主流的框架，SaFe（Scaled Agile Framework）和LeSS（Large Scale Scrum），这里我不想用大量的笔墨给你介绍它们，如果你对它们的具体内容感兴趣，可以去它们各自的官网了解一下。
而之所以提到这两个框架，是因为它们是如今做规模化推广比较成熟的范式，它们的方法可以为我们提供参考，有很多团队甚至直接套用这两个框架，但我并不建议你这么做，因为它们都有各自的长处和短板，如果你使用不当，反而会陷入敏捷实践的歧途。
其实不只这两个框架，每个框架都有各自的优劣之处，所以我想和你强调的是，要想做好敏捷的规模化推广，不要套用框架，也不要被框架限制，只要它们的可取之处能帮到我们，你就可以有选择地拿来使用。就像我在一开始讲敏捷的价值时提到的，是不是冠以敏捷的名称不重要，只要它能帮助我们解决问题就好。
那规模化推广到底该怎么做呢？我认为，在做之前，还是要从企业或团队的痛点切入，看他们究竟需要解决什么问题。分析具体问题后，你可以从下面这些方面考虑怎么去推广，并形成自己的方案：
接下来我会结合一个案例，来给你讲具体怎么做大型团队的敏捷导入与推广，做好了这点，我相信你的规模化敏捷之路会更加平稳顺畅。
这个案例来自一家银行，我们姑且叫它D公司，他们的研发团队有接近2000人，在比较顺利地做了试点后，希望做规模化推广，让敏捷为整个公司的研发赋能。
我先分析了他们的痛点，总地来说就是研发效率比较低，无法满足业务发展的要求。他们的问题也很突出，主要有3点：
针对问题1，我们在规模化前的试点中，改变了研发模式，让小团队使用了Scrum，很有效地解决了这个问题。
而问题2和问题3涉及的就是大型团队导入与推广敏捷最需要解决的两个问题。要想做好规模化敏捷，主要就是要突破这两个问题。
那么该如何解决这两个问题呢？
针对问题2业务人员参与度低这个问题，其实就是D公司在推广时忽视了业务这一环。
你要注意，只做到开发、测试团队的敏捷，只算是敏捷的一个小胜利，最重要的是要走向业务敏捷。只有业务敏捷了，我们才能和IT团队一起真正打通研发整个过程的敏捷，才能在短时间内快速交付业务价值。
因此，大型团队敏捷的导入和推广，首先要打造端到端的、从需求到开发到测试到运维到运营的敏捷全生命周期，向业务敏捷靠拢。
所以针对问题2，我们主要通过两个方法来解决。
第一是定制度。确立产品负责人制度，将过去以“项目”为中心的管理改为以“产品”为中心的管理。只有这样，才能让业务战略与产品战略合二为一，让整个团队目标一致，“劲儿往一处使”，从而方便团队做好研发全链条的敏捷。
第二是定反馈机制。在整个产品研发流程中进行数据收集和处理，做到从业务创意和机会捕捉到需求识别，到开发上线，再到业务运营的整体大反馈闭环。这样做的好处是为端到端的研发过程提供了数据支持，以便在后续工作中识别整个研发过程的瓶颈，为持续改进做支持。
针对问题3跨团队沟通不畅这一问题，涉及的就是团队间的敏捷实践。
我们很多团队在需要兄弟团队协助开发时，总是希望对方在我们需要时能够随叫随到，但每个团队都有自己的优先级工作，哪里有时间随时“听喝”呢？
因此，要建立各团队间的敏捷实践，就需要提前安排支持工作。这样，你们团队需要协助的工作就会被排入对方的工作列表，就更加易于团队间依赖关系的管理，省去了很多无效的沟通和无谓的等待。
由于管理实践是后面一切具体技术实践的基础，因此在这里我只想教你如何在管理实践上探索团队间的敏捷，带你做好这关键的第一步。
所以针对问题3，我们主要是建立沟通机制，对齐团队目标，把“做什么”和“怎么做”这两个方面的目标对齐以后，团队间的沟通就更加有序和高效了。
具体的措施是定义了一系列关于产品团队内以及与Scrum团队间的沟通策略和沟通机制，定期的产品集体计划会议，并将团队间的依赖放到看板上，通过Scrum of Scrum来定期沟通进展。其它还包括一些具体的技术实践，例如怎么进行团队间版本控制，团队间的架构解耦等等。
把这两个问题解决好以后，D公司根据自己的情况优先选择了做管理实践的规模推广，又在工具和自动化方面做了更多工作。考虑到要做敏捷的长期实践规划，我们又通过培养核心人员，也即内部敏捷教练来延续企业的敏捷文化，具体的举措，你可以参考后续09的文章来看。这样他们的规模化敏捷工作就开始平稳地推进下去。
最近我又对他们进行了电话回访，发现几年以后的今天，他们内部已经完成了规模化敏捷1.0，目前正在循序渐进地推进规模化敏捷2.0，重点放在DevOps方面的建设。据其核心负责人反馈，他们一直在做持续改进，我为他们的持续性探索而开心，因为这也是敏捷的本质所在。
好了，现在我想总结一下今天这节课的内容，以利于你更好的理解。
敏捷的规模化推广不是去简单拷贝试点经验，也不是找来几个规模化框架往企业身上套，而是需要根据企业的研发管理痛点和需要解决的问题，根据实际情况寻找解决方案。当然在这个过程中，成熟的规模化框架可以给予我们参考。
规模化推广敏捷的核心是大型团队的敏捷导入与推广，主要集中在业务敏捷和团队间敏捷这两点上。你可以通过定制度、定反馈机制推进业务敏捷，可以通过在管理实践上建立沟通机制，对齐团队目标来保证团队间敏捷的高效和有序。当然除了这一点，你也需要统筹全局，从推广策略、文化、环境等方面完成整个规模化推广的持续改进。
敏捷的推进不是一帆风顺，但是走到了规模化推广这一步，我想由衷地恭喜你，因为这意味着你的敏捷实践已经克服了很多困难并取得了一定成果，我相信只要你以更加坚韧的心态和努力的态度去不断检视、改善自己，坚持下去，你的敏捷实践一定会取得更大的成功。
现在，我想请你来思考一下，假设你在一个大型的研发组织里，你会怎么做敏捷规模化推广呢？你有成功或失败的经历吗？
我是宋宁，欢迎你在留言区与我分享你的疑问和思考。如果你觉得这篇文章对你有启发，也欢迎你把它分享给你的朋友，我们一起来探讨和学习。
评论