敏捷与OKR实践(如何让OKR与敏捷计划共存)
僵化的详细长期计划(根据消耗的预算跟踪进度)正在敏捷组织中迅速成为对过去的褪色怀旧记忆,这由预测和非静态路线图代替。定期在这些可视化文件前聚会,您将能够学习、共享并触发重要的对话,解决依赖性并邀请服务型领导的行为。使您的OKR和预测计划共存!
在这个博客中,我想给出带有可视化示例以及伴随的重复仪式。可视化和伴随的仪式可以共享进度,并确保持续解决和减轻障碍和依赖性。它还将预测变成对话(与被视为承诺的项目计划中捕获的固定估计相反)。
参与团队回答的核心问题是:
敲黑板 - 划重点(译者注)
"您是否有信心在本季度末之前完成关键结果?"
你可能还喜欢 Google OKR小册子

如果您不熟悉OKR,目标和关键结果的概念,则可以将目标视为"让我们对这一领域/问题/需求加倍研究",而关键结果则视为"让我们完成这一特定影响/结果/目标/交付成果"这将推动我们朝着目标迈进。" 对于每个季度,目标数量通常限制为3-5。每个目标依次具有3-5个关键结果。常见的指导原则是,平均而言,您应该以关键结果的70%成功,即以30%失败,这是正常的并且可以接受。该准则可确保我们设定大胆的目标,并避免安全起见。为什么?好吧,如果我们惩罚成功率不到100%的事情,我们最终将优化军阀制度。
OKR白板站立会议
当2017年重新引入OKR时,我曾在Spotify担任敏捷教练。我所工作的部落(认为半自治部门)不希望OKR成为PowerPoint中的静态幻灯片,而该幻灯片很快就被人们遗忘了,但是在生活我们可以随时"计划",以找出如何互相帮助。
与其以数字演示形式总结部落的集体协作的OKR,我们将它们(OKR)写在一块大白板上,该白板在所有团队旁边的走廊上非常醒目。每两周一次,我们进行OKR白板的站立会议。希望加入的每个人都受到欢迎,但我们要求每个团队(八个团队)至少有两名代表参加。
会议的例行很简单。我们走上了白板,一次实现了一个目标。对于每个目标,我们都会大声读出关键结果的措辞。提供该关键成果的工作团队简短地分享了进展并宣布了他们的信心水平。会议持续了15至25分钟。
置信度
对于每个关键结果,相关团队都回答了以下问题:
"您是否有信心在本季度末之前完成关键结果?"

绿色自信的笑脸 --完全自信这会发生。我们可以准备市场营销活动。

橙色担忧的笑脸 --我们可能做不到,应该提醒利益相关者。

红色悲伤的笑脸 --没办法。这不会在本季度内发生。不过,我们仍在努力。

检查 --完成。已交付。做完了。

停止 --我们已停止进行此工作(...由于优先级的改变或关键结果本身已变得无关紧要)。
每个关键结果下方都有6-7个框(取决于该季度中发生了多少个两周的周期),每个OKR白板站立会议都用掉一个框。当我们进行第三次站立时,我们填写了第三个方框,依此类推。这种方法使我们对我们的信心水平有了历史的认识。

如果有几个团队提供相同的关键结果,那么他们每个人都分享他们的进度和信心水平。但是,最悲观的置信度是框中显示的置信度。
提供关键结果的团队名称以方框下方的小文字表示。
实际上,我们有第六个符号-?问号表示"我们还不知道"。有时事实证明这是现实,他们真的不知道。但是对我来说那很奇怪。如果团队不确定自己是否有决心在OKR周期内实现目标,那么如何使团队"致力于"关键结果?但是事实证明它很有用,因此我们使用了它。
关键对话触发器
但是,重要的不是信心笑脸本身的更新-重要的事件是当笑脸的颜色从上次OKR白板站立起改变了颜色。
这些变化是重要对话的关键触发因素。绿色的笑脸变成橙色或红色的笑脸时,我们暂停下来,直到我们共同弄清楚如何采取行动后才继续进行讨论。房间里谁能帮忙?会议室中的谁可以将需要帮助的团队与可以帮助的人联系起来?我们需要提醒利益相关者吗?谁提醒利益相关者?要改变置信水平吗,需要做什么?等等。
仅在决定了至少一项有力措施(有可能推动我们前进)之后,我们才进行下一个关键结果。
即使每个团队每天都尽自己最大的努力来减轻障碍和解决依赖性,但OKR白板站立会议提供了一个反复出现的机会,可以将问题升级为需要扩大支持的朋友和领导者组织。
庆祝完成
当有人宣布他们完成"关键结果"并在框中打勾时,我们显然以雷鸣般的掌声庆祝。
服务型领导的机会
最初,一名敏捷教练协助OKR白板站起来。在前几次的站会中,三个部落首领都没有找到时间来参加。但是在第四次站会,其中一个部落首领加入了。
在几分钟之内,我相信他意识到这是一次千载难逢的良机,可以阅读所有团队的脉搏,对进度进行汇总并提供有益的服务型领导行为。他可以提供建议(在被问到时),为团队面临艰难的选择时提出前进的道路,并由于他或她的广泛网络而提供帮助,将需要的团队与利益相关者和组织的其他部门联系起来。
下一次OKR白板站立会议,所有部落首领都作为观察员参加了会议,准备在被要求时提供帮助和支持。很快他们甚至轮流为仪式本身提供帮助。
OKR白板审查会议
当季度结束后,我们聚集在一起参加OKR白板审查会议。我们回顾了已完成的关键结果,并讨论了未完成的结果。我们能学到什么?在下一个OKR周期中,我们可以带些什么?我们如何改善可视化和OKR板站立状态?
完成百分比
在第二季度,我们运行OKR白板站立会议,我们添加了一个方面来尝试使进度更新更加完整。对于每个关键结果,相关团队不仅回答他们的信心如何,而且还估计到目前为止他们已经完成了多少工作。(译者注:这个百分比慎重加)

