为什么你的Scrum会失败?(二)

前文说了Scrum三种角色的错误姿势,现在来说一下四个会议。注意是乱序,先看showcase。

Sprint评审会议/Demo/Showcase

如何评价评审会议(或者叫Demo, Showcase)的效果? 我听过的答案有客户满意、或收集到了反馈等。这都不够,且不说客户满不满意本就不应是评审会议追求的东西,就是收集到了反馈,都不够。

那如何评价评审会议的效果? 唯一的评价标准是, 会后有没有对product backlog做出调整

如果每次showcase完product backlog都没发生变化,那恭喜我们,我们的计划和预见能力很完美,完全可以按瀑布的方式工作,没必要迭代交付了。客户或stakeholder需要了解, 他们对showcase负有给出反馈的责任和义务,找对真正关心产品或项目的人来参加showcase。

但往往团队倾向于show好的一面,直接点就是掩饰问题,这是本末倒置,会后皆大欢喜就是失败的会议,会后没有调整product backlog也是失败的会议。

Sprint计划会议: 实际上应该是分开的两个会

很多团队都会抱怨Sprint计划会议的冗长和低效。抛开开会的技巧不谈,根本原因在于Scrum把两个不同目的,需要不同参会角色的会议融为一体了。在它的官方指南里明确说了计划会议有两个topic: what 和 how。

IPM

对于what,即下个sprint要做什么,某种程度上是不需要开发团队参与的。PO应该根据stakholder的输入,从业务优先级上选出下个sprint的backlog。这个过程可称之为IPM, iteration planning meeting,应该在本sprint开始前进行,也就是推荐在上个sprint的末尾进行,开发团队的参与是可选的,PO完全可以一个人搞定或者跟业务方的stakeholder来商定, 具体如何取决于PO。

  • 你说还没估算呢,PO怎么知道要选多少? PO可以根据之前Sprint完成的story个数,多选几张,比如多出个20%的量。
  • 你说开发团队不参与的话,可能漏掉一些技术依赖项。我们还有下个会呢,开发团队有机会给出反馈。

说到底,估算和技术方面的依赖,不是决定优先级的很重要的因素,仅供优先级参考而已。

IPM结束后,PO手里有了一小堆下个Sprint要做的功能,可能比开发团队正常能完成的量多了一点。这堆功能将作为下个会议的输入,可以微调。

IKM

下个会议称之为IKM, iteration kickoff meeting,在本Sprint开始时进行,主要目的是PO和开发团队对这个Sprint的目标进行交互解释、答疑、达成共识。开发团队对优先级,验收条件的任何疑问都可以提出来,PO来解释或调整任务。对what没有疑问之后可以开始估算,如果你非要估算的话。估的时候就按优先级估,估到累积的工作量达到团队的capacity为止。

IKM的解释,答疑和共识,依然是what,而不是how。对于how,开发团队自组织讨论就可以了,不需要PO参与。开发团队也完全可以在领到任务开始做的那一刹那,由领到任务的一对pair自己讨论how就可以。

总结一下就是 PO自己搞定planning,PO和团队一起kick off,团队自己搞定how。IPM不占开发团队时间,IKM 2个小时足够,其它的讨论分散在开发过程中

每日站会: 关注接力棒, 而不是运动员

站会到最后是最流于形式的会议,没有之一。原因很多,而一个比较普遍的原因是大部分站会关注在了错误的点上,引不起团队成员共鸣。这个错误的点就是关注每个人都干了啥,今天要干啥。站会对于团队成员就成了一项考核,考核你工作量饱不饱满。每个人挖空心思表明自己没闲着,说完自己的就完事,也不管别人的。

那么站会正确的关注点是什么? 进度,障碍,新知,及是否要进行调整。关注接力棒,而不是运动员

每日站会是进度报告会吗? 你可能会说不是。我只能说: 当然是了! 开完会对当前进度是什么样子都不知道,这会也太浪费时间了,甭管是半小时还是仅有10分钟。 (你说我们有其它方式了解进度,站会关注在其它方面,那是另外一回事)

站会首先是进度报告会,区别在于是向谁报告,报告的目的是什么。站会是向整个团队报告进度,目的是寻求帮助,提供新知,为可能的任务调整提供真实的输入。站会是以天为周期的PDCA环中重要的一步,负责Check和提出Action。Check时检查点不在谁闲着谁没闲着,而在于过去这一天有哪些新的信息会影响到任务交付。

评价站会效果的唯一方式是,会后有没有根据会上的信息做出相应调整。不排除不需要调整的情况,但很少。换句话说,如果你站会后没有调整,那你的站会是极有可能没什么效果的。

Sprint回顾会议

没什么可说的。只要回顾会议有效果,其它问题再大都是小问题。当回顾会议没有效果的时候,问题就大了去了。其它问题都可以在技巧层面针对问题本身改进。但回顾会议没效果的话,改进回顾会议本身是没有用的。

评价一项活动,不是看它过程,甚至不是看它结果,要看它对其它事务的影响。站会/回顾/评审会议,都涉及调整。开完会没什么调整, 会就白开了。

Share

发表评论

电子邮件地址不会被公开。 必填项已用*标注

This site uses Akismet to reduce spam. Learn how your comment data is processed.