深入浅出了解 OKR（九）：OKR和Scrum一起共舞

作为熟悉敏捷的高手，你也许已经发现OKR在很多方面和我们熟悉的Scrum有非常多的理念和做法高度重合。   现在可以拿出一张纸一支笔，尝试自己做一下分析，有多少是类似的，有多少是有不同的，有什么可以做融合，然后再看看和我的分析有多少差异。

在使用Scrum的时候，我们会经常碰到如下的挑战吗？

问题来自于哪里呢？我们看看下图，核心要回答几个问题：

大部分团队都是“近视眼”，视角都被限制在了“产品”和“特性”层，使得团队对于业务不熟悉，对战略不清楚。产品和特性层级的敏捷，只能解决交付问题，提升产品的响应能力，但业务层级的敏捷，非常难达到。大部分的PO，都是“产品设计”角度出发，是“产品设计师”和“产品管理者”，都很难触达战略，做到真正的“产品拥有者”。   如何破局呢？好的PO可遇不可求。使用“规模化敏捷”框架，看起来能够触达，但是挺复杂，学习成本和部署成本很高昂。我在实践中使用OKR来解决问题，将OKR和Scrum做融合一起使用。

企业文化是组织的价值观和行为准则，是企业创始团队的思维模式和认知模式的浓缩体现。它绝对不是公司贴在墙上的一些标语，文化角的一些口号，其背后隐藏了组织大量的深层假设，管理体系和流程，以及人事关系。   OKR和Scrum对企业文化的要求上有很多的一致性，比如价值驱动，透明公开、自下向上、以人为本、精神激励、内驱为主、信任授权、允许试错、学习成长等。这个是OKR和Scrum可以融合的基础。

适应性是OKR系统的核心特征，OKR做为源自管理2.0时代的工具，却很好的适应了管理3.0时代的要求，而Scrum的核心特征也是适应性。   在很多行为方式上，OKR和Scrum也有非常多的相似性，比如

从这个角度来看，OKR和Scrum是完全可以融合来使用的：

当然，融合不仅仅是OKR到Scrum的，我们在backlog中常用的优先级排序，我在使用时，也会借鉴到OKR中，对OKR的目标进行优先级的划分。   我们在敏捷中常用的MVP版本划分方式以及用户故事的拆分方法，也会借鉴到KR的制定中，使得KR制定更合理。   OKR和Scrum共同使用，相当于建立了大小迭代。大迭代是按照季度（一般来说12周）进行，小迭代按照1~2周进行。季度规划可以非常明确的提出短期目标和结果，以便于大家的聚焦和小成就的积累。     这样的好处还有很多，我们再看看OKR结构。 OKR的目标和关键结果，有没有类似我们说的“用户故事”和“验收标准”？   对于组织OKR，是我们说的“Epic”，目标是What，关键结果是How，回答了用户故事的Why。 对于团队OKR，目标是特性需求（Feature），关键结果是“版本标准”，回答了用户故事的What。 对于个人OKR而言，目标是用户故事（User Stoy），关键结果是“验收标准”，回答了用户故事的How。   当我们按照季度、月度和迭代这样的结构运行时，发现团队慢慢的发生了很多变化，对价值的理解更深刻，对业务和产品的支持更主动。   当然，OKR和Scrum的融合还有很多操作技巧，我也还在努力的不断探索更加高效的方式，同时限于篇幅不再过多描述，如果对这个话题感兴趣，可以和我联系。

OKR和Scrum共同使用，最直接的收益就是迭代目标非常清楚，版本目标和成果展现也不用再纠结。由OKR驱动，价值可以直接穿透到个人，上达到CEO，增加团队业务价值理解的深度和广度。   OKR的可见性好，根据我的经验，当你想谈论整个公司层面的目标或部门层面的目标时，OKR工作得非常好。当你想谈论每日、每周、每两周一次的工作重点项目时，更敏捷的Scrum方法非常有效。换句话说：OKR呈现了整体蓝图，Scrum给出了实现路径。   产品和特性交付的敏捷，对整体来说收益还是偏低的，是局部的敏捷，而且公司高层并不太关注，研发层级很少能和高层进行直接对话，让他们理解敏捷的含义和价值。借助OKR，敏捷的局部力量转为企业层面的，尤其是绩效能力的提升，会使得中高层全部关注。OKR的聚焦和短周期特性，还能促成业务敏捷的达成，当团队的交付能力稳定，并且团队成型后，OKR能让组织形成“指哪打哪”的强大能力。

所以，作为敏捷教练、ScrumMaster、PO的你，如果有机会可以推动OKR的开展，那更好了，可以突显成效，放大业务成果；如果组织和团队已经在使用了，那更要想办法介入，和敏捷更好的融合，促进目标和交付的双重成功。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。