敏捷成为营销团队的必备条件

随着Martech的发展，一系列技术领域的术语应用于营销领域，「敏捷」便是其中一项。

敏捷（Agile），或称敏捷开发，是应对快速变化的需求的软件开发能力，更强调程序员团队与业务专家之间的紧密协作、面对面的沟通、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法，也更注重软件开发过程中人的作用。

最初创建敏捷方法的目的，是提供给软件开发人员一个框架以创建产品，并在创建的过程中提供大量反馈，而不是等到流程结束才获得反馈。敏捷开发开发使得开发人员更充分思考、并理解他们的最终用户。这是营销人员值得借鉴的。

2012年，一群「敏捷营销人员」聚集于旧金山的SprintZero活动，发布「敏捷营销宣言」。以下是主要原则：

• 经过验证的知识，而不是观点和约定俗成
• 以顾客为中心的协作，而不是「孤岛」和「层级」
• 适应和迭代，而不是爆炸性的广告活动
• 有一套流程来寻找客户，而不是静态预测
• 灵活，而不是死板的计划
• 响应变革，而不是跟随计划
• 多次小规模试验，而不是豪赌

本届Martech Conference上，虽然没有设立专门的场次讨论敏捷，但在诸多嘉宾的发言中，都有所涉及（这从一个侧面反映出，敏捷已经不再是一个新生词汇，需要专场来讨论了）。

例如10月1日，来自Real Story Group的分析师Tony Bryne谈到了如何使用敏捷方法，帮助营销人员在他们的产品中构建测试，而不仅仅是提供一个Demo，「在演示中，您可以观看供应商播放的品牌故事；花点时间测试，看看Demo如何在实际场景中工作。」

10月2日，《纽约时报》产品营销技术总监Pamela Della Motta和工程副总裁Kristian Kristensen介绍如何使用敏捷方法促进团队合作。

起初，《纽约时报》的技术团队隶属于营销部门，技术作为营销的支持功能存在，营销策略决定了技术的实施；而在数字化转型的过程中，出现了种种问题：传统的营销方式无法有效量化，原本形成一个个「孤岛」的营销渠道也需要整合；技术越来越复杂，并且相互依存；预先准备的项目实施计划很容易过时……

Pamela特别提到了现在处于一个「VUCA」的环境中（V指Volatility，易变性；U指Uncertainty，不确定性；C指Complexity，复杂性；A指Ambiguity，模棱两可，Scott Brinker在10月2日的发言中也强调了这一点）。

最终《纽约时报》选择了敏捷方法，因为它能够「随着市场的快速变化而不断发展」；同时采取了产品经理制而非之前的项目制来解决营销问题。

Pamela表示，在一家由敏捷团队组成的敏捷企业中，团队之间可以更快地解决彼此间的冲突；促进沟通和提升透明度；通过快速迭代快速提供价值。

Pamela同时也强调，「如果不考虑所采用工具相关的组织环境，就无法构建该工具。」并举了一个例子，一个没有提前进行流程训练而构建工具的例子；问题的根源在于，团队更集中注意力于工具，而不是使用工具的人。

敏捷应成为营销组织的DNA

在一篇文章中，Rotkow比较了敏捷方法和传统的「瀑布」模型的区别。「瀑布」模型（Waterfall Model）强调系统开发应有完整之周期，且必须完整的经历周期之每一开发阶段，并系统化的考量分析与设计的技术、时间与资源之投入等，适用于创建单独的大型新产品。

Rotkow主张企业应混合使用瀑布和敏捷，协调不同的团队，将营销计划和营销活动（编辑、信息架构、品牌指南等）联系起来，这样每种方法都能产生价值。

对敏捷的批评

「战略就像交响乐。每项促销策略或媒体渠道，就像乐队中的一群音乐家。但是，并非世界上任何一种乐器都适用于任何一首歌曲，因此不应该将每种策略或渠道都纳入战略。战略通过预先研究和确定做什么、和不做什么，来促成效率最大化。」而「坚持敏捷、并且一直在改变短期策略的品牌只会亏钱。」

Scott甚至强调说，假设你做「敏捷营销」，并且一直测试各种策略和渠道。如果要花几个月的时间来确定哪种方法最有效，那就浪费了时间和金钱。一个好的战略将决定一开始要做什么。

对于Scott的批评，另一位Scott，即Scott Brinker本人进行了回应，称：将敏捷营销和战略品牌领导作为对立的两极，这是对敏捷营销的错误描述。

Brinker介绍说，敏捷管理是一种执行战略的方式，当你所处的环境是流动和变化的，并且你想要快速感知并应对这些变化，或你借以实施战略的媒体能够延展性，并具有快速的反馈回路，可以提供迭代优化，并迅速而廉价地执行。

「敏捷通常不会在一次又一次迭代的基础上改变战略。但它也不会让糟糕的、过时的或被打乱的战略偏离轨道太远，除非提供必要的经验数据以做出修正。」