领导规模化敏捷变革8步法之五：授权赋能，自下向上发动

在前续系列文章《独家详解：领导敏捷规模化变革的8个步骤》中，介绍了这张图以及前四个步骤：①唤醒意识，②树立危机感、组建敏捷转型委员会，③树立转型的愿景，④沟通愿景（③和④汇总在第三篇里了）。

本文介绍第5个步骤： 授权赋能，自下向上发动。

常见疑惑：

敏捷转型是自上向下地命令执行，还是自下向上地自组织、自发展呢？

答：敏捷涉及到所有人，如果没有得到广泛的支持，单靠自上向下的愿景沟通、发号施令、监督控制，大规模的转型不可能发生。相反，如果纯粹地自下向上，让员工自组织开展敏捷活动，没有系统化地设计和领导，必然走不长远。

常踩的坑：自生自灭

在很多企业里开展的敏捷活动，都是自下向上、零零星星的星星之火，没有系统性地规划和领导，结果大都自生自灭。

因此，转型需要自上向下设计和沟通愿景，以及授权赋能，充分发挥每一个敏捷团队、每一个员工自下向上的力量。授权赋能有以下几种方式:建立敏捷实践社区、提供培训和辅导，以及解除与敏捷转型相左的桎梏。

一、建立敏捷实践社区

敏捷实践社区是以敏捷实践为单位构成的虚拟组织，比如：Scrum论坛、持续交付俱乐部、测试自动化社群等等。敏捷社区是由企业员工自愿组织的兴趣社团，本着交流敏捷实践、提升企业的敏捷能力为目的。敏捷实践社区的来源可以是企业敏捷转型委员会的Backlog，也可以是企业员工由兴趣出发自发组建。即便一个敏捷实践社区来源于企业敏捷转型委员会的Backlog，也是由企业员工自己主动认领，而不应该是由领导自上向下任命组建的。

如果说敏捷转型委员会是组织的官方力量，那么敏捷实践社区是组织的民间力量，它就像组织里播种的敏捷种子，生命力顽强，且传播迅速。

案例：

企业H开展敏捷转型开始的时候，成立了两个实践社区：

Scrum Master论坛

这个社区的宗旨是为那些新的Scrum Master提供快速成长的平台。由一位Scrum Master主动发起，每隔两周召集公司的所有Scrum Master聚集一次交流探讨经验，每次交流的话题由大家投票决定。

持续集成俱乐部

增强团队持续集成的能力是转型委员会的Backlog里的一项重要工作。转型委员会将这项工作拆分了几个重要任务，其中一个是成立持续集成社区，让持续集成实践在组织里迅速传播。委员会在企业内网上发布了求贤贴，招募社区的组织者。不久，一位工程师报名，他在之前的企业里有深厚的持续集成、自动化测试的经验，来到一个持续集成从零起步的组织，难以忍受这里的落后的工作环境，于是主动请缨，愿意组建这个社区，传播持续集成和测试自动化实践。

此外，每个敏捷团队也是重要的敏捷种子，他们身体力行地每天在实际工作中实践敏捷。敏捷转型委员会与敏捷团队、敏捷实践社区的关系如下图所示。

敏捷转型委员会与敏捷团队、敏捷实践社区的关系

首先，每一个实践社区、每一个敏捷试点团队与敏捷转型委员会的各自运作模式就像一个独立的Scrum团队，他们各自维护一个改进事项Backlog，迭代式运作，持续改进。

其次，这三个组织单元之间保持密切协作。敏捷转型委员会向每一个试点团队、每一个实践社区沟通转型愿景，并授权实践社区和试点团队自管理。每一个试点团队、每一个实践社区向敏捷转型委员会反馈所需要的支持、遇到的障碍，敏捷转型委员会将这些纳入Backlog。

实践社区与试点团队之间也有密切的合作关系。实践社区将形成的优秀实践、分享的知识及时传递给每一个试点团队，帮助试点团队快速成长；试点团队定期将自己实践的一线经验分享给各个实践社区。由于实践社区组建的范围覆盖到整个企业，所以，试点团队通过实践社区可以将自己的经验迅速传播到企业的其他团队，从而加速敏捷在整个企业范围内的发展。

二、提供培训和辅导

