敏捷实践:如何避免我们的营销团队犯的错误

已发表: 2020-12-22

错误敏捷营销团队 秘密出了。 敏捷项目管理可以改变游戏规则-开发人员和IT人员不再是唯一了解它的人。

作为营销人员,您肯定已经听说过敏捷。 您的团队可能正在使用某些敏捷实践,例如项目冲刺和站立会议。 如果是这样,那么您就是少数。 营销团队尚未充分利用敏捷的好处。 根据Workfront和MarketingProfs的新报告,只有30%的营销团队使用敏捷方法来管理其流程。 在我们致力于使敏捷工作之前,其他70%的人可能会遇到我的团队同样的挫败感。

#30%的营销团队使用#Agile方法通过@workfront_inc @MarketingProfs管理流程。 点击鸣叫

我们在Emplify的七人行销团队已经实践敏捷近一年了。 我们花了六个月的时间才能很好地实践它:更好,更快地制作工作,并投入更多精力和精力。

当我们开始练习敏捷时,我们犯了很多错误。 事实上,如此多的错误使我们有一天将一半的团队锁定在会议室,直到我们发现并解决了我们的方法中的一些重大缺陷后才离开。 幸运的是,那天有啤酒。 但是,这仍然很痛苦,并且需要花一些时间才能将自己从一些深层的,面向过程的漏洞中解脱出来。

在本文中,我分享了这些错误,以便您可以避免像我们这样的痛苦锁定。 如果您致力于使流程为您服务,那么敏捷可以彻底改变您的营销团队的协作能力并更快地交付工作。

在开始之前,我们先介绍一些基本知识:

什么是敏捷实践?

敏捷实践(通常称为“敏捷”)强调在具有较大互连任务的项目上持续交付较小的工作部分,这些任务可能跨越数周或数月(传统上称为瀑布式管理)。

敏捷基础知识包括:

  • Scrum团队:这个高度协作的团队由Scrum负责人组织,解决了复杂的问题,并以称为sprint的定长迭代提供解决方案,该迭代可以持续一周到30天。 例如,负责内容的Scrum团队可能会开始进行为期两周的冲刺,承诺创建新的信息图表或数据表。
  • 最小可行产品(MVP):在规划可交付成果时,敏捷原则强调尽快将项目发布出去,以便您的团队可以对实际问题做出早期响应。 为了实现持续交付的模型,Scrum主管鼓励团队定义MVP并找出在sprint范围内完成产品的最具创造性的方法。 例如,如果您开始一个为期两周的冲刺以创建电子书作为您的MVP,而您的设计师生病了,则可以决定将该冲刺的MVP重新定义为一系列博客文章,然后在下一个设计电子书短跑。
  • 每日站立会议:团队成员每天早上围坐15分钟左右,以讨论Scrum团队已完成的任务,重点领域和阻碍者,这可能会阻碍他们完成分配的冲刺工作。 在sprint结束时,敏捷团队将交付一组已定义的项目,然后在下一个sprint中对其进行评估和改进。 一些Scrum团队还参加了回顾会议,在会议上讨论可以在下一个Sprint中解决的过程缺陷。

敏捷营销错误_1

涉及的相关内容:
30个高效率内容团队的习惯[Infographic]

营销人员为什么要使用敏捷?

国家公共广播电台使用敏捷方法来创建和测试新节目。 在下一个“车道时刻”考虑一下。 尽管敏捷的根源是IT管理,但是这种形式的项目交付可以应用于企业的许多功能,包括市场营销。

采用连续迭代的敏捷模型,您的营销团队可以快速测试新消息或广告活动,对产品更新做出更快反应,并与要求您团队工作的利益相关者建立期望。

在我们开始敏捷之旅近九个月后,我们团队的光辉时刻就出现了。当时,我们刷新了网站上的内容,以对我们的产品消息进行一些调整。 我们定义了一周内可以完成的工作,并按计划完成了这项工作。 我们在导航中隐藏了我们没有时间在该sprint中更新的内容。 在后续的sprint中,我们一直在不断添加和刷新这些页面上的消息。

涉及的相关内容:
对敏捷营销感到困惑? 回答您的问题[带视频]

应该避免什么错误

如果您正在考虑在团队中采用敏捷,即使您只是希望简化营销团队中的流程,您也要避免我们团队犯下的这四个敏捷营销错误:

  1. 我们自称敏捷而不做功课。
  2. 我们未能指定问题负责人。
  3. 我们专注于可交付成果,而不是问题。
  4. 我们做事而不是优先考虑(并且假装我们可以完成所有工作)。

错误1:我们不做作业就自称为敏捷

当我开始与营销团队合作时,我迅速建立起每日站立的机会,以提供一种快速,轻松的方式检查项目的方法。 我以为我曾担任过以前的角色,曾做过站姿和有组织的冲刺比赛,所以我有敏捷的经验,对吗? 错误。

