You are not your job

agile-standup

受到光磊的系列文章——《Scrum:死马?》的启发,我也来谈谈Scrum中的元素之一——站会。


还记得经典Scrum站会上我们要问的三个问题吗?

  • 我昨天做了什么?
  • 我今天打算做什么?
  • 我遇到了什么障碍?

在初次接触Scrum的团队中,一般都会让团队成员去遵守“Scrum教义”中的做法,其中就包括了在站会上依次回答这三个问题。
一般我们会看到这样的情景:
张三说:我昨天把这个故事的代码写完了,今天打算自测一下,没遇到什么障碍。
李四说:我昨天被叫走解决某个紧急故障了,今天打算继续这个故事,遇到的障碍就是最近打断比较多。
……

如此往复,基本上几周之后,站会就变成一个人兴趣索然地说,其他人目光游离地听;不低头玩手机都已经算是给面子的了。

德鲁克在《卓有成效的管理者》中曾经写到过:

“在组织的内部,不会有成果出现,一切成果都存在于组织之外。举例来说,企业机构的成果,是通过顾客产生的,企业付出的成本和努力,必须通过顾客购买其产品或服务,才能转变为收入和利润。”

“在组织内部所发生的,只有人工和成本。”

这个说法不论在组织的任何层级都是奏效的:从企业的角度,只有不断创造价值去缩小人类理想和现实之间的鸿沟的公司才能做到基业长青;从团队的角度,只有持续对组织有所贡献的团队才算是高绩效团队。

同样,作为个体,只有你的劳动真正被别人承认并消费,你所做的事情才算得上是卓有成效。

只不过在历史上作为体力劳动者,员工的劳动基本上等同于创造的价值,因为他们创造的是有形的产品,不论是搬的砖、制造的零件还是放牧的羊群。而在今天作为知识工作者的代表,IT项目和从业者产出的都是无形的知识、创意或者信息,而这些无形的东西在被别人消费或者影响到别人之前,都不能产生任何价值。

所以我们回头检视一下刚才提到的三个问题,是不是能够从这个角度来提升一下我们站会的效率呢?我们能不能从外部的影响来重新考虑如何回答这三个问题呢?

  • 我昨天做的事情,对我们的项目产生了什么样的影响?今天谁可以来消费我昨天的工作成果?
  • 我今天打算做的事情,可能会使用谁的知识或者信息?
  • 我遇到的障碍会不会是我们项目中潜在的一个风险?

作为知识工作者,不光考虑自己所做的事情本身,多去考虑自己做的事情对于自己的伙伴、团队所造成的影响,就走上了“卓有成效”之路。

Share

为什么你的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

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

Scrum失败的原因有很多. 很普遍的一个原因是, 忽视其众多前提而仅仅是把现在的基层开发组织按照Scrum要求的那三种角色改一下, 就算是上马了, 很快Scrum也就像它的音译那样, 变成死马了, 仅留一身马皮. 我们来看一下为什么仅仅把基层开发组织改组为Scrum团队是不工作的.

角色一, PO: PO的任职资格

在我所见过的Scrum团队中, 绝大部分PO是不具备PO的资格的. 不是说能力, 而是资格. PO从职责上讲, 拥有Product Backlog, 负责决定哪些功能进, 哪些功能不进, 优先级是什么, 换句话说, PO负责产品的方向. Product Owner这个词从字面上也赋予了PO这种职责. 但与这种职责相伴的是对应的资格, 你必须有资格能够负责产品的方向, 你才能负责产品的方向. 那么通常都是什么样的人有资格负责产品的方向呢?

  • 如果你是一个定制化开发项目, 企业应用, 毫无疑问, 是客户才有资格负责产品的方向
  • 如果你是一个产品项目, 面向多个潜在客户, 那么你们组织里面谁对产品的成败负首要责任, 谁就是PO.

