我是一个懒人,虽然也记,也写一些东西,但是大多数都在公司内部做分享。通过ACT的培训,结实了一帮朋友,开始更公开的交流,期待大家的指导。

实践SCRUM已经有2个多季度。而在第2个季度的时候,团队已经形成了自组织,教练可以不参与一切团队活动,主要通过关注团队每天发到群里的数据和线下沟通来进行一些校准,避免团队遇到较大压力的时候倒退,并且帮助团队移除一些障碍。

当然最有效的干预手段,就是参与团队的“回顾会”。

那么我们是怎么开回顾会的呢?

开始阅读之前,我先跟大家安利一下我们团队的3个公约:

1:任何需要发言的场合,第一个发言者可以从没有发言的人中指定下一个发言者,直至所有人都发言完毕,不发言的可以喊——“过”。

2:回顾会需要准备甜品,例如奶茶,饮料,小食,方式AA(2个季度喝遍公司周围所有饮品店……),据说甜品可以增加多巴胺的分泌,让人感觉到舒适,安全。

3:回顾会不一定要在公司开(例如星巴克,例如各种甜品店,看团队的爱好,去公园草坪也可以)

以下是我们迭代到目前的回顾会议程,以及我的一些观念思考。

A:准备环节:

团队在回顾会前一天的站会上选出1名回顾会引导人,通常是轮流,团队初期由教练来进行引导。

引导者准备道具和数据资料。

B:开始

一:宣读宗旨

引导者宣读敏捷回顾会最高宗旨,团队自由选择跟读。

如下:

无论我们发现了什么,考虑到当时的已知情况、个人的技术水平和能力、可用的资源,以及手上的状况,我们理解并坚信:每个人对自己的工作都已全力以赴。

我的观点:

非常有必要且充满能量的一个环节,注意用标准的普通话,饱含坚定的意志去宣读这句话。可怕的是,这种能量可以传染,快速的复制到每个人的身上,这种仪式感可以让大家迅速进入状态。

二:改进成果回顾

对上个迭代制定的改进措施执行情况及取得的成果进行评价(匿名1-5分)

引导者:“请大家对上一个迭代的回顾会所制定改进措施的执行情况进行评价,这是问卷网匿名评价,请大家扫码提交评价。”出示二维码。

打分选项如下:

1:好像没做什么改进

2:有改进,但有较多不足

3:改进措施对我的工作有帮助

4:我在改进中受益,我认为改进有效

5:我们明显受益,我会持续守护我们的改进成果

展示评价结果平均分。并邀请大家进行1分钟发言,阐述自己的看法。

我的观点:

让大家对于上次迭代的改进情况进行一次主观的评价,检视一下上次的改进成果是否深入人心,承前启后。


这个检视有两层含义:


1:回忆一下我们都改进了些什么,大家看下我们都是怎么看待上次的改进,大家一起照照镜子,这次我们要如何做的更好?

2:每个人的角度不同,也许自己从改进中受益,但却伤害了他人,集体的视角往往更加全面

三:看图说话

引导者同屏展示如下几个图,或者发到群里,团队自己看。

1:燃尽图

作为一个懒人,我就不解释什么是“燃尽图”了,不明白的小伙伴可以自行百度,GOOGLE,BING。我们有2个燃尽指标,1个是PBI,达到DOD。1个是SBI,达到DOD。但凡达到DOD大家就可以在看板上移动它。

2:情绪彩虹

“情绪彩虹”这个名字是我起的,源自于“情绪曲线”,“情绪测震仪”。玩法有点有区别。我来跟大家说道说道。

首先,团队的每个人都会领取一只颜色别致彰显自己个性的白板笔,颜色自选,先来后到。

然后,看板上找一块区域,纵轴标记出笑脸,一般,生气,3个表情,横轴标记迭代的天数。每天站会结束时,大家用自己的水笔,在看板上画出能体现出你此刻感觉的图形或者打点,此时不连线。

如果遇到有事件影响了你,绿色代表技术类事件,黄色代表组织类事件,红色代表个人事件,撕下小报事贴,写上并贴在当天情绪点的最上方区域。变化并不可怕,可怕的是无视这些变化,把所有团队认为有影响的事情记录下来,会发现很多惊喜以及被忽略的一些重要事物之间的联系。

最后,回顾会前,大家清理看板的时候,用标志自己颜色的水笔将自己画的图案连成一条线。

团队连完线,远远看去,是不是感觉像大家一起画出一道属于团队的靓丽彩虹呢?