不要在一个星期一上班,像我一样宣布您要“敏捷”。 仅仅因为您正在进行为期两周的冲刺,并且每天都站起来,并不意味着您就是一个敏捷团队。 敏捷的优点在于,它使您的团队有权共同致力于项目,并在指定的时间内定义可交付的质量。 如果您只是想在两个星期内完成尽可能多的工作,并且为了达到终点而牺牲质量,那美就被否定了。

在营销团队中建立敏捷流程之前,请做好功课。 破解一两本书。 我建议从Jeff Sutherland(被称为敏捷之父之一)的Scrum和Scott Brinker的Hacking Marketing开始。 此外,请阅读CMI关于敏捷营销的出色文章。

完成作业后,优先考虑对现有流程的一些简单更改,以开始制定一种适用于您的团队的敏捷方法。

@evacjackson说,在您的#contentmarketing团队上建立#Agile流程之前,请做好功课。 点击鸣叫

错误2:我们未能指定问题所有者

如果没有发生以下情况,则可以跳过本节; 您实现了我尚未发现的某种形式的营销过程必杀技。

其余的人则想像一下:在一个大型团队项目中,您有98%的工作期限很明确,最后一个小时,利益相关者惊讶地加入了数十次修订。 然后,您的团队被迫将项目延长两个星期以解决这些更改,因为没有人可以说这个利益相关者是错的。

还在读书吗? 我是这么想的。

我们团队缺乏明确的所有权是我们发展敏捷营销部门的最大障碍。 我们不知所措。 当多个利益相关者参与项目质量评估时,我们感到沮丧。 由于最新的编辑和修复,我们没有得到任何帮助。

如果您的营销团队像我们一样,那么您就很难知道项目的最终所有者是谁。 由谁直接负责交付成果的成功? 谁为团队可以完成的任务设定可衡量的结果? 谁需要这个项目才能成功,以便他或她最终也能成功?

为了防止最后一刻返工,我们现在为每个项目分配这样的人员(问题负责人)。

防止最后一刻返工,在#Agile #contentstrategy中为每个渠道分配问题所有者。 @evacjackson点击发推

每个季度,我们都会为我们的每个主要营销渠道设定销售合格的潜在客户目标:广告,活动,有机网站潜在客户等。 然后,为这些渠道中的每个渠道分配一个团队所有者,而该所有者将成为该渠道下所有可交付成果的首选人。

由于以下几个原因,问题的所有权对于我们的团队特别成功:

  • 它把成功的责任放在一个人身上,如果没有达到目标,这个人就要负责。
  • 这迫使渠道所有者尽早发现问题,以便团队主动解决。
  • 它允许整个团队参与集体讨论解决方案并实施修补程序。
  • 它使一个人可以指导任何给定项目的质量。

如果您的团队不清楚谁在内容项目中拥有最终决定权,请与您的部门坐下来,问一个棘手的简单但具有挑战性的问题:“谁拥有什么?” 回答该问题并记录您的答案以供所有人查看,将产生不可估量的责任感。

涉及的相关内容:
如何避免内容团队内部的协作超负荷

错误三:我们专注于可交付成果,而不是问题

对于敏捷团队来说,另一个改变游戏规则的时刻是,当我们停止将我们的工作视为一组可交付的成果时,便开始考虑将我们的工作视为要解决的一系列问题。

考虑一下团队中的各个贡献者:开发人员,撰稿人,设计师和其他类似的实现角色。 他们多久被要求“设计这张幻灯片”或“撰写这本电子书”,而他们却很少这么做,为什么?

只是在待办事项列表上分配任务而没有帮助您的团队了解项目背后的真正目的,这会导致工作乏善可陈,而无需团队的个人投资。

@evacjackson说,没有帮助您的团队理解目标的任务分配会导致工作乏善可陈。 点击鸣叫

实际上,缺乏以目标为导向的工作不仅会对您的营销策略产生严重影响。 在对LinkedIn成员的调查中,超过60%的非定向工作受访者计划在三年或更短的时间内离开公司。

接受调查的60%以上的人没有计划在3年或更短时间内离开目的职业。 @LinkedIn @Imperative点击鸣叫

在我们的团队中,我们有一个严格的规则,禁止在考虑到规定的交付成果的情况下开始任何项目。 面对现实吧,利益相关者并不总是知道他们想要什么。 解决问题有助于促进协作以获得更好的结果。

取而代之的是,我们在每个项目中都以问题陈述开始,该陈述遵循在敏捷开发世界中通常称为用户故事的格式。 该格式如下所示:

当发生__________时,我想________,以便我们得到此可衡量的结果:___________。

这是一个假设项目中此类问题陈述(或用户案例)的示例:

敏捷营销错误_2

