Scott Brinker：我们是否进入了后敏捷营销时代？

赶上我在本月早些时候 #MartechDay 之前积压的数据和主题——其中包括 2022 年营销技术前景和 2022 年 Stackies——清单最上面是来自 AgileSherpas 的最新敏捷营销状态报告。

与往常一样，这是一份关于如何以及为何在营销中使用敏捷方法的出色而全面的报告。从上图中可以看出，敏捷已进入各种营销活动：营销运营、创意服务、网站运营、社交媒体、广告等。

它甚至被应用在事件营销中（30%），长期以来，这一直是怀疑者的首选示例：「哦，敏捷永远无法为事件工作。」 （公平地说，在虚拟/混合事件世界中，事件营销的节奏和适应性显着提高。）

但与去年不同的是，当 51% 的参与者报告使用敏捷营销时，这次只有 43% 的人使用了。这接近 2020 年的 42%。敏捷营销是否正在倒退？

当然，最明显的免责声明是调查样本。即使有 513 名营销人员参与了这项最新调查，但它仍然只是多元化营销领域的一小部分，无疑会受到选择偏见的潮起潮落的影响。

但还是。经过近 15 年的敏捷营销倡导，这一运动的势头似乎……停滞不前？

敏捷营销原则、实践和标签

然而，敏捷营销的原则如今似乎被普遍接受为福音真理。我想不出我在过去几年遇到的一个营销人员没有接受适应性、从实验中学习、迭代改进、跨团队协作、更深入地了解工作中的工作和团队以及赋权等

营销已经成为一种敏捷的职业，彻底地。

经典的敏捷实践——比如 Sprint、每日例会、看板等——似乎也得到了广泛的推广。尽管在许多情况下，它们已经从原始形式演变而来。我们稍后会回到这个话题，因为我认为这是后敏捷的转折。

但是标签呢？没那么多。在营销讨论中，我很少听到 Sprint、例会或看板这些术语。甚至「敏捷营销」这个词出现的频率也没有几年前那么频繁。

敏捷营销 VS 敏捷开发趋势

Google 趋势中的几张图表有助于说明所发生的事情。首先，让我们看看搜索词「敏捷营销」的增长情况：

Google 趋势：敏捷营销

该图表显示了该词在过去 18 年中的相对搜索量。你可以看到它在 2017 年左右达到顶峰。（在 Hacking Marketing 发布一年后。巧合？）从那时起，它就上下波动了。但它在很大程度上达到了天花板。

为了更好地了解敏捷营销的绝对搜索量，您需要将其与另一种趋势进行比较。因此，让我们将它与它的前身「敏捷开发」进行比较：

Google 趋势：敏捷营销与敏捷开发

有两件事突然出现。首先，敏捷营销只取得了敏捷开发所获得的很小的份额。其次，自 2010 年以来，对敏捷开发的兴趣一直在稳步下降。大约是巅峰时期的 1/4。

2010年发生了什么？DevOps 的兴起。

Google 趋势：敏捷开发与 DevOps

事实上，DevOps 成为了站在敏捷开发肩膀上的巨人。它的受欢迎程度使敏捷开发相形见绌，即使在它的全盛时期也是如此。与这两者相比，敏捷营销几乎没有形成规模。

但值得注意的是，DevOps 源于敏捷。引用它的维基百科文章：

「敏捷开发团队……无法『通过早期和持续交付有价值的软件来满足客户』，除非他们包含与其应用程序相关的运营/基础设施责任，其中许多是自动化的。」

DevOps「旨在缩短系统开发生命周期并提供高质量软件的持续交付。」如果不是交付迭代软件开发的最终机制，那么什么是持续集成/持续部署 (CI/CD)？

正如《阿甘正传》可能会说的那样，「敏捷与敏捷一样。」

云中「运输」的成本直线下降

需要明确的是，DevOps 不是一种敏捷管理方法。它甚至不像其他运营职能（例如营销运营）那样属于「运营」团队（在大多数情况下）。相反，它是开发人员用来快速、迭代和安全地发布软件的一组实践、流程和技术。它利用了大量的自动化和仪器。

DevOps 优化构建和部署软件，但决定构建什么以及何时仍需要在高于此的级别上发生。理论上，Scrum 等敏捷开发方法可以为这些决策提供框架。但我认识的大多数开发团队不再明确使用这些方法。大多数人都发明了自己的流程，从敏捷方法中提取概念并对其进行调整，并利用 Jira 等开发项目管理工具。

我的看法：DevOps——更广泛地说，云——极大地降低了迭代开发软件的成本。早在创建 Scrum 等敏捷方法的时代，交付的成本和复杂性要高得多。Scrum 的僵化结构是一种有效且必要的管理方式。今天在良好的 DevOps 环境中？没有必要？

