This article has been updated to include the most recent data from our State of Agile Marketing Report.
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.
(Note: we also offer an online course introducing Agile marketing if you prefer to learn that way.)
Table of Contents:
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 try to create software that fit the specifications. Inevitably, it would take far longer for them to get it done than the project manager had estimated because the developers would uncover unknown dependencies and encounter unforeseen delays.
And also people are just really bad at accurately estimating how long things are going to take.
Things got so bad that 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:
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).
Every Agile marketing implementation will look a little different, but they share some 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.
An Agile team looks, works, and acts differently. If your team isn't clearly different following your adoption of Agile marketing, you may not have gone far enough down the Agile path.
Before proceeding to learn about the Agile Marketing Manifesto, why don't you take a second to get the most recent State of Agile Marketing Report?
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.
Frameworks, or the way we choose to DO Agile, may vary. But the values behind those frameworks, or the way we try to BE Agile, stay the same.
According to the manifesto, Agile marketers value:
The principles remain up for debate, but these are the candidates for guiding work on an Agile marketing team:
For more detail on what each value and principle means, check out this Slideshare:
Agile Marketing Values Explained from Andrea Fryrear
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 video:
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 complete in the next few weeks.
The meeting where the team figures all of this out is called Sprint Planning.
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. That said, planning poker has been found to reliably improve accuracy over time, so it’s worth a try.
Be honest about whether the time it takes is getting you the benefits you're after, and adjust accordingly. Just make sure you devote plenty of time to the experiment, i.e. at least a couple of months, because it can take teams quite a while to get good at experimentation.
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 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.
This meeting isn't useful if only the Scrum team attends, because they've been working together for weeks on these tasks and they don't need to show them to each other yet again. Make sure the team leads are getting the people who asked for that work into the Sprint review so they can actually use what's been created and give their feedback.
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.
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 (PO), 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 their name implies, the Scrum Master helps ensure the team is using Scrum in the best way possible. They facilitate meetings, help the team embrace the Agile mindset, and provide suggestions for process improvement.
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.
Also, there's no need to formally change someone's title to Product Owner. The important thing is that they (and the people they interact with) understand their duties as the PO.
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."
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 five to nine people. 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.
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 get work done.
Rather than a strict 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 new tasks as a way to postpone finishing tasks that are already in progress.
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.
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.
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 seven if you can, and definitely don't let them grow to more than ten. 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 ten 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 and how much people are working. 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 (or any high functioning Agile team for that matter), 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 non-stop 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.
A good rule of thumb is to look at how many people can work on each phase, and double that to set your initial WIP limit. So if we have three writers on the team, the "Writing" column would have a WIP limit of six.
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 over "nice to have" work, and emergency requests from the C-suite may have to put all other work on hold.
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 six, 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 six or less so that team members can always remember exactly how to handle various kinds of work that the team is asked to do.
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 sweet spot of five to nine people.
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.
This also means that Kanban is excellent for remote teams, because the board acts as a single source of information everyone can work off of. Instead of asking someone 7 time zones away and waiting all day for a response, the board and its cards should have everything you need to keep going.
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.
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 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
Despite being several 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:
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:
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.
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:
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 Product Owner.
Scrum protects many marketing teams from capricious external interruptions and helps them work more effectively. But check out these results from our most recent State of Agile Marketing Report:
Unlike software development, Agile marketing teams prefer a hybrid approach.
So please, don’t think that if you want to adopt Agile marketing that you have to do so using Scrum.
Agile marketing takes many, many, many forms.
As we saw above, our State of Agile Marketing Report reveals that hybrid approaches are far and away the most common for marketers. And what's more, those hybrid approaches are more likely to deliver some of the more powerful benefits of agility:
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.
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 two to three 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.
“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.
There’s so much marketers get wrong about Agile.
Iterations vs. increments. Kanban vs. Scrum. Cross-functional people vs. specialists. 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.
But unlocking the tremendous potential of Agile marketing starts with understanding how to apply its basic principles to your unique challenges.
To help marketers like you do just that, we’ve put together a library of content based on years of working with Agile marketing teams, and broken it down into 4 microlearning paths for different contexts:
Each of them contains 10 bite-sized lessons, 20 short engaging videos, and 10+ downloadable resources that can boost your Agile knowledge in minutes even during the busiest days.
Before you move on, don't forget to get the most recent State of Agile Marketing Report.