SAFe 案例研究:来自现场的转型笔记

已发表: 2022-08-23

本文是 Toptal 的敏捷扩展系列的第三部分,旨在指导项目经理进行团队扩展工作。 请务必阅读第一部分,“5 个敏捷扩展框架比较:您应该使用哪一个?” 第二部分,“敏捷扩展:Scrum Master 的 SAFe 最佳实践”。

根据第15 届年度敏捷状态报告,94% 的公司以某种方式实施敏捷。 但研究还表明,90% 的组织在企业范围内的敏捷实施中遇到了困难。 通常,由敏捷教练、Scrum 大师和其他项目管理专业人员来领导和组织这些工作。 通常,他们在难以理解的公司文化中与抵制变革的团队或部门合作。

在本次圆桌会议中,三位 Toptal 项目经理讨论了领导敏捷转型的挑战。 因为他们的解决方案符合 Scaled Agile Framework (SAFe),我们还与 SAFe 的创建者 Dean Leffingwell 进行了交谈。 他们的集体见解表明,SAFe 从业者需要对敏捷是什么有一个清晰的认识,并制定一个可以让顽固的团队参与进来的领导计划。

与框架的创建者交谈 SAFe

SAFe 是由 Scaled Agile 正式化的一个框架,它的历史可以追溯到 2014 年。但对于 Leffingwell 来说,这项工作始于他在 2000 年代初第一次遇到敏捷团队时。 作为一名软件开发方法学家,他对敏捷实践在开发团队中的成果印象深刻,并立即开始探索如何将这种思维方式应用于整个公司。 如果一个敏捷团队可以产生结果,那么一个由敏捷团队组成的团队可以产生什么? 敏捷实践如何用于国内或国际公司的全面转型项目? 正如 Leffingwell 所说,“我热爱软件开发。 我爱敏捷。 我只是想要它一点。”

标题为“最受欢迎的扩展框架”的条形图。有 10 个条形图,分别标有“规模化敏捷框架 (SAFe)”、“Scrum@Scale/Scrum of Scrums”、“企业 Scrum”、“Spotify 模型”、“敏捷投资组合管理 (APM)”、“有纪律的敏捷 (DA) 、“大规模 Scrum (LeSS)”、“Nexus”、“精益管理”和“企业敏捷治理秘诀 (RAGE)”。每个条形还标有代表使用该框架的组织比例的百分比:分别为 37%、9%、6%、5%、3%、3%、3%、3%、2% 和 1%。图表底部的一条线表示,“来源:第 15 届年度敏捷状态报告”。
SAFe 是使用最广泛的规模化框架,在第15 届年度敏捷状态报告中受到 37% 的受访者青睐。

从那以后的几年里,公司已经认识到 SAFe 的好处,包括更短的交付时间、更高的产品质量、更高的效率和更敬业的员工。 截至 2021 年,全球超过三分之一的组织使用 SAFe,其中最重要的方面是它提供的共享流程和统一语言。 例如,如果一个团队认为 sprint 需要两周时间,而另一个团队认为 sprint 需要 30 天,那么它就会产生 Leffingwell 所描述的“巴别塔问题”。 如果团队甚至无法就“功能”的含义达成一致,他们就很难讨论要添加哪些功能。 “如果你想构建大型解决方案,你[需要]人们以共同的方式工作,”他说。 “在我们的行业中,没有一个术语不超载,比如‘迭代’、‘冲刺’或‘积压工作’。 如果您尝试跨团队和区域边界工作,那将无济于事。”

敏捷成功案例

即使在迫切需要变革的情况下,让公司中的每个人都采用统一的方式来谈论和工作也是一项艰巨的任务。 在成熟的公司中,这可能更难。 Leffingwell 解释说:“你看到的是世界上最大的公司,它们赚了很多钱,做得非常好,而且竞争激烈——他们必须改变。 好吧,他们的问题是他们为什么要这么做?” 这里介绍的 Toptal 项目经理每个人在他们自己的扩展活动中都遇到了这样的问题,并且每个人都找到了自己的方式来使用 SAFe 完成他们的敏捷转换。