这并不是说战略、规划、路线图、优先级以及围绕它们所需的所有协调与协作都是不必要的。它们与以往一样对成功至关重要。但是 Scrum 的僵化将其转化为迭代发布周期？没有必要？

营销中有 DevOps 的等价物吗？

营销运营与 DevOps 是一种不同的生物。一方面，它是营销组织中的一个角色/团队，而不是所有营销人员都使用的实践/流程。

然而，有一些共同的 DNA。在许多方面，营销运营团队充当类似于 DevOps 的推动者，使营销人员能够快速、迭代和安全地「发布」营销活动。营销运营管理技术栈和流程以实现这一点——通过大量的自动化和仪器。

然而，随着 martech 中越来越多的无代码功能的兴起，营销运营也为营销人员提供了越来越多的自助服务功能。正如软件部署操作通过 DevOps 被「左移」（即向上游移动）到更多开发人员手中一样，更多执行营销的能力——包括内部和外部营销「部署」——正在转移到普通营销人员的手中。

我不知道这种现象有什么名字。这是营销运营某些方面的一种草根化（理想情况下，在专家营销运营团队的指导、治理和保护下）。但它越来越类似于 DevOps。更多的人可以快速、轻松、安全地发布更多营销信息。

就像软件一样，战略、规划、路线图、优先级、团队协调和协作对于有效利用这种分布式创造的力量至关重要。但同样，在过去十年中，部署大多数营销方式的成本也大幅下降。这在营销生产过程中造成了更多的松懈，这使得僵化的敏捷营销方法……没有必要了？

新的敏捷实践：DARCI、Slack、「Work OS」

说到 Slack，或者，嗯，Slack，过去 10 年也带来了工作沟通和协作产品创新的爆炸式增长。例如，Slack 和 Microsoft Teams 已经变得无处不在——以及与之扩展和集成的整个应用生态系统。新一代工作管理平台，例如 Asana、ClickUp、Monday.com 和（面向营销人员的）Workfront，为复杂、快速变化的优先事项、项目和工作流程提供了更好的结构和可见性。

2020-2022年Martech Landscape管理类别的增长

事实上，从 2020 年到 2022 年，martech 领域的管理类别的百分比增长幅度最大。

这些工具对工作的完成方式产生了重大影响。他们中的许多人结合或启用了敏捷实践。几乎没有人使用敏捷营销方法的术语。但敏捷的精髓就在那里：透明度、优先级、问责制、进行中的管理、识别障碍和瓶颈。

同时，我想说的是，Slack 和 Teams——由大迁移到远程工作加速——已经有效地取代了大多数团队的例会。

但这并不是说例会的基本原则已经消失。相反，这些企业通讯平台通常使团队更容易以相对低影响的方式全天保持联系。与在固定时间窗口内等待下一次例会相比，出现的问题可以更快地解决，这越来越无法与分布式团队成员的日程安排保持一致。

嘿，我仍然是面对面合作的忠实拥护者，我同意没有它会丢失一些东西。但是获得了其他东西。无论好坏，远程和混合团队都是新常态。在这个美丽新世界中，对于许多人来说，Slack 和 Teams 比日常例会更适合。

这不仅仅是技术。我认为是针对特定需求的「点解决方案」的管理方法——与一整套实践相比，如正式的敏捷营销——已经普及，以实现更好的跨职能协作和多方决策（如 DARCI 模型）。

净效应？营销团队变得越来越敏捷。

他们只是不一定将他们的做法视为正式的「敏捷营销」。

从敏捷营销到……营销？

数字营销发生了什么？它变成了营销。

不是因为营销变得不那么数字化了。恰恰相反。数字化变得如此深入到营销人员所做的一切事情中，以至于该行业的标签回归到了中庸之道：营销。我认为这是数字营销运动的胜利，而不是失败。

同样，敏捷营销是否只是变成了……营销？

也许「敏捷营销」将作为一项明确的运动重新开始增长。或者，它可能会被一些新命名的方法所取代，这种方法更接近于 DevOps 在软件开发行业中的地位。或者也许只是隐含在现代营销团队的运作方式中。

敏捷就像敏捷一样。

无论如何，我仍然相信有一个巨大的机会可以教营销团队如何最好地利用所有这些平台、实践和流程。在当今的环境中，通过良好的培训、支持、咨询和咨询服务来帮助营销团队实现最佳绩效的需求从未如此强烈。

我们如何称呼它真的很重要吗？

作者：Scott Brinker

翻译：Fred