The Worst Way to Test Agile Marketing, and What to Do Instead

This article was originally published on CMSWire on June 9th, 2020.

As we square our shoulders and prepare to face the second half of this most turbulent of years, it’s no surprise that many marketing leaders are hoping to equip their teams with greater agility. Many decide to experiment with an Agile pilot to see how this approach would go for their teams.

Marketers who adapt Agile ways of working report faster campaign delivery, better alignment with organizational priorities, stronger responsiveness to incoming data and even happier teams. In case that wasn’t enough, our recent experience navigating the rockiest period in living memory has provided plenty of bumps and bruises to remind us why we need to be as adaptive as possible.

Real agility, however, can’t be bolted on top of the way we’ve always done things. It demands significant shifts from our traditional ways of doing marketing work. Such serious change can be overwhelming, and even downright dangerous, to undertake simultaneously across an entire marketing department.

And so we pilot. We test out agility in a small pocket of the marketing function to make sure that it’s actually going to help us before we transform every team.

It’s a sound concept, but here’s the problem: most marketing leaders utterly botch their pilots.

Taking a single project and “running it in Agile” is the absolute worst way to do an Agile pilot, but it’s the one most commonly used. Here’s why it never works, and what you need to do instead.

Why a Part-Time Agile Pilot Always Fails

To understand why you can’t be Agile part-time, let’s paint a picture of a fully functional Agile team in action over the course of two weeks:

Monday, 9:00 am: The team, their leader and internal stakeholders get together for sprint planning. They spend about two hours reviewing their backlog (prioritized to-do list) of work, agreeing on what they can commit to finishing in the next two weeks, breaking large projects into smaller tasks, and volunteering for the work they’ll handle during the sprint. After this meeting, everyone has a very clear picture of what’s going to happen over the next two weeks.

Tuesday, 8:45 am: The team gathers for their daily stand-up meeting. In this quick 15-minute huddle they update one another on their progress over the last 24 hours, share their game plan for the upcoming day, and put any problems before the team. They hold one another accountable for agreed-upon actions and support each other in tackling roadblocks. Their leader hears concerns and goes to address them as needed.

Stand-ups proceed each day for the sprint until two working weeks have passed. Then the team convenes for their two closing ceremonies: sprint review and the retrospective.

Friday, 2:00 pm: The sprint review, or demo, shows off what the team has accomplished during their sprint and how previously released work is performing. Other marketing teams come to see how they might benefit from the learnings of this team, stakeholders see the progress on their requested work, and the team gets the warm fuzzy feeling of having gotten a lot done in a short amount of time.

Friday, 3:30 pm: To close out their sprint, the team gets together to talk about their Agile process in a 60-minute retrospective. They chat about whether their standups are effective, how useful their tools are in visualizing the work and point out any issues they encountered with stakeholders, agencies, partners, etc. At the end of the retrospective, they’ve identified a handful of actions to make their next sprint work even better.

On Monday, the cycle starts again.

This system assumes these team members aren’t doing anything except working with their single Agile team on a shared to-do list of tasks. So the handful of planning and review meetings aren’t that time consuming because they only take a total of six or seven hours over the course of two weeks. But if each team member is on multiple Agile teams, that number quickly skyrockets.

Lack of Time, Lack of Focus

If an Agile team needs an average of 3.5 hours of someone’s time each week to run effectively, and I sit on five Agile projects, I’m now spending 17.5 hours in Agile meetings. This completely defeats a core purpose of Agile ways of working, which is to free people up to actually get work done.

Sitting on multiple project-based teams also robs people of the ability to focus on high-value activities. When they’re on one team with a single, common backlog they can see exactly what’s a top priority and tackle it. But if they have five teams to worry about, they have to navigate five different priority sets. And chances are each and every one of those project leads believes their project is the most important and pushes their members to work on that project right now.

Even if someone is part of the “Agile” pilot project, they’ll still be jumping around from project to project as they always have. The only difference is that one of those projects is making them go to a weird 15-minute meeting every morning. Just putting some Agile meetings around projects doesn’t magically improve productivity. It doesn’t align teams around a shared purpose, it doesn’t reduce the mental load on individuals, and doesn’t show the true power of Agile.

In a word, it fails.

Create Stable Persistent Teams Instead

So if projects won’t work, how do we test Agile marketing? The only way is to create teams the way they’re meant to function inside an Agile framework. This means each person is part of one team, with whom they work 100% of the time. That team works on multiple projects at the same time, but they prioritize work in one unified backlog.

If you’re thinking this sounds a lot harder than just picking a single project, you’re completely right. It’s WAY harder. But if you want an accurate test of the impact you’ll see from using Agile, this is the only way to get it.

It can sound daunting when we’re used to viewing everything through the project lens, but there’s a bit of a hack you can use to identify the work that could make it possible to pilot in this way.

A Simple Way to Hack Agile Pilots

Step 1: Get your marketing leadership together and list everything they’re planning to do in the next three to six months. This should be as comprehensive as you can make it, so collect everyone and devote a good solid hour to the process.

Step 2: Find the commonalities in your list. Does a lot of the work ladder up to a particular initiative or OKR? Is there a ton for one specific business unit? Will you be spending quite a bit of time and budget revising your event strategy? Look for a bucket that’s full enough to keep your pilot team of five to 10 busy 100% of their time for the next several months. This will become their team’s purpose.

Step 3: Review your options for team members, and be sure the majority of the candidates can be fully present on the Agile team. If you have one or two specialists who aren’t needed for the entire effort, they can jump in and out, but that should be the exception rather than the rule. If some of your pilot team members are currently attached to active projects that would pull them out of full dedication to the Agile team, either choose another team member or wait until their current work winds down to start the pilot.

Step 4: Formally launch the new Agile team by having them build their backlog of work together, write a working agreement, and generally mark the beginning of their new life as a cohesive unit. Turn them loose and watch the magic happen.

If at all possible, benchmark your organization’s key metrics pre-Agile and compare them to the results your Agile team puts out. These can be efficiency metrics like speed to market and rounds of review, or marketing metrics like MQLs generated per campaign. The point is to be able to actually measure the impact new ways of working could have if applied to the entire marketing function.

Dedicated Agile Pilots Always Win

Agile frameworks are built around dedicated, persistent teams that work together around a shared purpose. If you attempt to pilot Agile practices on part-time, project-based groups, you’ll end up with frustrated team members and very little (if any) improvement in your process.

Instead, find a shared purpose for your Agile pilot TEAM to work on. Compare their performance to the non-Agile work, and you’ll finally see what all the fuss is about.