What is Agile Marketing: Everything You Need to Know

Discover agile marketing in this comprehensive guide. Learn how to stay ahead of the competition and achieve your marketing goals applying agile methodologies.
Reading time: 31 Minutes
Share this blog post:

Table of Contents

This article was originally published on agilesherpas.comΒ byΒ Andrea Fryrear.

As audience expectations rise, marketing technology gets more sophisticated, and the number of channels we need to reach keeps growing, marketers are discovering that their tried and true ways of working just don’t cut it anymore.

Fortunately, Agile marketing holds the key to making marketing work in this volatile climate. But what is Agile marketing REALLY? Is it just being faster, firing all the managers, and marketing without a plan?

Not even close.

Agile marketing is the deliberate, long-term application of a specific Agile methodology to manage and improve the way a marketing team gets work done. It requires a strategic vision, as well as short-, medium-, and long-term marketing plans.

It differs from traditional marketing in several important ways, including a focus on frequent releases, deliberate experimentation, and a relentless commitment to audience satisfaction.

That’s a bird’s eye view of this whole Agile marketing thing, but I’m willing to bet that you aren’t a bird.

You’re a marketer who wants to know how it WORKS. How do these vague descriptions actually play out in a real live marketing department? I’m so glad you asked.

This is a detailed (I mean REALLY detailed) guide to Agile marketing, from its history to its methodologies to its mindset. You can find a hyperlinked table of contents right here so you can jump from section to section.

From Agile Software Development to Agile Marketing

The Agile craze has been transforming marketing teams of all shapes and sizes for years, but it has an even longer history outside of the marketing profession.

Agile approaches to managing knowledge work originated in software development in the mid- to late-1990s, completely revolutionizing the way that developers did their jobs.

Developers were in dire need of a change. Traditional ways of managing projects, known as the waterfall approach, just weren’t working. These techniques called for project managers to gather information about what the software was expected to do and collect them in massive documents known as requirements.

They’d deliver the requirements to the developers, who would then go off and create software that fit the specifications. Inevitably, it would take far longer for them to get it done than the project manager had estimated.

A 1995 report found that only 16.2% of software projects were being completed on time and on budget. In large enterprise companies the numbers were even worse, with only 9% of projects hitting time and budget estimates.

It was also alarmingly common for the final products to fail to satisfy the consumers they were built for. The developers who were writing the code were so far removed from the people who would use their software they weren’t delivering useful software.

Developers would get specs from managers, who would get requirements from other stakeholders, who would base those requirements on analysis or statistics, which might have been collected from actual users.

It was like a game of software telephone where the final message didn’t look much like the functionality that the audience originally wanted.

In fact, a 1995 study of $37 billion worth of US Defense Department projects concluded that 46% of the systems β€œso egregiously did not meet the real needs (although they met the specifications) that they were never successfully used, and another 20% required extensive rework” to be usable.

In this environment early Agile pioneers like Jeff Sutherland, David Anderson, Alistair Cockburn, Mike Cohn, and many others started searching for a better way to do work. In February of 2001 seventeen software practitioners met and wrote the original Agile Manifesto for Software Development.

From there methodologies like Scrum and Kanban began to emerge as ways to apply those core principles to software creation.

The results of applying these new systems were staggering.

Agile software development teams could now provide:

  • Transparency and visibility into their work throughout the development process.
  • Early and predictable delivery of small increments of work instead of one huge project that might take years to complete.
  • Predictable costs and schedule rather than ever-expanding scopes and timelines.
  • Adaptation to changes in the market and business goals.
  • A focus on user needs and business value.
  • Higher quality products with fewer bugs and defects.

Over time it’s become obvious that her aspects of modern businesses could benefit from taking similar approaches to their work, and so Agile has begun to spread from software into other function.

Agile marketing is one of the newer applications, with the Agile Marketing Manifesto having been written in 2012, and that specific use case is the focus of the rest of this guide (and this site in general).

What is an Agile Approach to Marketing?

