Martin Liu

Martin Liu

Senior Developer Relations/Advocate, Founder of DevOps China, DevOps Institute Ambassador

对不起Scrum,你的游戏可能已经结束了!

市场正在向新的方向转变,Scrum还能找到自己的空间吗?

Martin Liu

2 分钟

流程设计

我们不可能忽视 Scrum 的知名度。多年来,Scrum 是全球大多数公司在敏捷框架中的首选;只有少数公司会挑战它。但最近,发生了一些变化,组织正在失去对Scrum的信任。在未能获得有意义的结果之后,在许多地方,人们正在用 SAFe、Kanban 或其他框架取代 Scrum。

除了这些不满 Scrum 的组织,有些经验丰富的专业人士也不愿意与Scrum共舞。很多人甚至觉得被称为产品经理(Product Owner)或 Scrum Master 都很尴尬。市场正在向新的方向转变,Scrum还会有空间吗?

公司想做敏捷,但他们难以放弃旧的指令和管控风格。

让我来阐述一下,为什么我认为 Scrum 的游戏可能已经结束了。 请注意 这篇文章的内容是基于我过去十年的经验和观察。这也是为什么我邀请你也分享你的观点。

作者

本文出处:https://medium.com/serious-scrum/sorry-scrum-the-game-might-be-over-for-you-915227f3a0d

作者:David Pereira Head of Product Management @virtualidentity Course: How to be a strong Product Owner: http://bit.ly/30ylNEH

Scrum不是一个流程!

第一个软件是在1948年才出现的,那时候软件开发还是个新鲜事物。我猜汤姆-基尔本无法想象软件开发会给世界带来多么快的进步。

计算机科学家汤姆-基尔本负责编写了世界上第一个软件,该软件于1948年6月21日上午11时在英国曼彻斯特大学运行。

Micah Yost, A Brief History of Software Development

在新千禧年之前,公司缺乏符合客户期望的技术。大多数公司专注于围绕软件开发改进流程。尽管所有的努力都是为了实施像 Rational Unified Process 统一流程这样的重磅流程,但质量还是有问题,客户也还是不满意。构建无用的软件让许多人感到沮丧;软件行业需要一场革命。

虽然像 ScrumeXtreme Programming 这样的敏捷框架已经存在许久,但在2001年《敏捷宣言》-(Agile Manifesto )出台后,才大大改变了全球软件的开发方式。在那之后,Scrum框架成为最受欢迎的替代品。

从千禧年的初期情况来看,Scrum 能解决软件开发的所有问题吗?我们必须去了解问题的根本原因,但很多公司忽略了这一步,反而求助于寻找新的流程。仅仅依靠替换人们工作方式的流程是不够的。这就是大多数组织未能从Scrum 中获益的原因。

根本原因不是流程,而是缺乏敏捷的思维方式。

我们以足球为例,在瓜迪奥拉(Pep Guardiola)的领导下,巴塞罗那在4年内赢得了14个冠军。从2008年到2012年,巴塞罗那绝对是世界上最强的足球队。很多人将成功归功于瓜迪奥拉执教球队的方式。其中一个显著的方面是主导比赛;巴塞罗那经常拥有70%以上的控球率。这是否意味着将 “Tiki Taka “ 运用到另外一支球队后,他们就能达到类似的效果呢?

瓜迪奥拉从2013年到2016年执教拜仁慕尼黑,他应用了和巴塞罗那一样的风格。然而,所取得的成功与巴萨不相上下;在拜仁慕尼黑,他获得了5个国家冠军,却没有获得欧冠冠军。要想实现伟大的成就,仅仅靠一个‘流程’是不够的,还需要其它更多的东西。

把Scrum当做流程的公司都失败了。如果还没有更重大的改变,任何敏捷框架都无法带领团队走向成功。除非公司解决了他们的组织型障碍(dysfunctions),否则环境不会让团队发挥的更出色。

