[Editor’s Note: This post was originally published on Oct, 12, 2017 but is such a fan favorite that we’re re-posting. Thanks to Andrea for sharing these amazing insights with us.]
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.
Before #Agile, only 16% of software projects were being completed on time & on budget. #Yikes via @AgileSherpas
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 other aspects of modern businesses could benefit from taking similar approaches to their work, and so Agile has begun to spread from software into other functions.
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.)
- 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.
Top brands across industries, from eCornell to Verizon are adopting the nimble and unstoppable approach of agile marketing. Rooted in the disruption-hungry world of software development, agile is a powerful tech industry legacy that has proven itself to be the perfect solution to today’s toughest marketing challenges.
- How do we keep up with customer expectations, which become more sophisticated with every smartphone upgrade and new social media trend?
- How can marketers compete in the vast and ever-expanding universe of online content?
- With today’s demand for multidimensional marketing campaigns, what in the world can we do to get a clear picture of ROI – and provide our worth to C-suite and clients?
- And, the top challenge of marketers today – how can we identify the optimal platforms to use to generate traffic and leads for a specific industry, niche, and brand?
The answer my friend, isn’t blowing in the wind. It’s swimming past you like a slippery fish. Agile is fluid, continuous, incredibly flexible – and not the easiest thing in the world to grasp. With an agile approach, you no longer have to climb over those seemingly insurmountable mountains of work. Now you can flow past them in order to reach your lead generation/ROI/brand loyalty building goals.
It’s about following the path of least resistance. This is better than the already beaten path, which comes with the very dangerous risk of diminishing returns, explains Ed Hewett, a former industry strategy and marketing team senior manager for Adobe. And, agile is about being quick and flexible enough to catch those shiny opportunities that pop up and disappear like bubbles foaming along our watery analogy.
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:
- Validated learning over opinions and conventions.
- Customer-focused collaboration over silos and hierarchy.
- Adaptive and iterative campaigns over Big Bang campaigns.
- The process of customer discovery over static prediction.
- Flexible vs. Rigid planning.
- Responding to change over following a plan.
- Many small experiments over a few large bets.
Tattoo this on the back of your hand. However you approach agile marketing, whatever methodology you use, it is important to understand the core concepts of agile. These are the principles of agile marketing – adopted from the original agile manifesto for software development.
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.
There are different ways to be agile. The one you’ve probably heard the most about already is Scrum. This is the dominant methodology in the software industry. A look at agile marketing in 2016 found that over in our neck of woods, the rigid structure of Scrum doesn’t always fit. Marketing professionals tend to prefer Lean, Kanban, and Scrumban, the other three primary methods.
I suggest Scrum for new agile teams who feel like they could use the structure, or for larger teams that need a framework to help them collaborate with management. If your marketing department is a four-person strong establishment or less and is already familiar with agile principles, Scrum may feel too restrictive.
Of course, being agile, you would dive in, try out each, evaluate the results, dump what doesn’t work, and move ahead with what does.
Scrum can, however, be a good place to start. Marcus Miller, Managing Director of UK-based SEO and digital marketing company Bowler Hat, has found Scrum to work well for improving the speed and quality of his team’s marketing campaigns.
Scrum, nor any of the methods for that matter, cannot be easily boiled down. It’s a process of continuous improvement that involves small groups of people working together in short bursts called ‘sprints.’ There is a lot of planning, but all the planning is flexible. Basically, your initial roadmap, or big picture plan, will evolve as you learn along the way.
Tools like burn charts and visual task boards, and even the Fibonacci sequence, are used to keep a sharp eye on what needs to be done, what is being worked on, and what’s completed. A big part of agile marketing are the daily meetings – preferably standing up, less than fifteen minutes, and everyone is expected to contribute. An even bigger part of agile is the measuring. Every project is, in a sense, another experiment to learn from in order to continually improve – ideally driving better and better results.
There’s a lot to Scrum, so you may want to brew a pot of coffee and put on your reading glasses. The Scrum Alliance is an excellent place to start. This is where you’ll find the official Scrum Guide as well as a thriving community of Scrum experts.
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.
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 visualization 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 visualization, 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.
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.
Start with One Project
Now, it’s time to get started. Start with one small project. Put together your Scrum team, get out your white board, and start sprinting. Starting small is important as you develop your team’s approach to agile. It also gives you the opportunity to see how the process works, make a few mistakes, and improve your group’s approach before presenting agile marketing to the rest of your team or your organization. The more success you have with agile, the easier it will be to convince others that transforming your agency culture is worth it.
Agile marketing guru Jim Ewel recommends introducing agile in increments rather than trying to do everything at once. So, you can try one or two aspects of Scrum – or Kanban, Lean, or Scrumban – and work with them for a few weeks. Then, as you become more agile, you can introduce more.
Stick with It
You can’t just get out a rule book and follow the instructions for agile marketing. This is a mindset, one that will likely require some mental and creative stretching. That means adopting agile marketing is a process, a never-ending one. Once you start, keep growing, learning, and expanding along the way.
Not everyone is using agile marketing. In fact, few have really adopted the methodology. According to the The State of Agile Marketing 2016 report, only 11% of content marketers reported using agile. The biggest reason marketing professionals haven’t taken the plunge is a simple lack of training or knowledge. There is indeed a learning curve to agile marketing – just as there was with SEO, social media, and video.
If you want to evolve your approach and discover why so many successful marketers are excited about agile, then start walking the path until you’ve immersed yourself in the method and truly understand what it can do. Once you see how much more effective it makes your marketing, you may find yourself shouting from the rooftops about amazing, game changing agile.
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…
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.
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.
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.
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.
The Choice is Yours
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.
A Glossary of Agile Marketing Terms
- Adaptability: the ability of a marketing team to pivot or adjust to changes in the market, feedback from their customers, the competitive landscape, and data from their own campaigns. The goal of adaptability is to avoid being trapped in a pre-established marketing plan even when it becomes clear that changes need to be made. A primary benefit of agile methodologies.
- Backlog: a list of user stories or projects that have not yet been worked on. See also “Sprint backlog” and “Product backlog.”
- Burndown chart: A visual chart showing daily progress of tasks during a sprint
- Business owners: A small group of stakeholders that has ultimate responsibility for the value delivered by a sprint. Their primary role is in sprint planning and review to help with prioritization.
- Chickens v. Pigs: Based on the joke that if a pig and a chicken were to open a restaurant together the pig would be committed, but the chicken would only be involved, this distinction refers to people who are directly responsible for completing stories within a sprint as opposed to those who observe but don’t contribute directly.
- Daily Standup: A short (15-minutes max) status meeting used to keep all Agile team members up to date on how work is progressing. Formats can vary depending on your methodology of choice, but typical updates include answers to the questions “What did you do yesterday? What do you plan to do today? Is there anything blocking your work?”
- “Done”: The team and product owner must determine what criteria need to be met in order for each project to be accepted as complete. These criteria are likely to change from sprint to sprint and project to project, but must be made explicit for all team members and stakeholders. Stories that don’t hit all these requirements won’t be considered “done” at the end of a sprint.
- Epic: An extremely large user story, goal or objective that needs to be tackled over multiple sprints and/or broken down into smaller, more manageable increments.
- Failing Fast: The idea that failure isn’t a negative outcome, it simply reveals a course of action that wasn’t optimal. Because most agile teams can roll out an experiment, evaluate the results, and react almost immediately, a “failure” is more like a lesson.
- Fans: Other employees that, while not players in the sprint, may have projects that are impacted by sprint objectives. They typically observe and do not participate in sprint planning or review. Sometimes referred to as “chickens.”
- Hypothesis: A possible source for a sprint task/objective, this is something your team wants to test and evaluate. E.g. By moving our introductory video so that it’s adjacent to our call to action we can improve the both video views and action completion rates.
- Iteration: A repeating instance or occurrence. Sprints are said to be iterative because they are repeated over and over with new tasks/goals/objectives. Waterfall marketing plans are not iterative because they are done only once.
- Kaizen: Mostly commonly used in Kanban or Scrumban, a Kaizen can take place at a pre-determined interval (e.g. after so many blog posts) and/or when a team member feels the need to examine some part of the agile process. It essentially translates to “continuous improvement,” or “change for the better.”
- Players: Those taking part in a sprint by owning particular tasks. Also known as “Pigs.”
- Product Backlog: A prioritized list of high level requirements for the product
- Product Owner: In Scrum, the person in charge of managing the product backlog by ensuring it’s accurately prioritized, reviewing the team members’ work, and otherwise working closely with the Scrum team to make sure the product is being best served by their efforts. The product owner can set tasks to be done, but the team choose how best to accomplish those tasks.
- Push-based v. Pull-based Systems: In a pull-based system, team members will grab items from a prioritized backlog.
- Scrumban: A hybrid of the Scrum and Kanban methodologies, Scrumban is typically a good option for Scrum teams who are looking to move past the need for ceremonial meetings. It can also be a better option for teams who are not co-located. It relies on a visible, shared board to track tasks, Work In Progress (WIP) limits, and the Kaizen review process.
- Scrum or stand up: A daily meeting during which players literally stand up and report to one another on what they did yesterday, what they plan to do today, and any obstacles they are encountering.
- Scrum master: The person responsible for running all sprint plannings, sprint reviews, sprint retrospectives and daily scrum meetings. Basically ensures that things stay on task during these meetings. Also responsible for helping remove impediments to progress brought up during daily scrum/stand ups.
- Sprint: The length of time allotted for achieving particular marketing goals. Software development sprints tend to run about 2 weeks; marketing sprints may need to be longer if statistically relevant data on current objectives will take longer to gather. Feel free to adjust the length of your marketing sprints based on what you’re trying to test/achieve for that particular sprint, but don’t go any longer than six weeks.
- Sprint Backlog: A prioritized list of tasks to be accomplished during the sprint
- Sprint planning meeting: A meeting held at the beginning of a sprint. Attended by players, business owners, scrum master and fans. During this meeting you should determine what you want to achieve during the sprint using the product backlog and dialog with the entire team to determine the time that work will take. This will form the sprint backlog.
- Sprint poker or planning poker: How the team estimates the relative effort required for addressing user stories in the backlog. It’s called “poker” because it is often done with playing cards. As each story/task comes up, players put cards face down in front of them to indicate their “vote” for how long it will take. Then everyone turns their cards over and comes to a consensus based on the results.
- Sprint retrospective: A meeting that happens at the end of a sprint to determine not whether tasks were completed but how the sprint as a whole went. Basically sets out to determine what went well and what could be improved for the next sprint. Typically attended by only the players and scrum master, though business owners may sometimes join.
- Sprint review: Business owners, players, scrum master and fans re-assemble just as in the sprint planning meeting, this time to see what goals were completed and which ones were not. Players get to show off what they have completed and/or learned, such as new email campaigns, blog posts, or metrics. Incomplete goals may be moved into the product backlog for consideration in future sprints.
- Success criteria: Criteria used to determine if a task is complete. Typically evaluated by a product owner. See also “Done.”
- Swarm: When tasks reach their WIP limit, a sprint is in danger of failing, or some other high-priority situation arises, agile team members may swarm a user story or task to get it done as quickly as possible. This typically works best in highly cross-functional teams that have similar skill sets.
- Timebox: A predetermined amount of time during which a set number of tasks will be completed. This can refer to the time allotted for a full sprint (typically measured in weeks) or for a meeting (hopefully measured in minutes).
- User story: A sentence that states in plain language what a customer or consumer may want or need from your product. They are used to drive what goals and tasks are addressed during a sprint based on their priorities. Example: As a digital marketer, I want to download a daily schedule so I can more effectively prioritize my tasks. To address this user story we might create a daily digital marketing schedule template and then place it, with appropriate calls to action, around our website and other channels (and then track results of course).
- Work in Progress (WIP) Limits: Typically used only in Kanban or Scrumban, WIP limits refer to a fixed number of cards/tasks that may be in a category at any one time. Your team may only be able to handle having four tasks in your “doing” column; before you can add another, one of those must be moved into the “completed” column. When a WIP limit is exceeded a team may swarm a card to get it moved to the next point in the process and make room for the next one.