Every Agile marketing implementation will look a little different, but they also share these key characteristics. If you’re missing one or more of these, you may need to take a good hard look at your team and see if you’re truly Agile or just giving your busyness a different name.

  • Mindset shift: Marketers on an agile team think about their work differently. They exhibit β€œrespect, collaboration, improvement and learning cycles, pride in ownership, focus on delivering value, and the ability to adapt to change. This mindset is necessary to cultivate high-performing teams, who in turn deliver amazing value for their customers.”
  • Experimentation, iteration, and small releases: Rigid, long-term plans don’t fit with an Agile environment. Instead you should see lots of small experiments being released frequently. Then the team applies the results of those experiments to their next round of work.
  • Adherence to the Agile manifesto: At the end of the day, the values and principles of the Agile manifesto should be the final arbiter for most decisions on an Agile marketing team. (We’ll go into the manifesto in more detail later in this guide.)
  • Mindset shift:Β Marketers on an agile team think about their work differently.Β They exhibitΒ β€œrespect, collaboration, improvement and learning cycles, pride in ownership, focus on delivering value, and the ability to adapt to change. This mindset is necessary to cultivate high-performing teams, who in turn deliver amazing value for their customers.”
  • Experimentation, iteration, and small releases:Β Rigid, long-term plans don’t fit with an Agile environment. Instead you should see lots of small experiments being released frequently. Then the team applies the results of those experiments to their next round of work.
  • Adherence to the Agile manifesto:Β At the end of the day, the values and principles of theΒ Agile manifestoΒ should be the final arbiter for most decisions on an Agile marketing team. (We’ll go into the manifesto in more detail later in this guide.)
  • Servant leadership:Β Managers, directors, and other people in leadership roles act differently in an Agile marketing department. They’re focused on helping theΒ teamΒ succeed, not on hitting numbers at any cost.
  • Teamwork and collaboration:Β Individuals onΒ an Agile teamΒ also behave in distinct ways, always looking for ways to join forces to do better work in a more efficient way. There should be an obvious lack of in-fighting, jealousy, and backstabbing on an Agile marketing team.
  • Data-driven marketing:Β All modern marketing teams need data to guide their efforts, but Agile teams are really and truly driven by their data β€” otherwise how would they know if their experiments were successful? They make sure all of their work can be measured, and they rely on empirical evidence to make decisions.

An Agile team looks, works, and acts differently. If your team is clearly different following your adoption of Agile marketing, you may not have gone far enough down the Agile path.

What is the Agile Marketing Manifesto?

In 2012, a group of forward-thinking marketers put their heads together to come up with the marketing version of the Agile Manifesto. The idea was to establish an agreed-upon set of values and principles to guide marketers as they tried to adopt a more Agile way of working.

According to the manifesto, Agile marketers value:

  1. Validated learning over opinions and conventions
  2. Customer-focused collaboration over silos and hierarchy
  3. Adaptive and iterative campaigns over Big Bang campaigns
  4. The process of customer discovery over static prediction
  5. Flexible vs. rigid planning
  6. Responding to change over following a plan
  7. Many small experiments over a few large bets

The principles remain up for debate, but these are the candidates for guiding work on an Agile marketing team:

  • Our highest priority is to satisfy the customer through early and continuous delivery of marketing that solves problems.
  • We welcome and plan for change. We believe that our ability to quickly respond to change is a source of competitive advantage.
  • Deliver marketing programs frequently, from a couple of weeks to a couple of months, with a preference for the shorter timescale.
  • Great marketing requires close alignment with business people, sales, and development.
  • Build marketing programs around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
  • Learning, through the build-measure-learn feedback loop, is the primary measure of progress.
  • Sustainable marketing requires you to keep a constant pace and pipeline.
  • Don’t be afraid to fail; just don’t fail the same way twice.
  • Continuous attention to marketing fundamentals and good design enhances agility.
  • Simplicity is essential.

For more detail on what each value and principle means, check out this Slideshare presentation:

