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