3:团队时间表

团队时间表,用来分析大家时间都花去了哪里,哪些地方坑,哪些地方比预想的情况要好,在回顾会之前,引导者会组织大家花几分钟时间清理看板,将看板上的报事贴撕下来进行整理,并形成这种可视数据,这样做可以尽可能的客观的了解每天时间的使用情况。

这种时间数据建议按照事项或者工作项来统计,如果团队自组织不是很完善,千万不要统计到个人头上,避免内耗,大家需要时刻意识到我们是一个整体。

4:缺陷趋势+看板自留地

缺陷趋势用来警示团队,质量是我们的生命线。

自留地可以有任何团队想要表达的内容,包括遗留问题等。

上面左图所示是尚未上线前的某段时间缺陷的情况,统计的是导致集成构建失败以及自动化测试完成,进入手工测试阶段以后所发现的缺陷。右图是上线后近期一次回顾会展示的自留地。大家把生产问题支持所花费的时间,修改BUG,新增商户等需要消耗团队资源支撑的事情也做了记录。

我告诉大家,这些时间趋势如果每个迭代在逐步变少,那么我们的债务就越少。如果在变大,那么我们的债务和利息就越多,大家自己看着办。

5:用户评审感受

用户评审感受纵轴是打分标准,横轴是迭代次数。

在评审会的时候,用户给本次迭代评审展示的成果进行打分。迭代计划会的时候,我们会和最终用户爸爸/PO一起确认迭代计划。迭代结束时,团队会给用户爸爸展示我们迭代的成果,有时候是开发人员演示,有时候是测试人员演示,用户爸爸如果在现场,我们还会邀请用户爸爸现场体验新功能,演示结束之后,我们邀请用户爸爸给我们匿名(用户爸爸有可能是多人)打分。

以下是评分标准

1:真烂

2:无言以对

3:凑合

4:满意

5:特别棒

(小贴士:正式功能上线之后,也可以参考此方法让用户对正式功能进行打分,我们现在有在做这样的实践,发现效果不错,用户的反馈持续变好,团队更加有信心)

引导者将以上几个图展示完之后,会让团队团队,思考5分钟,并把自己的看法记在纸上,如果是新增加的图或者第一次看图,引导者会讲这个图怎么看,但是不评论图上的数据。

然后我们进行轮流发言,每个人1分钟,讲自己的观点。“我的观点是,……完毕,下一个XXX”

发言结束之后进入下一个环节

我的观点:

1:数据驱动和持续改进是一对好基友,但是切莫因为数据搜集,建模困难而不去做,刚开始尝试难免会有数据不准确,维度不丰富,反馈不客观等等的情况,只要继续尝试下去,逐渐丰富起来,相信大家一定会找到适合自己团队的数据。


2:在这个环节,有个点比较让人容易忽视,就是团队的主观感受。


绩效=能力*意愿。在这个环节,除了让大家从不同角度观察客观的业绩数据(跟能力相关)之外,还需要观察主观的情绪数据(跟意愿相关),对情绪变化明显的同学表示关心和好奇。很多团队在做数据驱动的时候,过于强调结果和客观的业绩数据,导致忽视了个人情绪和意愿反而会让组织变得僵化。

四:聚焦问题

这个环节我们主要通过共创的方式让大家结合之前对迭代看法的上下文,背对背思考之后提出需要聚焦问题。

引导者:“通过刚才的发言,大家刚才分别阐述了对本次迭代的一些看法,我们都知道,回顾是为了聚焦问题,提出改进,下面让我们进行提问,格式是“如何……?”例如“如何提高自动化测试的覆盖率?”,围绕如何改进,大家每个人最多能提3个问题,请将问题写在报事贴上,1张报事贴,写1个问题,2分钟。”

引导者也参与写,写完之后,大家进行交流讨论10分钟,重要的是,每个人提出的问题能让其他人听到,并且知道你为什么认为这个问题如此重要。

我们的做法通常是3人一组,交流一轮,然后每组选择1个人留在那组,其他人换组再交流一轮。大家充分碰撞思路。

思路碰撞完之后,给大家1分钟,做问题调整,再次列出你认为最重要的3个问题,如果依然跟之前写出的没有差异,那么可以不用做调整。

最后大家一起把问题合并同类项。针对有争议的可以放在一边,一般来说大家的问题相似度会比较高。下图是我们有一次在星巴克做回顾贴出的问题。选择出最长的那一列,就是大家最关注的问题了。如果有2列都一样,那么则进行投票,每人1票,投票结果相同进行一轮交流,之后再投票。找出这个最关注的问题之后,就要进入下一个环节,改进措施。

