敏捷与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的结尾,其主要作用是对于当前的迭代周期做一个阶段性的总结,包括好 ...
随机推荐
- python—nnlog日志
#when='S'每秒产生一个[D天默认 H M S]# backCount='5'## level是设置打印级别默认是debug级别(下面是四个级别可以指定打印) import nnlog lo ...
- ScheduledThreadPoolExecutor之remove方法
之前用定时任务的线程池,设置了个任务,但是突然今天产品说,某些个操作需要中断某些任务(如果任务还没有执行),使其不能再到点执行了.于是查了API果然有这样一个方法. 一看API,需要移除的是一个Run ...
- mysql慢查询分析工具比较与实战
00 前言 在进行mysql性能优化的时候,第一个想到的便是查看慢sql. 但是对于慢sql有没有什么好的工具进行分析呢? 推荐两个工具mysqldumpslow及pt-query-digest. m ...
- VUE一款适用于pc平台的简单toast
新项目要求用typescript+vue+elementui的模式来搭建pc项目,最初踩了好多坑.产品说提示不想用element-ui的提示. 打算用toast的形式.所以就自己写了一个pc的toas ...
- 前端上传视频、图片、文件等大文件 组件Plupload使用指南
demo:https://blog.csdn.net/qq_30100043/article/details/78491993 Plupload上传插件中文帮助文档网址:http://www.phpi ...
- 经常登录Linux,用户密码背后的知识了解一下
一,用户密码存放在哪里? 说到这个问题,绝大部分的同学肯定都知道/etc/passwd这个文件,不错,这个文件里存储的就是用户名,密码等信息. 每一行都是一个account,每一行有7个信息,分别用 ...
- 3.K均值算法
一.概念 K-means中心思想:事先确定常数K,常数K意味着最终的聚类类别数,首先随机选定初始点为质心,并通过计算每一个样本与质心之间的相似度(这里为欧式距离),将样本点归到最相似的类中,接着,重新 ...
- git log查看某文件的修改历史
1. git log filename 可以看到fileName相关的commit记录 2. git log -p filename可以显示每次提交的diff 3. 只看某次提交中的某个文件变化,可以 ...
- 8.3 String 类的方法 使用分类
String类的判断功能.获取功能. * String类的判断功能: * boolean equals(Object obj):比较字符串的内容是否相同 * boolean equalsIgnoreC ...
- String 对象-->replace() 方法
1.定义和用法 replace() 方法用于字符串替换 语法: string.replace(searchvalue,newvalue) 参数: searchvalue:被替换的字符串 newvalu ...