展示价值

智利圣地亚哥的 Toptal 项目经理 Alvaro Villena 最近为开发跨业务平台的投资组合完成了 SAFe 过渡。 “我转型的第一个里程碑是举办价值流研讨会,”他说。 简单来说,价值流研讨会是一个启动会议,旨在确定从概念到交付的整个业务流程以及其间的所有步骤、用户、系统和痛点。

让整个企业的代表参加研讨会有助于 Villena 了解公司文化以及他的障碍是什么。 “在我们实施研讨会之前,有一种结构,一个企业有他们的团队,另一个企业有他们的团队,下一个企业有他们的团队——这三个人没有互相交谈。”

Villena 发现,尽管所有团队都有相似的痛点,但在解决方案上没有协作。 例如,尽管投资组合中的每个企业都发货了产品,但只有一个企业开发了跟踪系统。 他们没有理由不能全部使用它,只是没有人分享知识。 一旦研讨会让他们开始讨论,知识就开始在团队、企业和产品所有者之间流动。 “这种对话对节目来说真的非常强大。 这是一个很好的起点,”Villena 说。 当 DevOps、设计和产品都知道其他团队在做什么时,他们会看到公司中有他们可以使用的解决方案。 “他们开始问,'我怎么能拥有它?' 这就是你介入并说'遵循这个过程'的地方。

“在他们知道原因之前,没有人想要改变。 所以你从一个原因开始,给他们一个更美好的未来。” SAFe 的创始人 Dean Leffingwell

Leffingwell 知道团队有时会抗拒。 “在他们知道原因之前,没有人想要改变,”他告诉 Toptal。 “所以你从一个原因开始,给他们一个更好的未来。” 让团队了解他们可以提高多少效率是变革领导力的有力工具。

即使每个人都热情地加入,你仍然应该期待艰难的开始。 例如,习惯于传统瀑布式开发和大型发布的团队可能难以转向更具迭代性和​​敏捷性的开发流程,即使他们看到了其中的价值。 “我们做的第一个项目增量对团队来说是一场灾难,”Villena 说。 “我们知道它会是; 我们告诉客户,前三个月可能会很困难。” 为了弥补这一点,他在第一个程序增量 (PI) 结束时构建了一个为期一周的迭代,团队可以在其中评估他们的进度。 他组织了一个冲刺,专门用于流程改进和评估,超越通常的检查和适应。 他发现将敏捷思维不仅应用于产品,还应用于业务转型,花时间退后一步,看看哪些有效,哪些无效,并做出相应的调整。

创造小胜利

为您采用 SAFe 过程中的意外障碍做好准备是很重要的。 几年前,塞尔维亚贝尔格莱德的 Toptal 项目经理 Miroslav Anicin 正在将一家电信公司过渡到 SAFe。 该公司已将其所有软件开发外包。 组建一个异地团队并不是一项特别繁重的任务——所涉及的问题主要是后勤问题。 但这种努力给公司本身的转型带来了无法预料的挑战。 “我正在寻找我们在发布培训中需要的能力,”他说。 “而且我必须选择的所有人都来自营销、法律、产品、金融——完全缺乏敏捷思维,甚至没有任何敏捷经验。”

很明显,管理层没有处理敏捷团队的经验。 分布式决策需要管理者放弃一些控制权,如果他们没有敏捷框架的经验,领导层可能会犹豫不决。 为了解决这个问题,Anicin 必须自下而上和自上而下进行培训,指导领导者及其团队。

转向更加分散的决策制定需要“将工作方式从指挥和控制,通过仆人式领导,转变为这种授权的学习文化和敏捷文化——以及容忍错误的能力,”Leffingwell 说。