我的观点:

团队共同认为什么问题是最重要的,就解决什么问题。每个迭代只聚焦1个问题,最重要的问题解决了,其他的问题可能会随之发生变化,也许就变得不再重要了。团队应该把当前的精力集中在解决大家共同认为的最重要的问题上。

五:改进措施


改进措施的形成原则,遵守“奥卡姆剃刀”,少即是多。所以我们团队约定,我们只针对最重要的问题,制定一条大家都认可的改进措施,所有人对这条改进措施负责。其余的好的改进措施和想法,也都列示出来,有想帮助大家做的更好的同学可以积极的践行。

引导者:“既然我们大家共同找到了那个最重要的问题,接下来,大家一起来思考,我们如何能够有效解决这个问题。”

具体行程改进项的方式和上一环节“聚焦问题”是一样的,找到聚焦的问题之后,大家集中精力,思考5-10分钟。列出1-3条改进的措施,要求简单有效即可。

例如曾经有一次关于“如何提高工作计划的合理性”这个问题,团队有提出两种思路:

一种是通过JIRA,建立一些数据模型,录入数据分析,生成报表,balabala。。。

另外一种是直接采用SBI报事贴,直接把报事贴上的时间统计下来展示给大家,大家再来探寻。

这样的情况下,我们通常会直接采用第二种方式,尽可能简单并且能产生效果的方式。

我的观点:

1:为了避免受害者情绪,只有大家自己认可的东西,大家内心才会接受,改进措施制定的前提条件是尊重团队的选择,如果大家都选择了复杂的,那么就用复杂的,下个迭代我们再来看这个改进的有效性如何。复杂的改进也未必不好,只要有效,并且大家认可就好。


2:那么什么是有效呢?有效的改进是指客观上有衡量的标准,主观上感受也有改善,如果只是要求客观上的数据指标达到要求,主观上的感觉很糟糕,我们也不认为这个改进有效。

六:我要点赞

完成了行动项的输出,我们通常需要一些激励,以便面对接下来的困难。彼此感谢,彼此欣赏最为重要。

点赞的规则是每个人只有一次机会点赞,必须说出为什么感谢那个人,点赞不能给自己,可以给团队任何人。然后记录这次迭代回顾点赞的数据,每个月团队内公布一次获赞的榜单。

我的观点:

点赞是给非常有必要的环节,可以提振团队士气,但是要注意,团队的安全感足够高的情况下,我建议跟我们一样,采用当场实名,“说出来”的方式点赞,这种“说出来”的方式不仅是对被赞赏人的肯定,更是自我的一种积极表达。


我们希望在职场中要不吝赞美,好的情绪和能量可以扩大。


反之,如果安全感不够,或者极度缺乏安全感,可以匿名的方式,例如用匿名投票,匿名卡片等等。

七:回顾评价

最后,引导者宣布回顾会结束,感谢大家参与,并邀请大家评价。

引导者:“感谢大家参加这次回顾会,下面请在赞扬声中用你的反馈来帮助我进行持续改进,以便我以后更好的为大家服务。”出示反馈二维码。

以下是回顾评价打分选项:

1:并没有什么用

2:希望有用吧

3:找到了解决问题的方向

4:感觉不错

5:我觉得充满力量

我的观点:

追求透明,检视,调整是Scrum的核心支柱,可以通过大家的反馈帮助自己迅速提高引导技巧,收获认可,发现不足。团队就是教练的镜子,教练也是团队的镜子,同时教练也可以根据反馈来辅导引导者,共同成长。

以上就是我的回顾会教练经验,另外,友情提示以下2个需要注意的地方。

1:上述方法较多,不一定适合您现在的团队,如果觉得对您有帮助的话,请考虑酌情导入,我们形成上面的套路也是经过了一段时间的迭代。

2:注意感受打分的极值(极值就是指打5分或1分的情况出现),虽然是匿名打分,但是极值依然重要,极值的出现可以辅助判断团队在某些方面感受强弱的明显信号。

最后感谢大家读完这篇长长的处女作。如果你喜欢也可以给点反馈,来点赞哦~!

投稿联系:glenwangcn(备注:真北敏捷)