3 Agile Methods for Marketing

While Scrum has gotten the lion’s share of coverage in the past decade and a half, it’s not the only way to implement the Agile mindset on your team. We’re going to spend a lot of time covering all three major methodologies, Scrum, Kanban, and Scrumban, so you can make the right choice for your team.

For more on why Scrum isn’t always the best choice for marketers, check out this Slideshare:

What is Agile Marketing Like With Scrum?

Ok, let’s talk about Scrum. This is a basic diagram of how Scrum works on a team, which you may have seen before. Let’s start by talking about what we see here.

First we see the backlog, which is simply a prioritized to-do list for the marketing team to use as the source of all their work. That’s a nice simple explanation, but backlogs are shockingly difficult to maintain.

To be at their most useful they need to be constantly updated, and the work near the top needs to have enough detail that the Agile marketing team could start working on it immediately without asking anybody any questions.

A good backlog is the heart of a high functioning Agile team of any kind, and if you neglect it you’ll quickly find issues cropping up throughout the process.

At the start of each Sprint the marketing team pulls work from the comprehensive marketing backlog to form the smaller Sprint backlog. This is the amount of work they believe they can complete within their next Sprint. It’s up to the team to make this call, not their manager or the director or the CMO.

The idea is that the Agile team who executes the work has the best understanding of how long things REALLY take to get done, so they’re best qualified to decide how much they can get done.

Sprint Planning Meeting

The meeting where the team figures all of this out is called the Sprint Planning Meeting.

Generally you should plan to take an hour for each week of your sprint for planning, meaning a two week Sprint will take two hours to plan. If you’re estimating the size of your work that should also happen during Sprint Planning.

You can assign points to each project to reflect their relative size, typically using the Fibonacci sequence that you see here. So a project that’s a 2 is twice as big as a project that’s given a size of 1, and so forth.

The total number of points that the team is working on is known as its Velocity, and ideally that number should climb steadily as the team stabilizes and gets better at practicing Scrum.

Estimating helps you get a more objective look at how much the team is doing, but it’s a bit of a controversial practice.

Some people think estimating is actually waste because humans are really, really bad at it.

We get it wrong a lot, especially when we’re new to the practice. Others think that without estimating it’s practically impossible to track a Scrum team’s progress over time. Estimation can also help quantify the costs of interruptions or emergencies, because the team can say β€œwhen we have external interruption we only get 25 points done, but without interruptions we get 32.”

As with most things on an Agile team, my recommendation for you when it comes to estimation is to try it out and see if it helps your team.

Be honest about whether the time it takes is getting you the benefits your after, and adjust accordingly. Just make sure you devote plenty of time to the experiment, at least a couple of months, because it can take teams quite a while to get good at experimentation.

During the Sprint

Ok, after the Sprint Planning meeting the team is committed to a set amount of work and the Sprint begins. Ideally once they’ve started the Sprint the team is locked into to only the work they’ve chosen.

Nobody should be able to add anything new onto them.

In reality there are usually unplanned things that come up, so you can either negotiate these events by taking some work out to make room for the unplanned projects, or you can leave some of the team’s time unplanned knowing that something will happen to fill that time.

As the Sprint proceeds, the team meets everyday to share their individual updates on how things are going during the Daily Standup meeting, also known as the Daily Scrum.

This meeting shouldn’t last any longer than 15 minutes, because otherwise you’re wasting a ton of the team’s time. It helps to have everyone actually standing up to motivate them to keep things nice and short.Β Forbidding laptops and phones at this meeting also helps with brevity.

The traditional format for standup is to talk about only three things: what each team member did yesterday, what they plan to do today, and any road blocks they’re experiencing. It’s very easy for this meeting to devolve into a boring check in, but it should be more like a mini-strategy meeting or a football huddle.

All team members should be thinking about how they can join forces in the next 24 hours to get things done better, just like a football team decides what play to run next in each huddle.

