This is part of chapter 24 of Louis Gudema’s Bullseye Marketing book, which is available on Amazon.

In this book, I’ve outlined a whole new approach to marketing that wouldn’t have made sense in the past when the Big Idea and big campaigns dominated marketing. Today we are much more focused on creating hundreds of small pieces of content – personalized emails, videos, blog posts, tweets, infographics, case studies, ROI calculators, website updates, and on and on. Then we need to continuously monitor this content and optimize these programs based on customer reactions, and be aware of – and possibly respond to — the moves that competitors are making. Often opportunities arise that we only have a few days or weeks to take advantage of.

We can’t afford to take weeks to create a master plan and months to execute it. We need to be more agile.

In 2012, taking inspiration from the agile software development movement, a group of marketers led by John Cass and Jim Ewel (who is interviewed below) came together for what they called SprintZero and created the Agile Marketing Manifesto[i]. It read:

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

It’s worth stopping for a few minutes and reading each of those seven points again. Then read them again and take some time to consider how each can impact how you do marketing.

It’s a manifesto that focuses on the customer– and feedback from them – at the center of marketing, data over opinion, a responsive and flexible attitude and practice, and experimentation.

Agile intends to lower the risk in projects by increasing the ability of the team to respond to changes in the market and project requirements, and by being closer to the customer.

Many marketing teams who adopt agile marketing report being more productive: they increase throughput, get campaigns to market faster, and improve their business results. Employees also report improved job satisfaction with the agile method. It’s perfectly suited for the Bullseye approach.

Agile marketing is a philosophy. Agile marketing practitioners have tended to adopt one of two methodologies for implementing it: Scrum or Kanban. Each method has certain practices and tools that I’ll describe below – the sprint, daily team stand-up meeting, and Kanban boards – but all of those are mutable. Or can be combined in unique ways. Just as all companies are different, each needs to find or develop the form of agile that works best for it.

Scrum

Agile software development inspired the agile marketing movement, and Scrum has been adopted from the software world, as well. Some product development teams were using Scrum in the mid-1980s. (The term “scrum” comes from rugby; it is a means of restarting play in which a large number of players join closely together to try to move the ball.)

A key organizing unit for Scrum is a series of 2-4 week sprints in which the team works to achieve specific goals and tasks by the end of the sprint. The length of the sprint cannot be changed once it starts, nor can tasks be added to the sprint.

At the start of the sprint, the team holds a sprint planning meeting to determine the goals and the tasks for each team member for that sprint and to get buy-in from the team.

The team usually chooses the tasks from a product backlog of user stories. A product owner creates these user stories for the team; Scrum teams typically have one product owner, and this role is not combined with the Scrum master (below).

These user stories are customer-centric and include the Actor, Action and Achievement, such as:

• As a [particular persona] I want to be able to [learn specific information] to [understand product differentiators].
• As a potential end-user, I want to see a software product demo to understand how the user interface compares to other software.
• As a car buyer interested in sustainability I want to learn the carbon footprint of this automobile.
• As a person planning a trip to Croatia, I want to find the best seafood restaurants

User stories also include context for the request and acceptance criteria for the task. Some criteria are objective – this landing page will increase leads by X%, or this blog post will get Y shares. Some criteria are more subjective.

The sprint planning meeting, and the entire sprint, is facilitated by a Scrum master. Unlike a traditional manager, though, the Scrum master is not ultimately responsible for the outcome of the sprint, the team is.

The Scrum master helps the team decide which product backlog items to undertake for the upcoming sprint and identify what tasks are necessary to complete them.

During the sprint, Scrum teams often start the day with 15-minute standing meetings. The three questions that each person answers in the daily standup are:

1. What did I do yesterday?
2. What will I do today?
3. Do I need help with anything that’s blocking me from accomplishing today’s tasks?

This keeps the team members focused on their goals for this sprint, and collaborating on how to achieve them.

At the end of each sprint, the team holds two meetings: the sprint review and retrospective.

In the sprint review, the completed work is presented to stakeholders, and the team and stakeholders review what they accomplished and discuss what should be worked on next.

In the sprint retrospective, the Scrum master and team review the last sprint and discuss how to improve their process going forward, and any changes in the process needed for the next sprint.

Wash, rinse and repeat.

Kanban

Kanban, which comes from the Japanese for “sign,” originated in manufacturing at Toyota in the late 1940s and has been applied to many other industries since then.

Right from the get-go, Kanban is different from Scrum in that it does not have the start-stop rhythm of 2-4 week sprints. Kanban is a continuous flow process, and when one item is completed the team member goes on to the next. Consequently, it also doesn’t have the sprint planning, review, and retrospective meetings that are central to Scrum.

As in Scrum, Kanban tasks can be created as user stories which are then put into the backlog on a Kanban board. Kanban boards are central to the method and are also used by some Scrum teams. (There are physical and software Kanban boards.)

The simplest Kanban board has three columns or lists:

• To do
• Doing
• Done

More complex boards may have far more lists representing the stages of a process, such as this one for blog posts:

• Conceive
• Research
• Write
• Edit
• Design
• Post, amplify and promote

Cards aren’t moved forward until they are considered as good as possible or, as would be said in manufacturing, error-free. In the blog post example, a writer would not move a post into editing unless they felt it was correct regarding content, spelling, and grammar – ready for publication.

And each list has a defined limit. For example, the editing list may only be able to accommodate four pieces at a time. If the list is already full, but another post is ready, it is not moved onto the edit list until one of those four already there is completed and moved on to design.

So Kanban is much less structured than Scrum, with fewer new roles and meetings. It is a process of continuous delivery, and the continuous improvement of an existing process. It may not be as radical of a change as Scrum is for most organizations.

These are short descriptions of two complex methodologies. Entire books have been written about each.

And teams don’t necessarily need to choose between Scrum and Kanban. They can choose the aspects of each that work best for them. The important thing is to create a process that adheres to those agile principles that works for you.

Agile isn’t necessarily applicable to everything. If you have a big product launch or website redesign, those may need more traditional “waterfall” or other planning approaches.

While agile may seem like a relatively simple process to implement with a small team, it actually affects relations throughout the company — such as with product managers and sales — who need to be involved in creating new user stories and reviewing marketing’s work product. There may be some hiccups in transition, as there are with any change, but in the long run agile can help create smoother, more productive and successful working relationships.