我观察过很多虚弱无力的 Scrum 团队,因为环境的组织型障碍。最常见的组织障碍是。

  • 缺乏信任
  • 缺少方向
  • 根据职位确定优先次序
  • 微观管理(micromanagement)

对于这些有组织型障碍的公司来说,Scrum应用失效是不可避免的。最后,Scrum还要背这个锅。

Scrum 框架并不适合畏惧改变的组织。不改变其文化,就不可能用 Scrum 取得成功。许多人对 Scrum 的角色、事件和工件了如指掌,但很少有人知道背后的价值观。如果不活用 Scrum 背后的价值观,就不可能实现 Scrum 的承诺。

为什么Scrum即将崩塌?

Scrum 自称简单易行,其实很难掌握。几乎我认识的每个人都同意这句话,然而,我要质疑 Scrum 有多简单。框架的一个关键部分经常被忽略,试着问一些团队的价值观是什么?你会惊讶的发现,几乎没有人知道。不过,价值观仍然是 Scrum 的一个关键部分。

Scrum 的成功使用取决于人们是否能更熟练地运用这五种价值观。 承诺、专注、开放、尊重和勇气。

The Scrum Guide, November 2020

当组织把 Scrum 当作一个流程来实施时,挫折是不可避免的。从设计上看,Scrum 是不完整的,没有一个团队能够在不适应其场景的情况下取得成功。例如,产品管理并不是 Scrum 的一部分,然而,它却是交付有意义产品的关键学科。

要想利用 Scrum 获得成功,组织必须经历一场大规模的转型。不幸的是,大多数高管都不愿意去准备一个能让团队茁壮成长的环境。我在企业中遇到过以下几种范式。

  • 赋权 vs. 微观管理

  • 成果 vs. 产出

  • 协调/对齐 vs. 共识

  • 承担风险 vs. 遵循计划

“高层管理者们认为,拥有真正自我管理的团队风险太大。这就是为什么 Scrum 会遇到玻璃天花板的原因。” Willem-Jan Ageling, Scrum Has Hit the Glass Ceiling

高层管理人员们往往无法充分给个人授权,因为他们想继续自己的控制。所以他们才会走捷径。首先,改变执行力。然后,如果 Scrum 证明了它的价值,那再来改变文化。好吧,这样做是行不通的,结果是大家都很沮丧。当Scrum 变成了一个过场(译者注:此处突出一下形同虚设的空架子流程的含义,请酌情理解),角色就会变异成毫无意义的东西。让我来分享一下我的一些心得。

Photo by Maria Teneva on Unsplash

产品负责人/经理(Product owner)

如果不能对优先级负责,产品负责人就会像服务员一样。他们接受订单,建议配菜,然后把订单交给厨房。做一个接单员是令人沮丧的,你唯一的义务是管理利益相关者的期望,并用做和开发人员沟通的桥梁。

不幸的是,与产品负责人角色的变异更多的是规则而不是例外。这就是为什么我在想,是否有人可以成为 Scrum产品负责人。当我回顾我的职业生涯时,也许我曾经就差点变成这样的人,但从来没有像 Scrum 指南所推荐的那样,被完全的授权过。我的问题是:Scrum产品负责人在现实的企业中存在吗?

你能举出多少家公司的产品负责人真正的完全拥有产品决策的最终决定权?如果他们没有最终决定权,这些人还是产品负责人吗?然而,有成千上万的人声称自己是产品所有者,却不拥有任何产品。

Maarten Dalmijn , Will the real Product Owner please stand up?

在反模式之上,我注意到很多有产品思维的人对产品负责人这个角色失去了兴趣。他们觉得很难把它和产品经理联系起来。虽然公司经常雇佣产品负责人,但由于 Marty Cagan 所推崇的看法,很多专业人士都不好意思这样称呼,他声称产品负责人不是一份工作,而是一个角色,而且这份工作比 Scrum 所建议的要多得多。

