Debunking 3 myths of agile marketing

Agile Marketing Cycle

Agile marketing continues to grow in popularity.

Why? The old “waterfall” approach to marketing planning and execution simply can’t keep pace with the speed at which prospects (and competitors) can move in the superconductive digital world.

In a Forrester report earlier this year, from which the graph below was excerpted, analyst Laura Ramos wrote, “The traditional annual planning routine is ripe for extinction, as 69% of our B2B marketing leaders say that conditions change too quickly to keep plans current. Accelerating the test, revise, and run cycle on campaigns can help marketing compare planned activity with actual results better.”

Why Agile Marketing Is Eclipsing Annual Planning

Agile marketing is ideally suited to addressing the challenges of rapidly shifting market conditions and “fast adaptation” of marketing campaigns. Based — sometimes loosely — on agile software development methodologies such as Scrum, agile marketing lets marketers run programs on shorter planning cycles. Days or weeks, instead of months or a year. This promotes a more iterative approach that can respond more quickly to market feedback.

However, agile marketing is itself a work-in-progress. Hundreds of different marketers are experimenting with their own variations of agile processes. After all, marketing is different than software engineering. So agile software development practices that have been well established over the past decade aren’t necessarily a cookbook recipe for marketing.

Agile marketing is more like chili — a catch-all label for a spicy, bean-based stew that has many diverse interpretations. Just like chili chefs, pioneering agile marketing managers often take great pride in their unique concoctions, tailored to their company and culture.

For the most part, I believe such experimentation — an evolutionary approach to learning which agile marketing methods work best in different kinds of organizations — is the right strategy for our industry at this point. It’s certainly compatible with the philosophy of agile that encourages adaptation within teams.

But in the absence of a well-defined and broadly-accepted agile marketing methodology, a number of misconceptions about the essence of agile management seem to perpetuate.

The following 3 myths of agile marketing seem to hold back a number of organizations from tapping the real power of agile, so let’s dispel them:

Myth #1: Agile is about doing things quick and dirty.

There are two allegations here: quick and dirty. Both are mistaken.

Agile isn’t about doing things “quickly,” at least not in the sense of individuals hurrying their work. In fact, the philosophy behind agile was inspired by the quest for a more sustainable, high-quality style of work — the antithesis of just rushing people to get more things done faster. It aims to prevent burnout, not induce it.

Instead, agile speeds up deliverables in three ways:

First, agile teams seek to minimize time spent on unnecessary overhead, such as excessive documentation, perfunctory meetings, or overly formal protocols between stakeholders. It’s about finding a high signal-to-noise ratio for the time that team members spend actually doing productive work.

Second, agile seeks to break big projects into smaller deliverables, each of which has value on its own or can be tested, either by internal review or with external market feedback. Ideally, this isn’t so much about breaking things into serialized components as much as it is refined or expanded iterations. So instead of having to wait three months for a big project to be delivered, smaller iterations of that project can be delivered within days or weeks.

It’s not really a higher velocity of work. It’s a more frequent rate for surfacing work.

This is the heart of what makes agile so powerful. By enabling earlier feedback, the project can course correct more fluidly to changes in the market. It can adapt based on people’s reactions. Maybe the smaller incarnation of the project is sufficient. Maybe it’s a dog, and the team would be better off doing something completely different. Agile gives you more options for such controlled, midstream corrections.

Third, agile seeks to eliminate interrupt-driven fire drills that sap productivity. When teams are constantly interrupted with urgent ad hoc requests — drop that, do this — the “switching costs” of losing momentum, shifting gears, and picking back up again, take a heavy toll on productivity.

Hey, change happens. But agile accommodates that reality by running short sprints — typically 2-4 weeks. At the end of each sprint, there’s an explicit opportunity to rearrange priorities for the next sprint. In exchange, the team is usually not interrupted while they’re in the middle of a sprint.

It’s a way of balancing both responsiveness and focus in a predictable fashion.

Agile isn’t about doing things “dirty” either, although there are two ways in which that misunderstanding arises.

First, sometimes the most productive way to illustrate an idea is to do a prototype, some kind of low-res incarnation, for internal demonstration and discussion purposes only. For example, web designers may mock up wireframes to show layout possibilities. However, no one would ever say, “Okay, let’s just go live with those wireframes and call it a day!”

Second, because agile encourages breaking big projects into smaller, iterative deliverables, some people assume that “smaller” is a euphemism for “lower quality.” But that doesn’t have to be the case — in fact, it shouldn’t be. In most scenarios, you can produce a smaller incarnation that is also high quality. Small doesn’t mean sloppy.

If you have a situation where anything less than the whole big project would be considered unshippable to the outside world, that’s fine. There’s no requirement that deliverables from an individual sprint have to ship. They can be reviewed internally, and then the next sprint can continue working towards the big finish line.

It is completely under the control of marketing management to decide when a particular iteration is “good enough” to be shared with the world.

