• Five_reasons
  • Cal2_20220108
  • Hardware-agile-practice
  • 2020-scrum-guide-banner
  • Clp_20220108
  • A-CSM 国际Scrum联盟认证 ScrumMaster
  • 敏捷思维 领导力 企业培训 国际Scrum联盟认证
  • 汽车行业敏捷开发课程
  • CSM A-CSM Scrum敏捷实践
  • 敏捷领导力认证培训  CAL认证培训 CST CSP
  • 30天软件开发 敏捷规模化实践 Scrum精髓 敏捷文化
  • CSM CSP CAL CSPO CSD CST CEC CTC
  • Scrum敏捷培训 Scrum敏捷企业内训
  • Scrum敏捷软件开发管理 企业内训 Scrum转型
如何用Scrum做变革管理的落地实施

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 与多个团队的沟通机制

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

  ......

总之,Scrum 提供了用Scrum 做变革管理内容的落地实施的一个框架,这也是Jeff 经常提及的Scrumming Scrum。Pete Behrens 在他的CAL 课程中(见下图示)介绍的Use agile to be agile。

后续我还会写一些关于敏捷转型变革管理的短文与大家进一步探讨,感谢关注。