As the Sprint comes to a close, the goal is to have something that could be released out to the audience. If it’s a small component of a larger campaign you don’t HAVE to release it, but the great thing about Scrum is that it helps us deliver useful marketing work to our audience constantly and consistently.

Post-Sprint Meetings

Also at the end of the Sprint the team holds two final meetings: the Sprint review and a Retrospective.

The Sprint review is like a show and tell. Any and all internal stakeholders attend, and the marketing team shows what they’ve completed during the previous Sprint.

A retrospective, on the other hand, is attended only by the Scrum team.

It’s their opportunity to honestly discuss how the process is working for them and how they might make it better. Any suggestions for improvements that the team comes up with should be documented and added to the backlog to make sure they’re acted on. There’s nothing more frustrating than talking about the same things at every single retrospective because the problem isn’t being addressed.

Retros are another meeting that can stagnate easily if you don’t keep them fresh. Be sure you have a facilitator to run the meeting and encourage participation from every contributor as well as respectful debate. These meetings should be one of the most important hours that your team spends together.

And then, after the retro, it all starts again with a Sprint planning meeting.

Members of the Scrum Marketing Team

That’s a high level look at WHAT happens on a Scrum marketing team, but we also need to talk about WHO belongs on these teams. Traditional Scrum roles include a Scrum Master, a Product Owner, and developers, but marketing teams don’t usually look like this.

For one thing, few of us have the budget to hire our own dedicated Scrum Master. I suggest getting a couple of people on your team certified and rotating Scrum Master responsibilities among them so they can still perform their β€œregular” jobs too.

As for the Product Owner, this Scrum role is designed to be the intermediary between the development team and the business. They keep the backlog current, communicate with stakeholders, and help the team make sure they’re doing the right work at the right time.

Marketing teams typically find the best success when they give the Product Owner responsibilities to a marketing leader like a director or senior manager.

Finally, Scrum originally envisioned a team of purely cross-functional folks who all had the title of developer. Marketing teams tend to be far more specialized than this, so don’t worry about changing everybody’s title to β€œMarketer.”

Who Should Use Scrum

As I said, Scrum works great in particular contexts, but it’s not necessarily right for everyone. For one thing, it was designed to work on teams of 5-9. When teams are larger or smaller things get a bit more complicated.

It also works best when the team is cross functional, because that means they can complete all their work from start to finish without relying on someone outside the Scrum unit. This gives them a much better chance at actually delivering the work they committed to during Sprint Planning.

So if you rely on freelancers or agencies and want to use Scrum, your best bet is to get them on board with your cadence.

Scrum can also be great for teams that suffer from a lot of external interruptions because it gives you a nice way to say No or Not right now when people want to throw something onto the team. You can politely say that you’ll put it into the backlog and get to it in your next Sprint.

Finally, if your marketing team is open to some serious change in how they manage work, then Scrum could be a good fit for you. Not everybody is up for major alterations in their workflow, so you may encounter resistance if you don’t have a really willing marketing team.

What is Agile Marketing Like With Kanban?

As you can probably tell, Scrum is a pretty prescriptive approach. It has strong opinions about how and when we should do certain things. Kanban, on the other hand, is far more adaptive. It’s designed to work WITH the way you already manage your work.

Rather than a work management system, Kanban is more like a continuous improvement tool.

Kanban is based on something that sounds a little paradoxical: by limiting the amount of work we do at any given time, we get more done.

Another way of saying this is that Kanban encourages us to stop starting and start finishing our work.

To show us how much work is in progress we need to see our work, so an accurate visualisation of the workflow is one of the central tenets of Kanban.

Known as a kanban board, this is a simple system for showing all the possible states that work could be in on your team, and how much there is in each state at any given time. You’ve probably seen boards like this; Trello has made them a popular way of managing all kinds of projects.

But just using a kanban board doesn’t mean you’re using the Kanban methodology.

In addition to this workflow visualisation, we’re going to talk about 3 other components of a successful Kanban marketing team: WIP limits, explicit policies, and work item types.

About the Kanban Board