开发人员

开发者是决定实际如何开展工作的人,他们负责实现,使用哪种技术栈,等等。这是一个美丽的幻觉(理论)。但在实践中,我从未见过这种情况。常见的是有一个首席技术官(CTO),一个技术负责人,或者其他头衔的什么人,他们不仅要来做决策,还要管理开发者。

Scrum 所宣称的开发者有自主权,但他们得到了吗?我认为自主的情况很少见。说起来也很悲哀,但大多数开发者所收到的命令都是要遵守的;只是很少有开发者被授权在没有截止日期的情况下解决问题。

Scrum 开发者在幻想世界中可能会和 Scrum产品所有者工作在一起,但在现实中却不是。我们最常见的是开发者被封印在了特性工厂里。

Scrum Master

Scrum Master 是 Scrum 中最遭受鄙视的角色。没有 Scrum Master 的 Scrum 团队是很常见的,因为公司不愿意雇佣专人来做这个工作。不过,即便有些公司雇佣了 Scrum Master ,但还是会经常让他们虚弱无力。

Scrum Master 的失效无法避免,因为他们也不能催生出任何必需的改变,能让 Scrum 蓬勃发展起来。

Scrum Master 和其他角色也没有什么不同。要找到一个人,他能够完全像Scrum指南中所建议的那样,成为真正的 Scrum Master 是不太可能的。Scrum Master 通常无力促进组织中所需要的变化。

##Scrum 还会活下去吗?

许多有经验的专业人士已经厌倦了 Scrum,他们对它失去了信心。他们想要一些其他的东西,这些专业人士正在寻找机会尝试其它的框架。

高管们对变革的恐惧阻碍了 Scrum 团队的发展。一连串错误的决定和错误的观念可能会导致 Scrum 走向灭亡。高层管理者不能将其先天不足的指令和管控风格留在过去。

一个可悲的结果可能就会发生,SAFe,这个瀑布模型的卧槽马,它已经准备好要上位了。

我很害怕 SAFe,因为它是一个沉重的流程,它看起来一点也不像是一个敏捷的方法。这台沉重的机器怎么能让人背得滚瓜烂熟呢?我真不知道他们凭什么敢说这也是敏捷。

SAFe 5.0

Scrum可能需要重启才能活下来

Scrum 角色的魅力已经大不如前。很多公司对 Scrum 的错误认知,导致专业人士抵触与之合作。在 Scrum 成为一个流程的场景下,人们也不想成为 Scrum Master 或产品所有者。

我相信 Scrum 需要重新开始才能保持存在的意义。

我们所处的时代与20年前不同。在2001年,Scrum 是一个新生的孩子。世界已经改变了。现在 Scrum 是一种商品。为了让 Scrum 还维持在前线,创造者们需要有勇气去接受框架的核心,并解决那些阻碍。其中一些(可能的)阻碍可能是人家的血牛。想想(Scrum Master 和 Product Owner)认证产业。

Willem-Jan Ageling, Will Scrum Fall Victim to Its Own Success?

不管发生了什么,那些勇于改变自己内核的公司还是能在 Scrum 中脱颖而出。这从来都不是为了定义一个流程,而是为了拥有一种专注于更快地交付价值的文化。希望尚在,一些大胆的公司能拥抱变化,他们所表现出的迹象是。

  • 首席产品官(Chief Product Officer)成了高管团队的成员。
  • 高层管理人员专注于给出方向而不是指令。
  • Scrum团队被授权去试验各种用来达成关键成果的方案。
  • 产品探索(Product Discovery)的建立。高管们知道,投入适当的时间去发现那些值得解决的问题是必不可少的工作。

最新文章

分类

关于

This Blog is sharing DevOps and SRE ariticles. I am a Senior Developer Relations/Advocate at Elastic, Founder of DevOps China since 2017, Microsift MVP since 2021, DevOps Institute Ambassador.