Anicin 开始了逐步扩展的过程——在单个团队中执行小型敏捷项目,而不是在 SAFe 框架内——因此各个团队可以开发一些实践经验。 这些项目必须是无关紧要的,并且足够小,以至于如果第一次尝试出现问题,公司不会受到伤害,但又足够有用,可以向团队展示该方法可以完成的工作。 例如,营销团队创建了一个内部营销活动,在此期间,Anicin 向他们传授了 Scrum 的基础知识。 与 Villena 的研讨会类似,这些较小的项目真实地展示了敏捷的价值,因此团队成员和领导层可以在全面过渡之前看到短期发布和持续改进的好处。

满足您的团队的需求

当驻巴黎的 Toptal 项目经理 Imane Marouane 领导一家大型跨国金融机构的转型时,她步入了一个混乱的环境,在这个环境中,各个团队都做出了扎实的工作,但在公司范围内没有共同的愿景。 “每个团队都有自己的优先事项。 每个产品经理都希望他们的产品首先交付。”

SAFe 对这个问题的解决方案可以在加权最短作业优先 (WSJF) 模型中找到。 WSJF 提供了工作优先级的标准,因此当需要决定下一个任务应该是什么时,第一步不会涉及如何对重要性进行排序的争议。 在基于流程的敏捷系统中,您不必担心一次性交付所有内容,因为正如 Leffingwell 所说,“最重要的是接下来要做什么工作。 这是一个比什么是最有价值的工作更容易回答的问题。” SAFe 提供了一种解决团队之间依赖关系的方法——任务排序对于这一结果至关重要。

标题为“加权最短工作优先公式”的插图。一个框包含一个公式,“WSJF 等于延迟成本除以作业持续时间(作业大小)”。底部有一行写着“来源:Scaled Agile”。
Scaled Agile 的加权最短工作优先公式通过权衡延迟成本与所需工作的难度和持续时间来确定任务的优先级。

Marouane 解决依赖关系的途径变得不确定:“经过两次冲刺,在第一次检查和调整之前,我们注意到一些团队没有遵循我们的 PI 计划。” 未遵循 PI 计划中定义的依赖关系,因此一个团队的工作无法开始,因为另一个团队的贡献尚未准备好。

“由于这是第一次迭代,而且团队不习惯这种工作,我们决定举行一个额外的仪式——每周召开一次会议,讨论依赖关系的进展,”Marouane 说。 “每个团队都有一个人来更新他们贡献的进展。” 这样,如果 A 团队说他们无法交付,B 团队可以提前知道并做出相应的计划,而不是等待在他们的 sprint 开始时不会实现的贡献。

Leffingwell 在对 SAFe 进行此类调整时鼓吹谨慎:“SAFe 是一个责任体系。 ......你可以适应它,但你必须非常小心。” 尽管该框架旨在具有适应性,但如果不重新评估,更改往往会被纳入。 Essential SAFe 配置的存在是为了确保任何更改都符合基本标准。

Marouane 的额外仪式再次包含在第二个 PI 中,到第三个它已被淘汰。 团队没有什么可报告的尚未沟通的。 一点额外的灵活性让 Marouane 让团队回到更传统的流程​​轨道上。 她发现转型本身需要敏捷的思维方式才能充分利用金融机构的团队。 重要的是,她所做的改变,通过对持续改进的承诺,最终服务于作为 Essential SAFe 基础的精益敏捷原则。 她的解决方案为公司提供了它所缺乏的统一愿景,并允许团队朝着相同的优先事项共同努力。

适应未来

任何大规模运行的框架都将面临挑战。 移动部件的数量和相互竞争的利益是巨大的。 但回报同样巨大,一个执行良好的过渡将为团队提供实现共同目标所需的工具。 您在如此大规模的实施中面临的障碍将是不可预测的,而敏捷思维帮助 Villena、Anicin 和 Marouane 适应了意想不到的挑战。 毕竟,这就是持续交付的目的:使用工具赋予您的流程以适应不可预见的情况。

Scaled Agile 还适应新技术和不断发展的行业标准,并根据需要引入新工具和功能。 每个人都需要保持敏捷并为意外做好准备。 “我们没有水晶球,”莱芬威尔说。 “我们只是跑得快,领导努力,跟随努力——尽可能快地写作。”