No Kanban team can function without its kanban board, which must be an accurate representation of how work REALLY gets done on the team, not how you wish it got done or how your managers think work gets done.

When we have our process made visible like this, we can easily see where things are getting stuck, known as bottlenecks. The team can then start to make adjustments to eliminate those bottlenecks and make work flow more quickly through the team, improving output and efficiency for the team.

If you’re having trouble figuring out how to structure the board, think of any serious gates or gatekeepers in your workflow, like approvals, reviews, handoffs from one person to another, or releases to the audience and use those to create columns.

The board also has to have reasonable start and end points. These should represent the outer limits of where your team controls its workflow.

So if some of the sources of your work are outside the team, if they come from sales for example, then your workflow visualization shouldn’t start with brainstorming new projects.

The same thing goes for the end point. If legal has to review everything you do before it’s published, you may have to end your board at β€œready for review.” You don’t control how long it takes legal to review things, so including that stage of work could really mess up your understanding of your workflow. Work would appear to be stuck in Review all the time, but you couldn’t do anything to fix that bottleneck.

One more thing about the board: it needs to accurately represent how work happens on your team, but it should also be as simple as possible.

Keep your columns, the states that work goes through before it’s done, under 7 if you can, and definitely don’t let them grow to more than 10. At that point the system is too complex, and you’ll have trouble optimizing the flow of work. If you feel that you need more than 10 states of work, you may actually need more than one board.

Don’t hesitate to create several different boards if sub-sections of the team do very different kinds of work.

The point of all this visualization, of course, is to see where work is getting stuck. You can’t go any faster than your bottleneck, so by finding out where it is and doing your best to mitigate it you’ll improve the flow of work through the team.

WIP Limits

Once we have the board all set up, we need to put limits on how much work can be in each state at any given time. This is called a Work in Progress, or WIP, limit, and it’s one of the most powerful tools in the Agile toolbox.

We don’t want a WIP limit that’s too high, because then we have tasks that sit idle.

If the WIP limit is too low, then we have people who are idle and don’t have anything they can work on. In both cases work flows sluggishly through the system, which is not what we want.

We need a Goldilocks WIP limit that’s just right, keeping people busy and tasks flowing quickly from one state to another. We know we’ve got this right when we get down to just one bottleneck in the system.

That means there’s just one point in our workflow that’s operating at maximum capacity, or just one person (or team) in our marketing department working at full capacity all the time.

Everyone else will experience moments of downtime, or slack.

Slack is an amazing byproduct of a high functioning Kanban team, because it purposely creates moments when people aren’t working. During that time they can think about ways to improve the process, do some professional education, or strategize about the next great project for their team.

It doesn’t matter too much what they do, but the fact that people on the team have time to reflect and consider their next step is a major improvement over marketing teams who spend their time running nonstop without any idea where they’re going or why they’re going there so fast.

As you’re working towards this promised land and setting your first WIP limits, start higher than you think you need to and work down.

That will allow you to take a sufficient amount of work into the system to see how things are flowing (or not flowing). If you start too low you won’t have enough tasks in the flow to see where the areas of improvement really are.

Making Policies Explicit

The next crucial piece of a Kanban implementation is to create explicit policies about how work gets done on your team. Most of us have implicit policies, or ways that we all just do things, but by making them clear and publicly visible we eliminate misunderstandings and create consistency across the marketing function.

One of the policies we have to clarify first are the cadences for our Agile marketing team, because we don’t have Sprints to provide structure around things like retrospectives and backlog refinement.

This can be powerful because we can have retros every week but only work on the backlog when it gets down to less than five items. These two activities don’t have to be tied to a Sprint schedule; they can happen whenever is best for the team.

Just make sure you clearly define when backlog refinement, retrospectives, and releases will happen. You’ll still have standup meetings, but those should continue to happen daily to get the best results.

You’ll also need to create policies around how different kinds of work gets done. Deadline-driven projects should automatically take priority of β€œnice to have” work, and emergency requests from the C-suite may have to put all other work on hold.