我们为什么要这样做?好吧,我们觉得我们缺少故事的一部分。我们了解到,有时即使有些团队只是猜测自己已经完成了10%的工作,他们还是感到超级自信。有时,即使90%的工作都完成了,团队也感到非常悲观。在某些情况下,这是非常有用的信息。
组织内传播
当下一个OKR周期的时候,我们进行OKR白板后续行动的方式已在内部传播。令我们感到惊喜的是,几个部落抄袭了我们的方法。
当某种东西传播并在内部进行时,这是工具/技术/方法有用且有价值的最好"证明"。
可能的变化
如果这种方法对您有所启发,但您在团队或部门中未使用OKR,则此方法有许多变体,仍将静态预测转换为持续对话,从而触发重要对话。
预测扑克计划
如果假设我们正在处理解决一系列特定问题或完成功能之前无法交付产品,那么我们可以要求团队成员逐个猜测 "多少周/每次冲刺可以完成我们需要达到X?"通过在便利贴上写下他们的猜测。

删除最悲观和最乐观的投票,并在白板上写下剩余的范围。如果估计范围不会每周减少一周,那么您就有机会讨论可能采取的措施或缓解措施。
截止日期置信度
有时我们需要应付一个固定的期限。也许我们的机会窗口有限,或者也许我们必须在特定日期之前满足法律要求(例如GDRP)。然后我们可以问团队"我们在日期Z之前完成X的信心如何?"

可以用五个手指进行投票。一根手指代表超级悲观,五根手指超级乐观。三根手指可能意味着紧张。如果信心没有每周增加一次,我们将讨论需要做的事情或摆在我们面前的选择。

版本的猜测
一些团队会持续交付,但仍需要与利益相关者和客户沟通进度和期望。他们从产品待办列表中拉取工作加入到Sprint中。

