SAFe不是敏捷 - Jeff Gothelf

自从Scaled Agile Framework（简称SAFe）在4.5版中采用Lean UX以来，我就收到了源源不断的入门问题，这些问题是关于这两种方法应该如何协同工作的。   
简短的答案是，我不知道。 
稍长一点的答案是，我们在Lean UX中内置的所有原理似乎都不存在于SAFe中。 
SAFe对话显然缺乏持续学习和改进，以客户为中心，谦虚，跨部门协作，基于证据的决策，实验，设计和课程更正的功能。
取而代之的是，采用这种工作方式的组织将重点放在僵化的团队结构，严格的仪式和事件以及行为改变要求的不均匀分布上，具体取决于组织中的高层人员。 
简而言之，SAFe并不敏捷。 
 
考虑到训练有素的训练团队必须经过“ SAFe认证”，因此他们抵制变革也就不足为奇了。他们已经过训练，可以以一种非常特定的方式工作-一种只专注于可预测的交付方式，而不是学习方式，对学习过的课程不进行修正，当然也不是敏捷性。
使团队真正敏捷的活动需要灵活的计划。他们要求与客户成功保持一致，而不是预先确定的功能。他们需要一个连续的发现过程，这不可避免地导致计划外的路线修正。这些更正将立即“终止”发布训练。
寻求敏捷性的大型组织意识到了随之而来的不确定性，并坚持熟悉的瀑布流程。SAFe给人一种“采用敏捷”的幻想，同时使熟悉的管理流程保持完整。在瞬息万变的世界中，不断变化的消费者消费模式，地缘政治的不稳定性和指数级的技术进步，这种工作方式是不可持续的。 
如果您在已经采用SAFe或正在实施SAFe的大型组织中工作，请问自己在此过渡期间发生了什么变化。您离客户更近吗？了解您是否已交付有价值的东西需要花费多长时间？更好的是，您如何衡量“价值”？问自己，基于新发现实施一项举措有多容易？然后，在开始使用“大房间规划”，“ PI”和“发布培训工程师”之类的术语之前，将这些答案与情况进行比较。 
在大型组织中扩展任何工作方式都是棘手且不平衡的。试图将整个过程应用到整个公司中，该过程完全专注于交付，而不是持续发现和纠正过程，只会强化传统的工作方式。
心理上安全感是吸引人的，因为它似乎提供了一个尺寸适合所有配方大规模的敏捷性。实际上，它奖励可预测性，合规性和合规性，同时为高管提供掩盖“我们如何变得更加敏捷？”这一问题的掩护。
您对SAFe的经验是什么？你成功了吗？我很想听听你的故事。

 
网友评论：
几乎没有争议，SAFE确实是PMO /执行官管理组织的答案。它与典型的阶段驱动的PMO流程没有什么不同，只是术语和角色不同。它会像牛奶一样老化，并在几年内被其他东西取代。
 
我在一家足够大的公司工作，可以让我目睹应用SAFe的多种方式（跨不同业务部门的多种发布方式），我可以告诉你它们不是相同的。我的直觉告诉我，其中90％的差异来自关键职位人员的文化背景。作为RTE，我虔诚重复的一句话是“我们为什么要这样做？什么目的？我们怎样才能减少膨胀就达到相同的目标？”例如：两年前，20个同事参加的每两周一次的ART Sync会议耗时3-4个小时，而所有需要参加的人都感到恐惧。如今，同一个ART Sync通常只需不到60分钟的时间，并且向利益相关者提供了该系统的简短演示。在两种情况下都使用SAFe…。
 
他显然对SAFe一无所知，或者没有对SAFe进行对话，因为SAFe代表了所有这些事情（不确定他是如何错过的）。我确实同意大型组织喜欢假装他们正在实施SAFe，实际上，他们只是在给猪涂口红。除了添加一些PI计划并将其称为SAFe，其他就没有太大变化。领导力永远是成功实施SAFe的问题/障碍。
 
我同意你的观点，但是我认为这是组织最好的方法之一：即组织必须采用一些敏捷的实践和框架（例如Scrum）来保持一定的形式化。
 
SAFE是组织尝试使管理控制变得敏捷的一种尝试。本质上，敏捷的管理参与度非常有限，敏捷团队的分布非管理结构非常扁平。大型组织采用SAFE作为使结构敏捷的一种方式，因此SAFE并非敏捷，而是瀑布般的轮回。
 
我不是SAFe的粉丝或从业者。最终，我觉得SAFe可以替代瀑布。它是不敏捷！但是，我确实在某种形式的全面规划中发现了巨大的好处，正是因为您指出了精益用户体验/敏捷的好处：以客户为中心，发现，学习和课程修正，而且我觉得它增加了两个组成部分帮助高管放手，使团队可以自治-透明和协作。它可以帮助我们专注于为客户和企业带来最大价值的计划，而不是被某个特定产品或特定团队所孤立。在没有全力以赴的计划的情况下，大型组织会沦为特色工厂的猎物。
我们主要使用Scrum和一些看板来实践双轨敏捷，并且在它们带来最大价值时立即利用设计思想和精益方法。我们的公开路线图是主题化的，其举措可推动客户取得成果，并与长期和近期的OKR保持一致。我们内部的四个月交付计划是全面计划的输出，利用了一些新的“远程：敏捷性框架”（r:af）。该计划始终是交付和发现的结合。如果您有几个以上的团队（在我们的示例中是12个Scrum团队），那么全能计划就是救命稻草。它使跨职能的团队和利益相关者相互交流，分享见解并促进健康的辩论，从而使他们能够共同解决问题，并获得其他所有人的支持。
我最经常看到的是团队需要更多的培训和发现方面的帮助。因此，我说跳过敏捷框架培训，并为团队配备发现工具和培训。许多团队收集了一些定性的客户声音并进行了一些简单的草绘后，便停止了发现循环。他们倾向于跳过假设，风险评估和实验。而且，大多数团队都将发现视为他们已经计划交付的工作的验证。
 