Kanban Work Item Types

The most efficient way to get these kinds of policies in place is to create categories or buckets for your work known as Work Item types. That way when new work comes into the system you can quickly categorize it, which allows the team to know which policies apply, and therefore how they should handle that new work.

This combination of work item types and explicit policies allows Kanban teams to get away from estimating each individual piece of work like some Scrum teams do, so don’t neglect these pieces of the Kanban process.

Try to keep your work item types under 6, otherwise it’s difficult for the team to easily recall them as they’re planning work.

The same thing goes for the policies that you put in place around your work item types β€” you want to keep it around 6 or less so that team members can always remember exactly how to handle various kinds of work that the team is asked to do.

Who Should Use Kanban

Finally, let’s talk about who should consider Kanban as their first step on an Agile marketing journey.Β 

As with Scrum, I want to share four characteristics that may indicate that Kanban is right for you.

First of all, Kanban can work for teams of just about any size, but it can be particularly useful if your team falls outside of Scrum’s sweetspot of 5-9.

In fact, single-person teams can easily use the Kanban system, and it scales up without much additional effort.

Second, teams that aren’t cross functional can find great benefit in Kanban. So if you rely on external resources, whether that’s another department in your organization, freelancers, or agencies, then Kanban could be for you.

If you’ve got skeptics in your organization who want some quick proof that Agile could work for marketing, Kanban may be able to get you those kinds of results faster since it’s designed to work on top of your current system without demanding a whole bunch of change before you start seeing benefits.

And finally, if your marketing team is already super burned out and stressed out but you still want to help them out with an Agile approach, you should definitely use Kanban. It’s so adaptive that it won’t disrupt your output or force them to overhaul their systems right away, meaning they can start without much drama.

What is Agile Marketing Like With Scrumban?

As you’ve probably guessed, Scrumban is a combination methodology, taking some elements from Scrum and others from Kanban to create something different. Simply put, it involves applying a Kanban system in a Scrum context.

In practice that typically means visualizing the workflow on a kanban board that employs WIP limits, work item types, and explicit policies while continuing to plan and release work within recurring Sprints

While I say β€œtypically,” that’s really just the most common kind of Scrumban implementation.

Each team will have their own way of applying the Scrumban methodology, and no two will be exactly alike. The great thing about Scrumban is that it’s like having access to a fully loaded buffet of agile options and getting to choose whichever ones you like best.

A few things that you should definitely keep, however, are daily standup meetings, a visualized workflow, and regular retrospectives. Those three things form the foundation of just about any good Agile team, so whatever other components you decide to use, don’t get rid of those three.

Some of the use cases for Scrumban are similar to the ones we talked about for Kanban. So if you have very small or very large teams or rely on external sources to complete your work Scrumban may be a good fit for you.

You might also consider trying Scrumban first if your team is already fairly stable and you’re looking for a competitive advantage to give you a leg up on the competition.

Because Scrumban gives you control over every single aspect of the Agile system, you can get some amazing results pretty quickly when you roll it out right.

Likewise, if your team has a good deal of autonomy to experiment with its process, then Scrumban is a great place to start your Agile marketing journey. Autonomy will give you the freedom to experiment across the full range of Scrumban options, so you’ll find multiple opportunities for improvement faster.

Common Agile Marketing Myths

Despite being five years from the creation of the Agile Marketing Manifesto, misconceptions about Agile marketing still run rampant, creating misunderstandings and misinformation about the application of Agile principles to marketing.

As part of this explanatory piece, I want to debunk two of the most common (and most dangerous) fallacies that I encounter when talking to marketers about agility:

If you’re Agile, you don’t plan anything
Agile marketing = using Scrum on your marketing team

Myth #1: Agile is Anti-Planning

This myth can be summed up in a single line from an article claiming to be about agile marketing: β€œCan you plan to be agile? Isn’t that cheating?”

