分类: 敏捷, 转型

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

发表评论

评论

  1. 有一个事情就是扯皮 如果先团队建设 再谈所谓的敏捷会好点麽 没责任就没有风险 没有最优的方法论

Webmentions

  • 为什么你的Scrum会失败?(二) | TW洞见 2015年5月7日

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