刘桉齐:敏捷回顾会七步成诗法 | 真北群友作品相关推荐

  1. 大卫张翻译:敏捷宣言的历史(敏捷宣言诞生记)| 真北敏捷低调分享

    Jim Highsmith 真北敏捷 今天 译者按 本文译自: http://www.agilemanifesto.org/history.html. 要想了解敏捷软件开发,这篇文章是必读,对学习敏捷 ...

  2. 真北敏捷公众号里的群友

    整理了下真北敏捷公众号中与群友相关的作品. 云原生12 要素和云原生15要素The 12-Factor App and Beyond the 12 factor App 敏捷OKR实战 DevOpsD ...

  3. 真北读书 | 小说体敏捷《猎豹行动:硝烟中的敏捷转型之旅》

    时值Scrum诞生25年及敏捷宣言诞生17年,中文原创敏捷类书籍如雨后春笋般冒出,这标志着敏捷这一工作方式在中国已跨越雪山草地.<猎豹行动>以小说体拔类其中.能够以一本小说把敏捷写出来,值 ...

  4. 敏捷回顾会议的套路与实践分享

    01 - 关于敏捷回顾会议 实践过敏捷的人都知道,在敏捷中会有很多的会议要开,比如计划会议(Planning).站立会议(Daily Scrum).评审会议(Review)以及回顾会议(Retrosp ...

  5. 互联网企业保持高绩效的秘密——敏捷回顾

    图片来源:https://vitalitychicago.com/wp-content/uploads/2018/06/norm-kert-quote3.jpg 大家可能都知道我们所处的时代是一个VU ...

  6. 印第安人的灵魂——敏捷回顾

    印第安人在赶了3天路后,会停下来小憩一天,因为他要等着自己的灵魂跟上来.敏捷开发在经历了一次迭代或者冲刺(Sprint)后,也需要休整,以等待团队的灵魂跟上来,这一过程被称之为"敏捷回顾(A ...

  7. 使用敏捷回顾实施组织变革

    由Jutta Eckstein所编写的<使用敏捷回顾实施组织变革:敏捷方法>一书,探讨了如何应用敏捷回顾来启动和实施组织变革.它描述了使用回顾来发展共同未来的思想,并分享了用回顾来支持组织 ...

  8. 【华为云技术分享】如何让敏捷回顾会议更有效果,这样做就对了

    摘要:有些团队践行敏捷一段时间后,感觉回顾会议(Retrospective Meeting)时间太长,动辄2-3个小时,而且会议上走形式,会后无效果,那么如何才能让回顾会议有效果呢? 背景 有些团队践 ...

  9. 敏捷回顾会:经验教训的总结

    敏捷回顾会:经验教训的总结 原文:Agile Retrospectives: Lessons Learned 在一个sprint中哪些方面做得好,哪些方面做得不好,哪些方面需要提高?在每一个敏捷回顾会 ...

最新文章

  1. poj1679(次小生成树)
  2. 网上复制代码需谨慎,莫名其妙报错看这里!
  3. Linux2.6内核中链表的实现
  4. 把txt中的数据读出并保存到数组中
  5. [zjoi2017]仙人掌
  6. 解决eclipse中git插件中的cannot open git-upload-pack问题
  7. sap.ui.layout.HorizontalLayout is not a constructor
  8. STS+Git 项目操作相关
  9. java类名与文件名_为什么Java文件名必须与公共类名相同?
  10. css sgc加密,ASP+SGC实现柱状图
  11. pdf报表的制作入门,JasperReport
  12. [Python] 进制转换
  13. 编译CWM-recovery
  14. 集线器(hub),交换机以及路由器异同;冲突域和广播域详解
  15. YouTube批量下载开源代码汇总
  16. Windows中MSOCache文件夹
  17. word中生成带方块的对勾
  18. 简单 Python 快乐之旅之:Python 基础语法之 JSON 专题
  19. 标准C++为什么没有垃圾回收(Garbage Collection)
  20. python实战: 短链接生成器

热门文章

  1. 美格智能助力映翰通与Teltonika Networks工业互联网产品加速落地,用连接构建智能工厂
  2. 防弹脚注,Woohoo!
  3. 比菜鸟更进一步(1):Style文件和toolbar的使用
  4. 分支类1 7-3 根据输入的空气污染指数,输出相应的信息。 (5 分)
  5. 十分钟学python-【译】10分钟学会Pandas
  6. 计算机应用基础形成性考核册答案win7,《计算机应用基础》形成性考核册答案...
  7. PAT刷题集(乙级)1003 我要通过!(20 分)
  8. vue里面的model
  9. 百度流氓驱动bd0001.sys【多测师】
  10. 程序员的算法趣题Q57: 最快的联络网