换句话讲, PO通常是资方而不是劳方的人. PO要么是给项目提供资金的人, 要么是他的代言人. 通常出钱的人是老板, 很忙, 在大的组织里不太可能直接出任PO, 但他必须把他的职责代理给某个人, 而这个人是要对产品的成败负责的, 出了事之后他要负主要责任.

如果PO不需要对产品的成败负首要/主要责任, 那么他/她关于Backlog的范围和优先级的决定是不可信任的. 不是说他/她这个人不可信任, 人可能是好人, 找你借钱你也愿意借给他/她, 但由于他/她不需要负责, 他/她的决定是没有权威性的.

在我见过的运行的比较好的Scrum团队中, 担任PO的人都满足上面的任职资格, 包括客户本人, 包括从头到尾负责一个产品很多年的人等. 而运行的不好的Scrum团队中, PO通常由原先开发团队中的业务分析师担任, 仅具备一定的业务能力, 而没有商业上的资格和权威.

角色二, Scrum Master: Scrum Master的悖论

在我所见过的Scrum团队中, 绝大部分Scrum Master是没有认识到自己的使命的. Scrum Master的使命就是把自己做没, 不是做媒, 是做没.

Scrum Master这个角色深深反映了Scrum内在的不一致性. 我们只需考虑这么一个问题: 如何评价Scrum Master的工作成果? 如何证明一个人是合格的Scrum Master? 你会发现如果Scrum Master做的好的话, 他会把自己的大部分工作做没, 变得越来越轻松. 因为Scrum Master按照定义, 从根本上来说就是一个教练的角色, 教会团队自组织, 教育PO, 教育开发团队, 教育组织里其它Stakeholder. 评价教练的唯一标准就是被教授的人不再需要他/她了.

也就是长久来看, Scrum运行的好的话, 对Scrum Master的需求会越来越少, 这个职位甚至不再需要专职的人了, 而这在Scrum的教义中是不推荐的. 有的团队Scrum Master是兼职的, 平时还有一部分开发的职责, 不知道是不是认识到这一点之后未雨绸缪…

然而如果Scrum Master认识不到这一点的话, 对Scrum团队的破坏将是巨大的. 他/她会不由自主的为自己找事做, 无形中破坏了团队的自组织. 所谓自组织其实很简单, 就是不去干预. 如果团队在众多内部关于流程/活动/角色/职责等事情上需要Scrum Master的干预, 则离自组织还很远.

那为什么球队永远都需要一位教练? 答案很简单, 因为球队教练的职责是赢球, 而不是教会球员自组织. 如果他通过让球员在场上自组织来赢球, 那球队确实对他的依赖会减少.

角色三, 开发团队: 开发团队自组织的假象

在我所见过的Scrum团队中, 不是自组织, 而是没组织. 原先的Project Manager/Business Analyst/Developer/Tester的职责随风而去, 现在统一称Team Member了. 每个人在新的组织方式中无所适从, 而Scrum Master经验不足, 机械的, 一厢情愿的抹平角色的差异, 导致工作分配/领取出现众多状况, 影响进度.

那么我们来回答一下这个问题: 在Scrum的开发团队中, 还有PM/BA/Dev/Tester等分工吗?

答案是, 可以有.

什么, 这难道不是在Scrum教义中被明文禁止的吗?

Scrum确实禁止了, 但谁让它又开了个”自组织”的口子呢? 如果团队自组织起来, 开了个讨论会, 觉得这个Sprint, 谁谁谁, 你去负责跟PO接口, 搞清楚需求细节, 谁谁谁, 帮忙把CI环境弄稳定点, 谁谁谁, 把上个Sprint的功能没来及测的再测一下, 剩下的人都去做开发…这个会开完之后, 团队在这段时间内有了明确的分工甚至角色, 只要团队觉得合适, 团队觉得这样是在当前约束下完成工作最合适的方法, 又有何不可呢?

 

本文原文来源于>>>>http://liguanglei.name/blogs/2015/05/04/why-your-scrum-failed/?from=timeline&isappinstalled=0

Share