每个项目的问题所有者确定团队将为该项目解决哪些问题。 例如,如果网站未针对某个关键字进行排名,或者需要为即将到来的贸易展览更新消息,所有者可能会认为这是一个问题。 不管有什么问题,问题说明都永远不会包含解决方案。 在决定优先处理特定问题之后,我们的团队会一起分析问题,最终确定可以在下一个冲刺中执行的解决方案。

团队解决问题可以使每个人都对结果负责。

此外,这种方法迫使团队发现表面问题背后的痛点,从而找到解决核心需求而不是虚荣要求的解决方案。

例如,我们的销售团队报告说,一些潜在客户没有参加他们预定的演示会议,也没有响应重新安排的请求。 我们的销售副总裁希望营销团队制作动画讲解视频,以更好地吸引见面的人,尽管这样做可能要花几个月的时间。

在询问了有关销售流程的一些问题之后,我们意识到可以通过在演示会议之前改进电子邮件消息来解决销售团队的核心问题。 我们安排了一次会议,立即启动了一个三电子邮件滴灌运动。 该解决方案只花了两天的时间就使团队得以构建。 自制作此广告系列以来,我们将需要重新安排会议时间的人数减少了一半以上。

在将任务分配给团队成员之前,请先问问自己为什么这项工作很重要。 通过创建问题陈述并就解决方案进行协作,我们能够确定快速解决方案,该解决方案已为我们的团队带来了回报。 如果我们创建了动画视频,则销售团队可能在等待修复的过程中已经处理了几个月的问题。

错误四:我们塞满了,而不是优先考虑(并且假装我们可以完成所有工作)

如果您像我们一样尝试尽可能地适应每个敏捷营销冲刺,那么您做错了。

没有共同的优先感,您就不知道将时间集中在哪里。 如果没有重点,您只能对所有事情说“是”。 当您对所有事情都说“是”并且没有项目负责人时,您会发现自己陷入了紧张的四分之一的困境中,并交付了许多未完成的项目。

许多敏捷团队以团队为单位使用估算来确定工作的优先级并提高速度。 他们估算了一个项目所需的工作量,或者讨论了个人完成任务可能需要花费多少小时。 随着时间的推移,许多敏捷团队会感觉到每个sprint的平均产出,这有助于他们计划新任务。

在敏捷团队的最初几个月中,我们着手进行这种估算。 不幸的是,我们最终操纵了我们的估计,以至于看起来我们可以完成所有事情。 我们猜测了一个项目将要花费多少工作,然后我们降低了需求,以便为其他三个请求腾出空间。 最后,我们否定了估算工作的价值,使压力持续存在。

我们尝试了两种或三种跟踪速度的方法(包括计划扑克,这是估算工作量的常用方法)。 我们专注于使用估算来证明我们可以完成很多工作,而不是成为一支效率更高的团队。 那是我们的错误。

最近,我与我们公司的工程总监聊天,后者为我们的产品团队管理敏捷流程。 当我提到我们的团队从未掌握过估算时,他说:

如果您的利益相关者不断要求团队提供速度报告或改进的估计,您可能会遇到更大的过程问题,这些问题会损害团队按时向他们交付工作的能力。

您是否对#AgileMarketing速度或整体项目交付有疑问? @evacjackson点击发推

当运作良好的敏捷团队定期交付项目的快速迭代,并在期限不合理的情况下向利益相关者提出问题时,您自然会避免对团队的产出或生产力提出疑问。 当工作落后时,项目经理或Scrum主管有责任进行纠正并传达这些更改。

不要害怕在下一个Sprint中仅优先处理一个或两个新项目(或问题或故事),因为当前Sprint中有一些剩余项目。 只要确保及时将剩余的工作传达给利益相关者,并分享您的计划,以尽快完成该项目。

并且不要害怕指定一位领导者就需要优先考虑的事项做出最终决定。 例如,我们的团队禁止所有人将Trello卡移至“优先”冲刺栏中,但我们的营销副总裁除外。 那就是把责任放在优先考虑整个业务的人身上。

结论

就像每个敏捷团队一样,我们的团队正在以对我们有用的方式适应敏捷原则。 无论您的团队采用哪种敏捷方法,只有在您提供机会就流程进行公开反馈并且足够灵活地定期更改工作流程时,该方法才有效。 如果到目前为止,我对我们对敏捷方法所做的每一次调整都拥有记录,那将比这篇文章更长。

您的团队在实施敏捷流程时犯了哪些错误? 您如何解决这些错误? 在评论中让我们知道。

是否想改善内容营销效率的结构? 订阅我们的“营销商内容策略”每周新闻,其中包含首席内容顾问Robert Rose的独家见解。 如果您像我们遇到的许多其他营销人员一样,您将在每个星期六期待他的想法。

封面图片:Joseph Kalinowski /内容营销学院