可视化预测的方法是在Backlog中添加两行(例如,使用胶带)。
每个Sprint Review团队的成员都会问自己两个问题:
"我们对在接下来的四个冲刺中交付多少产品列表条目充满信心?"
"在接下来的四个冲刺中,我们还能提供多少呢?"
绘制一条绿线以可视化我们有信心我们将完成产品列表的工作。绘制红线以可视化乐观范围。
如果团队使用故事点来估计其用户故事并保持历史速度记录,那么这无疑是对团队猜测工作的重要投入。
当然可以将"四个冲刺"的时间范围替换为"接下来的两个月"或其他适合团队的时间。
结论
不要将您的估算、计划或预测制作成静态的数字文档,而该文档应位于云文件夹的深处。一定要可视化,使它可见,可访问。经常聚集在可视化文件的前面并共享进度,更新预测并讨论如何帮助您减轻障碍和解决依赖性。使其成为共存。
这不是火箭科学。这是一个简单的健康习惯。
你可能还喜欢 Google OKR小册子
作者: Jimmy Janlén
译者: Bob Jiang
原文链接
本文首发于 Bob Jiang的博客 ,转载请联系 Bob Jiang
敏捷与OKR实践(如何让OKR与敏捷计划共存)的更多相关文章
- 系列文章|OKR与敏捷(二):实现全栈敏捷
OKR与敏捷开发的原理有着相似之处,但已经使用敏捷的团队再用OKR感觉会显得多余.这种误解的根源就在于对这两种模式不够了解,运用得当的情况下,OKR和敏捷可以形成强强联合的效果,他们可以创造出以价值为 ...
- 4星|《OKR实践指南》:老司机经验谈
OKR 实践指南:知乎任向晖.雷明灿作品 (知乎「一小时」系列) 作者所在的公司已经实施了OKR十个季度了.算是目前少有的OKR老司机.书中介绍的是作者的实践经验,在目前的OKR中文书中这本算是比较少 ...
- 如何让OKR实践变得更简单一些
什么是OKR 近几年OKR的概念在国内开始流行起来了,之前公司也有人想实施OKR,但现在看来之前的OKR实施者只是在哪儿看了一下OKR的资料,本着跟老板邀功的想法比较功利的在推进,所以基本没有效果,今 ...
- 互联网大厂目标管理OKR实践落地与反思
上一篇「 互联网公司目标管理OKR和绩效考核的误区 」介绍了使用 OKR 时要澄清的一些概念,但是实际使用中又如何呢?我们快手也是很大的互联网公司,大家都是年轻人,思维活跃,容易接受新事物,敢尝试,但 ...
- 敏捷开发--洞察敏捷模型,从PO的角度看敏捷产品管理
转自本人运营的公众号“ 携程技术中心PMO”(ID:cso_pmo) 经常有人抱怨的一个问题:敏捷会让团队自组织,要求团队能“一方有难,八方支援”,但是为什么总感觉自己团队虽然实践了敏捷, ...
- 系列文章|OKR与敏捷(一):瀑布式目标与敏捷的冲突
OKR与敏捷开发的原理有着相似之处,但已经使用敏捷的团队再用OKR感觉会显得多余.这种误解的根源就在于对这两种模式不够了解,运用得当的情况下,OKR和敏捷可以形成强强联合的效果,他们可以创造出以价值为 ...
- 每日站立会议——敏捷流程scrum实践
每日站立会议是敏捷流程scrum中的很重要的一个制度之一. 功能: 1.快速同步进展,让项目组内部的员工互相了解彼此的进展,从而了解本项目的整体进展. 2.给每个人一种精神压力,信守 ...
- 敏捷软件开发实践-Code Review Process(转)
介绍: 在敏捷软件开发中,从代码的产生速度上来看,要比 传统Waterfall产生速度高很多.因为我们把时间安排的更加紧凑了.那么这么多的代码,如何能保证这些代码质量呢?很多人可能直接想到静态代码检测 ...
- 敏捷软件开发实践-Sprint Retrospective Meeting(转)
介绍: 在敏捷开发模式中,Sprint Retrospective Meeting 也是一个必不可少的环节,它通常发生在每个Sprint的结尾,其主要作用是对于当前的迭代周期做一个阶段性的总结,包括好 ...
随机推荐
- Tail Call
一.什么是尾调用 尾调用(Tail Call)是函数式编程的一个重要概念. 一个函数里的最后一个动作是返回一个函数的调用结果,用简单的一句话描述就是"在函数的最后一步调用函数". ...
- (25+4/25+4)复健-KMP/EKMP/manache/Trie
(29/29) 3.23已完成 1.KMP int Next[maxn]; void prekmp(char* x,int len){ ,suf=; Next[]=-; while(suf<l ...
- 模拟Java内存溢出
本文通过修改虚拟机启动参数,来剖析常见的java内存溢出异常(基于jdk1.8). 修改虚拟机启动参数Java堆溢出虚拟机栈溢出方法区溢出本机直接内存溢出 修改虚拟机启动参数 这里我们使用的是ID ...
- Luogu 1008 三连击
题目背景 本题为提交答案题,您可以写程序或手算在本机上算出答案后,直接提交答案文本,也可提交答案生成程序. 题目描述 将1,2, \cdots ,91,2,⋯,9共99个数分成33组,分别组成33个三 ...
- Java技巧之——判断相等
变量值的判断是java中重要的一部分 通常我们判断两个值是否相等,使用的是两个等号 == 为了防止少写一个等号,造成无法挽回的失误,判断写为下面的格式 int a; 12==a; 原理是不能将任何东西 ...
- Java的多线程1:线程的使用
概述 进程是线程的容器,线程共享进程的内存空间,所以线程之间彼此通信是比较容易的,而线程又有自己私有的内存地址,其他线程无法访问.了解进程和线程关系,可以看我另一篇博客<进程与线程> Ja ...
- 剑指Offer系列之题1~题5
目录 1.二维数组的查找 2.替换空格 3.从尾到头打印链表 4.链表中环的入口节点 5.重建二叉树 写在前面:本随笔中包含五道题:题目描述,题目思路以及对应解法. 1.二维数组的查找 在一个二维数组 ...
- 【PHP】数组
一.生活中的数组: a) 教室的座位:第一天来教室的时候,每个座位上都有自己的一个名字,我们可以通过这个名字快速定位到自己的座位在什么位置! b) 电影院的座位:我们买了电影票之后,能够通 ...
- MyBatis(九):动态SQL
本文是按照狂神说的教学视频学习的笔记,强力推荐,教学深入浅出一遍就懂!b站搜索狂神说或点击下面链接 https://space.bilibili.com/95256449?spm_id_from=33 ...
- python 爬虫之 urllib库
文章更新于:2020-03-02 注:代码来自老师授课用样例. 一.初识 urllib 库 在 python2.x 版本,urllib 与urllib2 是两个库,在 python3.x 版本,二者合 ...