Sadly, this author isn’t the only one to make this mistake:

  • β€œsome of the most impressive examples of agile marketing happened because of an event that couldn’t be planned for.”
  • β€œThis is where agile marketing comes in: small bursts of quickly developed content designed to catch the public mood at just the right time in order to capitalize on a brand new global trend.”
  • β€œResponding to social trends means flexibility, and agile marketing doesn’t work with controlled and deliberately timed plans.”
  • β€œIt’s important to capture and engage with your audience at the right moment, which can’t always be planned for in advance, which is why an effective agile marketing strategy is key.”*

There’s a lot more roaming unchecked in the wilds of the internet, but my blood pressure is climbing to dangerous levels from re-reading these things.

So I’m going to stop here, because the theme of these excerpts is clear: agile is the opposite of planning.

I don’t usually like to shut down debate, but…

No.

That is wrong.

Agile marketing includes planning. Requires planning. Embraces planning.

Quite a lot of planning, actually.

Heck, there’s a meeting in Scrum actually called β€œSprint PLANNING.”

To be perfectly clear, Agile marketing requires a strategic vision, as well as short-, medium-, and long-term marketing plans.

Truth: Agile Marketers Plan

Agile marketing isn’t free form, on-the-fly marketing.

What those well-meaning authors that I quoted a few paragraphs ago are talking about is newsjacking, not Agile marketing.

Staying on top of emerging trends and inserting your brand into those conversations is great, and a nifty marketing tactic if you can pull it off, but it has nothing to do with managing your work from day-to-day in a truly Agile fashion.

Sure, we want our teams to be agile (note lowercase β€œa”), as in nimble, responsive, and adaptive, and running your marketing team using Agile principles sets you up to be all of those things.

But Agile marketing teams still execute against marketing strategies and quarterly plans. They just do so with an eye to making adjustments to those plans and strategies as needed, kind of like this

Myth #2: Agile Marketing is Just Scrum

Now, onto my next pet peeve in Agile marketing content: assuming that all Agile marketing teams will use Scrum.

My friends, Scrum IS NOT the only way to be Agile.

If you encounter an article that explains what Agile marketing is by referencing Sprint Planning, Sprints, or Scrum Masters as if they are non-negotiable components, that writer has made the all too common mistake of equating Agile with Scrum.

To be clear: I’m not a Scrum hater.

I’ve used it.

I like it.

I’m a certified Scrum Master and a Product Owner.

Scrum protects many marketing teams from capricious external interruptions and helps them work more effectively. But check out these results from a 2016 survey of over 800 marketers:

Scrum is the least popular methodology.

Not the winner.

Dead last.

Fewest number of people using it.

So please, don’t think that if you want to adopt Agile marketing that you have to do so using Scrum.

Truth: Marketers Take a Buffet Approach to Agile Methodologies

Agile marketing takes many, many, many forms.

The methodology you choose, be it Scrum, Kanban, Scrumban, or Lean, should reflect your team’s unique situation.

It’s likely that over time you’ll pull components from multiple methodologies to create your own personal hybrid methodology, but in order to do so you’ve got to understand what components are available in the first place.

And, not to be a downer or anything, but this process demands serious research and education.

You can’t go out, read a couple of articles with the phrase β€œagile marketing” in the title, and figure you’re good to go.

As the disheartening quotes from earlier made clear, not everybody writing about Agile marketing knows their stuff.

So instead of trying to eat the topic of Agile in one enormous bite, take a few smaller bites and digest them one by one. Investigate each methodology in turn, and choose the one that meets your current needs. Then be prepared to evolve it over time.

Agile Marketing is a Marathon

You may have noticed that I included the mention of a long-term application of your chosen Agile methodology in my definition a couple thousand words ago.

β€œGoing Agile” isn’t something you put on your to-do list this week, check off, and then move on from. It’s likely to take 2-3 months for you to start seeing real benefits from the transformation.

Even after those first few months, your team will continuously find new ways to improve their process. (If they don’t, it may be time to retain a third-party coach or trainer to help kick things back into gear.)

