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


Scrum-Tag-Cloud

前文说了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和团队一起kickoff, 团队自己搞定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.