Myth #2: Agile doesn’t enforce consistency in what’s produced.

Because agile seeks to minimize the amount of administrative overhead for team members producing work, there is sometimes a concern that it has no mechanisms by which to enforce consistency in what’s produced. The image people sometimes have is that team members simply grab tasks from the backlog and get them done however they want, without having to adhere to any standardized procedures or requirements.

This is not true, however.

For instance, in agile software development, teams often have very strict rules about how source control is managed, the processes by which integration and builds of the software happen, style guides for formatting of code, test procedures, and so on.

Generally, the goal is to put in place as much process and standardization as necessary to optimize net productivity. Having no standards might seem like greased lightening for a brief while, but it would quickly bog down the team in a Tower of Babel quagmire.

The same should be true for agile marketing. Processes for digital asset management, approval flows for deployment into the market, analytics for consistent reporting and review, enforcement of brand standards, etc., are all perfectly feasible — and usually desirable.

Brand Debt in Agile Marketing

This dovetails with the first myth. There must be agreement among marketing managers and the agile team for what is acceptable quality. Failure to achieve that — or cutting corners in the internal organization of what’s produced — results what I call brand debt (analogous to technical debt in agile software projects).

Often, this is framed as the decision for what “done” means when you say a particular sprint task is complete.

Sometimes the team and its managers will consciously take on a little debt in exchange for addressing something immediately. But such Faustian bargains should be made rarely and should be repaired as soon as possible. A company with too much brand debt will suffer in its internal efficiency and its external reputation.

Note, however, that one of the purposes of the retrospective portion of the sprint cycle — when the team reflects on how the sprint worked, separate from reviewing what was produced — is to give the team the opportunity to evolve these standardized processes. In other words, such processes are established and enforced, but they’re also open to being adjusted to keep pace with changes in the work and the team.

Myth #3: Agile doesn’t support a long-term vision.

Sometimes, when people hear about the sprint cycle — set a plan for 2-4 weeks, execute it, (ideally) get something into the market, and repeat — they envision that agile is purely a fly-by-the-seat-of-your-pants approach that lacks a larger defining vision or strategy.

It’s true that agile isn’t a strategy.

Instead, it is a framework for implementing strategy. But one that is well-suited to a world where external environmental factors — changes with customers or competitors — can create unexpected opportunities and threats to one’s established strategy in short order.

It’s important to recognize that sprints don’t happen in a vacuum. At the beginning of each sprint, marketing managers both contribute tasks to be done to the backlog and prioritize them relative to any other existing tasks. The choices for these ideas and their prioritization should absolutely be dictated by the company’s overall marketing strategy.

As I mentioned in an earlier post on strategic data vs. data theater, a good strategy is one that helps you make clear choices to achieve your goals. Deciding what tasks should be on the agile backlog and what relative priority they should have is a perfect example of such choices that should be made strategically.

Agile marketing is not the Wild West. The work that is being executed with agile methods can — and should — be done in pursuit of an overarching strategy.

The strategic benefit of agile, however, is that it promotes rapid feedback loops between the intended strategy and how it actually performs in the real world. By using an iterative approach, each sprint gives managers an opportunity to evaluate how their strategy is performing. That doesn’t mean that they should swerve at the first sign of incongruity between their strategic theory and its real-world results. But it gives them that information early and often. And that’s extremely valuable.

If a strategy is not performing as expected — perhaps an assumption was flawed or the circumstances in the market have shifted — agile marketing makes is easy for managers to adjust their strategy accordingly. Each new sprint provides an opportunity to try a new variation, even a small one, to tune into what resonates best with the company’s target audience. And if something really big changes in the market, the company also has the option of pivoting more rapidly.

In this way, agile marketing supports emergent strategy.

Personally, I think this adaptivity is one of agile marketing’s greatest strengths. But again, it’s an option, not a requirement. Managers can consciously choose to maintain the backlog on course with a yearlong or multi-year plan. Yet they can still reap the benefit of more tactical flexibility and fast feedback from its implementation.

What other myths of agile marketing have you heard?



  1. A very well stated piece. I’ve implemented approaches to Agile Marketing in two distinctly different environments, one a social media travel community, the other a regional financial services firm, both in the UK. You tackle the issues of myths very well. The reality in both of the environments in which I have worked has been a significant acceleration of marketing and an increase in performance against KPI’s – plus the teams tell me they enjoy their jobs much more.

    One size fits all is never going to be the way with agile – as it isn’t with older more formal processes. The social media community needed quick, near news production levels of delivery whilst the financial services environment needed more steps in what we might denote as rigour – the challenge was to get quite removed functions such as legal to appreciate their need to participate in a way that did not decelerate the sprints – particularly on the must-have’s.

    Evolutionary is critical and my own approach is to be incremental on process itself, initially running very short time-boxes to find the flaws, redundancies and absences quickly. A simple template that adds unforeseen critical elements in a decent timeframe.

Leave a Reply