Having someone on the team dedicated to championing this ongoing improvement will help you avoid stagnation; it might be a certified Scrum Master, or it might be a servant-leader who also acts as a marketing manager or director.

There are development teams everywhere who have become complacent about their process, losing many of Agile’s benefits by just going through the motions week after week.

Don’t become those teams.

Improving Your Agile Marketing Process Over Time

β€œGoing Agile” sounds like a big step, and it can be tempting to think of it as an item on your to-do list. You check it off, and you’re done. But, for better or worse, it doesn’t work like that.

The Agile mindset calls for continuous refinement and improvement, meaning that there’s always something that could be a little bit better. This is one of many reasons why retrospective meetings are SO important β€” they systematize the practice of regularly reviewing your process and identifying opportunities for improvement.

Particularly on Kanban and Scrumban teams, everything about the way your team β€œdoes” Agile is up for debate. Maybe you want to try out a new team structure, or test a new tool, or simply adjust your WIP limits β€” any and all of those are ways to make Agile marketing work better for your team.

However, while you should be improving constantly, you don’t have to do it all at once. There are two complementary approaches, incremental and iterative improvement, and you may find one fits your team better. Or it may be a combination of both that does the trick. Like most components of Agile marketing, you won’t know for sure until you give it a try.

Iterative Improvement

Iteration involves revisiting the same item and making small adjustments. The classic example, courtesy of Jeff Patton here, is creating a painting like the Mona Lisa.

It starts with a vague sketch, an idea that you think might work. In the case of a new Agile marketing team, that might be your very first backlog. You get together with your stakeholders and put a basic first draft together, doing your best to create something viable, but not stressing about making it perfect.

As the team starts using the backlog to manage their work, they’ll identify things that work and things that need adjusting. You can see from sketch one to sketch two above that Ms. Lisa’s hand moves from her mouth to her lap β€” it’s a small change that makes a huge difference in the overall composition of the painting, and early changes can have a similar impact.

Each improvement may be small, but over time they add detail, functionality, and clarity to the end product.

Eventually you’ll find that each iteration brings smaller and smaller changes, and the results of those changes becomes increasingly less impactful. As that happens, you know that you’re nearing the end of this iterative cycle. Perhaps your backlog is as close to perfect as it needs to be, and you can work on another aspect of the process in your next iteration.

The above graph refers to taking an iterative approach to creating a product over time, but you can see how the same curve would apply to process improvement, or even a marketing campaign.

Your iterations don’t necessarily stop because something is perfect. They stop because improvements become so small that they only deliver tiny benefits. When that happens it’s time to consider your next increment.

Incremental Improvement

Improving your Agile marketing process using increments is less like creating a painting and more like doing a puzzle. As time goes on you add in additional components to produce a more complete process (or product or campaign or whatever).

If we’re using increments to adopt Agile marketing on our team, we might first create a backlog, then visualize our workflow, then add WIP limits, then start having retrospective meetings, and so on until we’ve eventually put all the pieces of our Agile process together.

The danger of an incremental approach is that it often assumes that you know what the final picture should look like.

In the Mona Lisa example above, the layout of the painting doesn’t change. We’re steadily expanding it over time, but we aren’t making adjustments as we go.

Keep this in mind when you’re deciding whether iterations or increments will serve you best. Iterations can help you explore and learn with minimal risk; increments will allow you to build steadily on that knowledge over time.

Beware Agile Marketing Myths

Iterations vs. increments. Kanban vs. Scrum. There are lots of choices for a new Agile marketing team to make, and most of them require serious reflection and discussion. Don’t blindly follow a checklist because it’s easy, or you risk creating new process problems instead of realizing the full potential of Agile.

Agile marketing offers benefits for the individual marketer who’s stressed out and overworked.

It can help marketing departments struggling to keep pace with their audience.

Bottom line: it’s practically the only way to effectively deal with the growing complexity of modern marketing.

Share this blog post:

Written by

Picture of Guest Author

Guest Author

Get updates for new posts