敏捷涉及到所有人。因此，最好让每一个人接受正式的敏捷导入培训。但是碍于企业的人数众多以及预算有限等原因，经常不可能让每个员工同时参与培训，因此可以分多个批次滚动式进行。优先从管理团队开始，然后让项目经理、产品经理、测试经理这些承担项目的一线管理角色的人参加培训；再次，选择试点团队后，让试点团队全员参加培训；之后，在每一个新的团队启动敏捷之前为这些团队的全员提供培训。这样逐渐地就覆盖到了每一个人。

光给大家培训还远远不够。如前续文章领导规模化敏捷变革八步法之二：组建敏捷转型委员会所介绍，敏捷转型委员会还需要雇佣或自己培养敏捷教练，为管理层和试点团队提供手把手的辅导。敏捷的理论听起来简单，做起来却十分困难。敏捷教练的辅导要着重针对以下角色：

每一个试点团队的Scrum Master和产品负责人
职能经理层
技术实践的辅导，着重针对开发者和测试者

辅导可以从以下几个维度开展：

对于试点团队的辅导，要遵循试点团队的迭代周期。迭代计划、迭代进行中的每日站会以及每日开发工作、迭代回顾和评审都是辅导的时间点。
对于管理层的辅导，可以采取一对一的线下交流方式。在管理者反馈自己的疑惑或担忧的时候，是开展辅导的好时机；此外，敏捷转型委员会的例行会议上对整个管理层的每个职能经理都是开展一对多辅导的好机会。
技术实践的辅导，要深入团队的每日开发和测试工作，与团队坐在一起工作，这样便于开展辅导。
针对关键角色，比如Scrum Master、产品负责人、职能经理，可以采取大量的一对一的方式，针对每个人的实际情况开展辅导。

培训和辅导的过程不止是传递知识和经验，同时还是消除阻碍的过程。很多阻碍都是由于人们对敏捷的不了解，由于无知产生了恐惧和抵触。

三、敢于解除与敏捷转型相左的流程桎梏

在敏捷转型的道路上，如何对待与敏捷相左的现有流程呢？这需要管理层具备大格局，为了实现更大的愿景，敢于改变现有体制中与敏捷转型相违背的流程，哪怕承担风险和可能面对的抵触、指责。

案例：

某企业启动敏捷转型的试点后，很快团队暴露了一个问题，提交给敏捷转型委员会决议：按照公司原有的流程，每个工程师需要在每天下班前给部门经理和组长发日报，总结今天做了什么，工作有什么进展和问题；此外，每个团队的组长在每天下班前需要将每个工程师的日报汇总成一个团队日报，发给整个项目群(Program)的经理。

团队发现，自从试点敏捷后一切信息和状态都在看板透明呈现上，不再需要让大家做日报。如果哪位领导感兴趣，完全可以通过看板看到一切信息。

敏捷转型委员会就这个议题开展了讨论，一些部门经理仍旧习惯于在座位上收取邮件报告；项目群(Program)经理也认为，发日报的习惯自古就有，不能因为做敏捷就取消了。试点团队的Scrum Master反馈，由于开展敏捷后，他不再需要工程师发日报就可以清楚地知道每个人工作的状态，因为团队有每日站会的实践。现在还让大家发日报，让大家非常反感。日报和站会，只能保留之一。

激烈讨论后，敏捷转型委员会决定，站会是高效的团队协作工具，在开展站会实践的团队里，日报成为一个不增值的工作，于是，自此取消了工程师做日报的负担。

在管理者的眼里，日报不是件大事，每天只耗费工程师10分钟的时间。但是在工程师的眼里，每天重复地花10分钟做一件浪费的工作是一件沮丧的事情。如果敏捷转型委员会不采取措施改变原有的工作方式，那么团队会认为敏捷加重了负担，在做原有的那些日报、周报等的基础上，又增加了一些新的管理会议，每天还得移动看板上的用户故事和任务卡片。

这里举的例子是个小例子。在实际中，有很多与企业现有流程冲突的更严重的情况发生。需要注意的是，不是在所有的现有制度都需要向敏捷转型让路。转型委员会需要针对每个冲突情况分析风险和代价来决策。有些时候，改变现有流程的时机也许当前还不合适，需要推迟改变。