如何用Scrum做变革管理的落地实施|ShineScrum认证

2019年至今，我接触的客户来自于制造业，能源，制药，零售，汽车等行业，多数是HR、PMO 的同事来咨询如何帮助团队和组织转型，当然也有老板授权HR、PMO 收集供应商信息，这些多数是“假”的需求，HR 或者负责培训的人员会索要一些资料，比如“成功”的案例，往往是拿到一通材料后，就“销声匿迹”了。这里面有要面试讲师的，要走Bidding 流程的。对于来寻求帮助的客户，我最看重的是：(1)老板能否拍板 (2)有无预算 (3)公司内部是否已经有团队尝试敏捷实践。这些都是衡量优质客户的特征，也是我们愿意合作的对象。当然我们可能会“得罪”并错失一些潜在的客户，特别是有些需求部门让我去说服(Convince)他们的老板去做敏捷。对于这几种情况，不停的问机构要资料(Paperwork)和成功案例，一个接一个的邮件Loops 的Back and Forth 沟通方法，甚至要老师去现场讲标，我都不看好这些机会。

大的转型(Transformation)也罢，小的Transition 也好，或者新词叫新常态(New Normal)，本质上就一个词——“改变(Change)”。改变这件事本身是很难的，我们大多从研发部门的员工开始，比如导入Scrum，做培训。但我们发现：HR/PMO 的工作方式却依旧未变，老板还是迫切“追要”一个确定的交付时间表，Leadership 的行为没有变化，最终结果是团队的敏捷也不能持续下去。结论是，一个组织光靠一个教练是不够的，需要把HR/PMO 拉进来入伙，需要一个C level 的Scrum 的“教父”领导者参与和支持变革，要有变革的愿景和敏捷思维(Mindsets)框架来指导实践。否则转型这件事情只能停留在研发团队上，收益不大，还会回潮。

过去几年我参与辅导客户用Scrum 这个框架来做创新和变革管理，比如说如何把制造业的精益思想小步改善(Kaizen)落地；HR 引入一个新的薪酬系统，涉及员工理念和工作方式甚至绩效考核；PMO 在指导团队跑Scrum 的时候，发现一些组织的阻碍，如何有效的移除这些障碍并度量移除。

下面我想聊聊如何用Scrum框架来执行和落地组织的变革管理(Change Management)。

Scrum 框架就是把要做的这些事情(Things)从价值的角度排序，小团队在较短的时间内专注优先级高的几件事情，尽快搞定，看结果给反馈。Scrum 是一个管理交付的框架，也是一个快速做决定的赋能框架，同时伴随反馈，学习和协作的发生。

下面以一个如何运用Scrum 来落地变革管理内容(Content)的例子，以工作坊的形式来解释如何操作。为了方便描述，我们假定这个变革管理项目叫NPS，你作为敏捷教练，考虑下面的步骤来落地NPS 的实施。

产品要有愿景和目标，即NPS 也应该有Vision 和目标。

NPS 将赋能三个维度：

1.赋予员工发展的自主权

2.支持经理拥抱业务敏捷性

3.提升人力资源的能力

我们使用Business Agility 画布(见上图)，识别出NPS 是六个赋能(Enabler)中的People & Engagement。

参照上面改善计划的Backlog 例子，NPS 初期建立Product Backlog 的几个Epic 有:

· 宣传和教育NPS 的好处

· 营造员工在职业谈话中的心理安全感

· 经理们具备如何引导有意义的员工发展对话

· 获得人力资源支持

也可以用影响地图建立待办列表。从目标到角色，到影响，再到交付物，影响地图是连接目标和具体交付物之间的树状图谱，见下图：

通过头脑风暴的形式共创产品待办列表，PO 阐述这个NPS 项目的愿景，聚焦出一个阶段性的目标。这个目标是可以度量的，而且是有时间约束条件的，尽量满足SMART 原则。Specific(明确)，Measurable(可度量)，Action-oriented(面向行动)，Realistic(现实)，Timely(有时限)。定义目标的目的在于：当获取到新信息时，交付方和业务方能够重新评估计划。

通过建立产品待办列表，每个团队练习尝试以“用户故事”的形式来描述用户的真正需求，我们发现NPS 有三种典型的用户：HR 人员，一般员工及经理们(Managers)，有点类似用户画像(Persona)的概念。在工作坊中，PO 确定了经理们对NPS 的Impact 优先级最高，重新排定了产品待办列表的优先级，然后对需求进行了澄清和拆分。

这里一个契机来引入产品待办列表梳理PBR(Product Backlog Refinement)活动的概念，并借用视频来演示，让团队感受到这是一个渐进明细需求的过程，业务和交付团队持续对话的活动，目的是保证下一个计划会议的需求进入“Ready”状态。

PBR 活动中估算是一个话题，讲师介绍了敏捷估算的原理和理论支持，并让学员现场体验相对估算的好处。估算的目的是为了“学习”，通过“面对面”的对话来对需求的理解达成共识，而不是传统思维，以一味追求估算的“精准度”为目的。

下一个话题着重讨论Scrum 框架下的角色，担责(Accountability)和责任(Responsibility)，讨论PO/SM 能不能是同一个人，SM 全职和兼职的利和弊。具备做PO 和SM 候选人的资质和特征，知识和技能。在Scrum 框架下传统项目经理的职责哪儿去了？

Scrum 开发团队与传统团队的区别，跨职能自组织对团队意谓着什么。团队工作协议如何建立，好的一份工作协议的特征是什么？高绩效团队的特征有哪些，SM 的一个最重要的职责——提高团队的效能(Effectiveness)。

最后系统介绍了Sprint 中有哪些事件发生，特别是Sprint 计划会议如何组织更高效，以任务(Task)驱动日常团队工作的Scrum 白板的建立，站会，评审会和回顾会的技巧和经常犯的错误。Sprint 是一个固定的时间盒，Sprint 的好处有什么，Sprint 目标是用来度量团队交付价值的进度进展，PBI 用来定义和实现价值的增量交付。

工作坊活动中，出乎意料的是，Scrum 团队通过开放空间的自组织形式，花了不足半个小时就组建好了团队，PO 的人选是组织提前确定，SM 的角色由团队自选或自荐，公开竞选演讲投票。

我们给学员留出时间把第一个Sprint 承诺的以Sprint 目标的Sprint Backlog 规划出来，并分解成具体的任务项。

在规模化敏捷方面，介绍了Scrum of Scrums 和Meta Scrum 的概念。核心思想：团队共享一个产品目标(Product Goal)，PO 是一个人而不是一个委员会，多团队共同拥有一份产品待办列表。

在工作坊中，团队讨论以下话题，项目启动的清单(部分)：

· 团队工作协议画布的制定

· Scrum 事件日历确定

· PO 与多个团队的沟通机制

· 管理产品待办列表的工具

......