您可能不会记得我，但是我们在几次会议上见了面，在那里我很幸运地采访了您与我合作的杂志。顺便说一句，我发现你的文章很真实。SAFe与敏捷无关。SAFe涉及组织的适应性，一致的结构以及多个团队之间的协调与配合。事实证明，这是许多大公司采用它的巨大增值原因。
但是，我可以根据经验告诉您，正如我们在我工作的公司中实施SAFe已有多年的历史一样，SAFe尽管流程严格，但它提供了创新，测试，学习和调整的手段。它只是在它们周围放置了更严格的控件或护栏，因此我们不会失去对要实现的战略目标的跟踪。
我认为重要的是要记住这是针对大型组织的。中小型企业应该避免使用SAFe，因为它们不会受到大型企业的官僚主义和复杂性的影响，因此应该针对速度进行设计。
 
亚马逊出色地做到了敏捷。拒绝敏捷的企业（这是一种选择）必须希望并祈祷亚马逊不会与他们竞争。
 
我看到SAFe试图提供支持和指导的地方很多，而我也看到了很多失败的地方。但这只是他执行的错。无法有效地管理可以执行的积压工作无济于事，缺乏对执行力的评估，回顾无法帮助您不断学习和适应。对我来说，SAFe是一个框架，甚至在名称中都包含了这个框架。因此，我以此为指导，使您可以适应自己的业务需求。不管您使用哪种方法或框架，都需要包括Jeff所包含的一些关键实践。就像当今大多数事情一样，关键是人（员工和客户）。确保他们参与支持和指导这些过程。
 
我来自一个敏捷的规模组织，该组织采用了SAFe的一些原则，并创建了自己的格式，文化和仪式及其某些组成部分。如今，我正在使用完整的SAFe设置，“ SAFe系统”的主要缺陷是应用于规模化敏捷的“流程优化”，因此将所有内容分解为计划和组织结构。如果以可持续的，以客户为中心的方式来改变事物，那么我认为SAFe不会造成伤害。我仍在搜索的是一个行业示例，其中一家公司采用SAFe并随后根据通过漏斗的产品获得了成功。
 
从我的阅读中，您实际上是在说组织变革既困难又复杂，而不是争辩“SAFE不是敏捷”的观点。没有任何一种“一刀切”的解决方案可以使更改变得容易。
如果将Scrum与看板进行比较，您可以轻易地认为Scrum与看板相比根本不敏捷，因为Scrum相当形式，流程，仪式和基于角色。虽然欢迎变化，但严格的时间限制（冲刺）和固定的范围限制了变化。相比之下，看板对流程的要求极低，几乎没有角色，没有时间表，而且您可以按小时进行更改变化，而不仅仅是外部冲刺。
就是说，我是否建议传统的，与流程相关的组织立即从瀑布式转换为看板式，因为看板是方法中最灵活的方法？绝对不。仅仅因为在系统和人员层面上需要的变更如此之大，以至于只有一个已经很敏捷的组织（如初创企业）才能一次成功地实现该变更级别。
您的观点是正确的，但这是我要质疑其上下文背景。如果组织及其人员已经敏捷，那么有很多更合适的方法来扩展敏捷，例如LESS，Scrum of Scrums或使用精益变更管理来建立自己的方法。但是，如果您有一个更传统的，矩阵化的，与流程相关的组织，并且没有实施重大的组织范围内的流程转换和人员转换的历史，那么在组织变革的背景下，循序渐进的方法可能会更成功。
当我考虑组织变革时，我总是会想到Shu Ha Ri的概念。

• Shu –首先，我们必须掌握我们的工艺基础。Scrum适​​用于团队，Safe适用于扩展。简单，易于遵循且可能掌握。请记住，在这一点上，我们可能仍会受到整体架构，有限的发布功能，手动测试，缺乏对组织范围的了解，敏捷带来了什么以及解决了什么问题的限制。
• Ha –我们正在掌握Scrum和Safe，从而在整个组织范围内发展敏捷的思维定势。我们了解敏捷可以为我们个人和组织做什么。这些知识使我们能够采用我们的方法。一些团队或业务组将开始修改其流程，以适应其更敏捷的需求。敏捷仍然是正确的，但是他们的精通使他们能够调整流程以适应他们的特定需求。添加精益概念，设计思想，更敏捷的交付方式，CI / CD。模块化架构。
• Ri –您不再遵循行业标准的敏捷方法。您现在拥有自己的定制方法，可以通过可持续方法来实现最大价值。您交付的东西更少。您了解您的客户，价值是什么，您可以将价值直接连接回资产负债表。您唯一的护栏是敏捷，精益，设计思想原则和组织的愿景。