In-Ear Insights: Introduction to Agile Marketing

In this episode of In-Ear Insights, the Trust Insights podcast, Katie and Chris delve into the world of Agile methodology. You will gain a clear understanding of Agile principles and how they compare to traditional waterfall project management. Discover the benefits of Agile for marketing, including increased flexibility, customer-centricity, and the ability to adapt to changing needs. Finally, explore the challenges of implementing Agile, such as the need for discipline, planning, and stakeholder management.

Watch the video here:

https://youtu.be/_3IE7rkyxEc

Can’t see anything? Watch it on YouTube here.

Listen to the audio here:

https://traffic.libsyn.com/inearinsights/tipodcast-introduction-agile-marketing.mp3

Download the MP3 audio here.

[podcastsponsor]

Machine-Generated Transcript

What follows is an AI-generated transcript. The transcript may contain errors and is not a substitute for listening to the episode.

Christopher Penn 0:00

In this week’s In-Ear Insights, we’re starting the first of a four-part series on the use of agile techniques in marketing and generative AI.

So, this week, let’s talk about what the heck is agile.

You’ve heard this term, and you’ve probably heard this term badly misused.

So Katie, when people are talking about agile—agile methodology, agile marketing, agile development, etc.—what is this?

Katie Robbert 0:26

Agile methodology comes from software development.

In project management, there are two standard types of approaches you take to a project: one is called waterfall, the other is called agile.

Now, there are a bunch of other subcategories, but those are the main parent categories.

Waterfall is the most traditional and most highly used method of getting projects done, until agile came on the scene.

So waterfall—okay, so if you’re listening to this, we’re showing this on our screens, you can catch it on TrustInsights.ai/youtube—so waterfall is a step-wise process where you have to finish the first phase before you move on to the next one.

Therefore, it creates this idea of a staircase or waterfall, where you go from the top down.

So you do your requirements, you have to finish those completely before you move on to design, then you move on to design, you finish those completely, you sign off on everything, and so on and so forth.

The upside of waterfall is you know what to expect; you have all of your pieces together.

The downside of waterfall is if you want to make a change to something somewhere—if you want to change a design, your business goals have changed, whatever it is—you have to go back and start at the beginning.

Waterfall is really good for projects that are repeatable, the process is clear.

It’s used a lot in manufacturing, it’s used a lot in research, because those steps are not meant to be shortcutted or skipped over, everything needs to go in a certain order.

So that’s waterfall methodology.

Agile methodology borrows from waterfall, but the difference is that it’s meant to be more iterative.

So you still have to do all of your high-level requirements upfront, but where it starts to deviate from waterfall is that you then pick one subset of requirements, you say, “I want to focus on these three, they are the most high priority and most important, let’s start building those out and put everything else off to the side.” So you focus on those three, and you go through the design, implementation, development, testing for those three.

And while you’re doing those—so basically, as they start to move through the different phases, once the people responsible for doing the requirements for those have passed them off to design, then they can continue to move on to the other set of requirements.

So basically, you have a lot of things running in parallel, creating this iterative loop, where by the time you have something developed and ready to show, you can then go back and start working on the next set of things.

And you can say, “Okay, we did this small piece of the development, we’re not satisfied, so let’s refine those, let’s refine those requirements, and let’s do that one over again.” But you haven’t developed everything, so redoing things or tweaking things or fixing things isn’t that big of a cost.

Now, it’s the ideal state for a lot of companies; they want to feel like they’re agile and iterative and can make changes.

What’s not talked about enough is how much discipline and planning goes into actually being agile.

It’s one of those situations where, you know, the people who do it make it look so easy, because they’ve been doing it for a long time, or because they are so regimented.

And that’s the thing that a lot of people misunderstand about Agile, is actually how regimented it is.

It’s more strict than waterfall because in order to actually be agile, you have to follow the precise set of steps.

Christopher Penn 4:30

So in a cooking analogy, would it be fair to say that waterfall is like a prefix menu where you have the entire menu baked out, there’s no deviations, the customer can’t order anything different.

They just come in, they get their meal beginning to end, every course served exactly as is.

Whereas agile might be more like a short order cook line, it’s like, “Okay, this is going—oh, this is coming, move this around, the customer doesn’t want this,” and so on, where they’re having to make a lot of changes on the fly, and new orders keep coming in, and they are processing them sometimes one order at a time, but sometimes one order out of, “Well, this person just complained that this is undercooked,” etcetera.

Katie Robbert 5:08

Yes, with the caveat that in that example of the short order cook, they have all of the ingredients prepped ahead of time so that they can make those substitutions.

So with waterfall, you’re saying, you know, it’s a prefix menu, no substitutions, no changes, we prepare everything ahead of time, and we execute it exactly as we’ve outlined.

That’s a good analogy.

For the short order cook, in order for it to be agile, they have to also prep everything ahead of time.

So if someone’s going to want tomatoes, but somebody else is going to want red bell peppers, you have to have both of those things prepared ahead of time.

Because if you don’t, someone’s gonna come in and say, “I want red bell peppers,” and you’ll say, “Okay, great, I have to stop everything and go back and prepare those,” you are no longer in the agile, iterative cycle.

Those—you know, to get a little bit overly technical—agile includes sprint planning, and that’s your requirements.

So your sprint planning should happen at the end of the first week of a sprint.

So you do your sprint planning, you start your sprint—sprints are two weeks of development time, concentrated development time.

At the end of the first week, you hold a sprint planning meeting for the next sprint.

So you have this constant overlap.

And the goal at the end of a two-week sprint is to have something movable, something that people can look at and see as it relates back to the set of requirements.

And so you have this constant iterative loop, where if, at the end of two weeks, something’s not working, you then have to go back and see where it fits into the next set of sprints that you have upcoming.

So you are constantly planning.

For people who don’t like sitting in requirements gathering meetings, detailing things out, talking through goals, making sure they have every step of the process clearly defined, you’re not doing Agile, because that is what’s required in order for Agile to work properly.

Chris, I can see you’re chuckling and smiling, but unless you’re doing that, you’re not actually working agile, in an agile way, you’re working in a waterfall way.

Christopher Penn 7:20

Got it.

So how does this apply to marketing? I mean, we are, for example, sitting here recording some podcast episodes and things.

How would we take either of these methodologies and say, “Okay, I want to make a four-part podcast series,” what does waterfall look like versus what does agile look like within this context of marketing?

Katie Robbert 7:39

You can absolutely use agile in the context of marketing.

It’s really effective if you are doing things like ad campaigns, if you’re doing email marketing campaigns.

When I started working with you at the agency, I immediately recognized the need for some kind of a process, and because I had just come off of 10 years of managing Agile developers, it was what was fresh in my brain.

And so I borrowed a lot of the things from agile development and brought them to your team.

So we started doing daily stand-ups, we started looking at breaking down bigger projects into milestones and figuring out who was working on what.

And so it was a very loose-based agile, but a lot of the methodology approaches applied.

If you’re looking at something like recording a four-part podcast series, honestly, you don’t need agile for that.

That’s completely waterfall, because basically, you sit down and say, “Alright, what do we want to talk about? What are the topics? What are the key points that we have to hit in each episode? And then what is our outcome?” Our outcome is going to be four produced podcast episodes that we can schedule over the course of a few weeks, and then we do the thing.

If we were going to do it agile, then we would not have all of the requirements baked out, we would say, “Here’s our high-level goals, here are the four key topics that we want to talk about, but as we’re going through it, we need to have the ability to go back and make changes to prior episodes.” And when you’re recording podcasts, that is a really cumbersome process.

And so I would say, in this instance, agile is the wrong approach, waterfall is the correct approach.

However, if you’re talking about doing something like an ad campaign, this is where Agile is really good, and it actually helps marketers check in on things more frequently.

It’s the ability to make changes as you’re seeing things on the fly versus waiting until the end of a campaign to see how it performed.

Christopher Penn 9:54

Got it.

So would that—so would that be useful for something that’s continuous, for example, writing each week’s newsletter, where you literally are waiting to see what happened in the previous week to decide, “Okay, this is something worth discussing,” or “Something else happened that was even more important”?

Katie Robbert 10:11

Yeah, you could use that technique.

The way that you would approach it is you would have a lot of information already written out.

So again, you can’t skip the planning process and just say, “I’m going to do it in bits and pieces and call it agile.” In order to make it effective, I would have to say, “Alright, I’m going to use agile methodology to start writing the newsletter.” First, I have to have a larger version of the newsletter drafted out, even if it’s just an outline, and I have it in pieces.

As I’m waiting to see what’s happening in the market, I still have to have all of that information organized, I still have to have my goals outlined, I still have to know who the audience is, I still have to know roughly, “If this happens, here’s what I’m going to write.

If this happens, here’s how I’m going to write.” So there’s still a lot of planning that goes into being truly agile.

And again, I feel like I can’t emphasize this enough: Agile is harder than waterfall because you are constantly planning, you are constantly sitting down and thinking through the steps and documenting and refining.

And if you do not want to do that, Agile is not for you.

Christopher Penn 11:23

Got it? So what do you do when you have a stakeholder that says, “Oh, we’re now an agile marketing workshop,” you know, “That’s not where we are now, we’re totally agile,” and none of these practices are in place? How do you, as maybe a manager, maybe as a vendor, how do you bring that to life in a way that is truthful, even if your stakeholder is not aware of what the words mean? Suppose it were back in 2015, and I said, “Okay, we’re an agile marketing team now,” and you’re like, “Oh, God, you don’t even know what that means.”

Katie Robbert 11:59

It’s a good question because I feel like—and we’ve had similar conversations about, you know, “What’s our AI strategy?” and this—there are buzzwords.

The first thing I would do is say, “Okay, what is the goal of being agile? What is it that you want us to do? Or what do you want to see changed by becoming agile? Like, what is the purpose of being agile?” My sense is that they want to say, “So we can do things faster.

So we can produce more.” Okay, that may or may not be an agile problem, it may be a process problem, it may be a bandwidth problem, it may just be that there are, you know, people just aren’t doing the right things to help us reach the goal.

So there are a lot of different pieces that I personally would want to explore first before saying, “Okay, sure, I’m gonna put a bunch of Agile processes in place.” Because changing from where you are today to agile, if you are not an agile shop, is a culture shift.

It’s people operating in a different way than they are used to doing, and if they have never worked on an Agile team, it is a total 180, and it can be very jarring.

When I was working with our development team, it took us a couple of years of truly focusing and discipline and not deviating from the Agile process in order to get everybody comfortable and used to, “This is how it works.” And even then, what we found, because the nature of the company and the type of work that we were doing really lended itself to waterfall—they were trying to really just do Agile for whatever reason—we found that we had to make some accommodations and compromise.

So instead of two-week sprints, we started doing three-week sprints, sometimes they were four-week sprints, but we still kept the basic principles in place.

So we still had the daily stand-ups, we still had to do the sprint planning, we had to stay disciplined.

So to your question about, you know, if an executive comes to me and says, “Okay, we’re agile now,” I would try to take the word agile out of the conversation.

If they want to slap the label agile on it, that’s fine, but that’s not really the problem they’re trying to solve.

They’re trying to find efficiencies, they’re trying to do process development, they’re trying to understand, “Are people being used the way they should be used? Do we need to do a skills gap assessment?” Those are the types of things that you would want to start to do before introducing Agile methodology.

I guess, Chris, I want to—I’ve been doing all of the talking here.

What are your thoughts on what Agile is, as you know, because I’ve brought it to you, I brought it to your team, I brought it to this company, like, how do you see agile?

Christopher Penn 14:51

More than a thing, I see it as being something that allows you to pivot for customer needs.

If properly done, it makes you more customer-centric because with waterfall, you say, “Here’s the requirements, you gather the requirements,” and then, we all have customers who change their minds, like, “Oh, actually, no, I really wanted to do to do this instead.” Or they’ll say, “You know, I thought I wanted sentiment analysis, but I really want topic modeling.” If you have a waterfall environment that’s pure and strict, you say, “Well, great, I guess we’re starting this project over, so we’re going to bill you another $90,000,” and so on and so forth.

Whereas if you do operate in an agile fashion, you can say, “Okay, well, cool, we’re gonna switch algorithms, we’ll put that in the backlog, and then the next sprint cycle, we’re going to figure out how we swap those components out.” And it’s very possible that after that sprint, the customer says, “Oh, you know, actually, I liked the sentiment analysis, but I also want the topic modeling, like, we have both,” and you’re like, “Yes, I’ll go in the next sprint, uncomment the old code that we wrote because you can’t make up your mind.” But that allows you to be more customer-focused, you can say, “I am going to adopt this system so that when the customer’s mind changes repeatedly, we can adapt with it and meet their expectations without having to do that frustrating ‘throw it all out and start over again’ thing.”

Katie Robbert 16:22

What’s interesting is you skipped over the part where we’re doing any kind of planning or research.

In order for that to be effective—and you’re right there, we can borrow a lot from Agile methodology in marketing, in business, there are ways that we can be more iterative—however, in order for that to happen, we have to do that planning upfront.

We have to sit down with the client and say, “We need to know what data you have to work with, we need to know what shape that data is in,” so that’s all of the planning and design.

And so we can do that in pieces.

If they say, “Topic modeling is the most important thing,” we can, once we get a sense of the ecosystem, focus on just the pieces that are relevant to topic modeling.

But if we don’t do that planning upfront, and they say, “I want to switch to sentiment analysis,” then it’s no longer agile, because you don’t have that information to be able to switch to it.

So it’s not just about re-commenting your code in a sprint, you do have to go back to the beginning, and that’s where you become waterfall again.

Christopher Penn 17:26

The challenge is, particularly with a lot of customers—and this is especially true in artificial intelligence—people don’t know what they want.

What they do know—and this is something you talk about a lot—is they know they can react to what they don’t want.

They can say, “Okay, here’s—that’s what I had in mind.” “Okay, well, great, what did you have in mind?” So even with proper requirements gathering, until they have something tangible in front of them—a wireframe, an example—it’s very difficult for them to even articulate, “Yes, this is what I want.” This is one of the reasons why—and we’ll talk about this in subsequent episodes—one reason why prompt engineering is so difficult for people is because it’s difficult for them to articulate what they want.

Katie Robbert 18:09

This is where—and we haven’t talked about this—but this is where the idea of the backlog comes into play.

As you’re sitting down in your sprint planning meetings, the information you’re looking at is the backlog.

When you start to do your initial—if you’re starting fresh, if you’re starting with a new client, new project, blank slate—you start to list out all of the things, “I want this, here’s my top priorities, here’s my must-haves, my nice-to-haves, and then here are the things that I don’t want.” And so you start to prioritize, basically just a list of everything, and that becomes your backlog.

So if halfway through the project, your client comes to you and says, “You know what, I really want this,” then what you have is that list of backlog items to go back to and say, “Okay, so I have these five things that are must-haves, and you’re now telling me that this one thing over here is another must-have.

In order for us to meet the timeline, in order for us to stay within budget, which of these five things has to go? Which of them moves down the list to a nice-to-have?” And it gives that constant negotiation.

This is something that we ran into a lot at my old company with—I mean, I had literally 12 stakeholders in my ear at all times, not including the development team, not including the design team, not including marketing, not including the data team, not including the customers, 12 people who were put in charge to all have opinions.

And it was a constant negotiation of, “Okay, you said this over here, you said this over here, you third person are saying this, you fourth person are just coming out of the woodwork and saying something else.” We can’t do everything.

That’s one of the things that I do like about agile methodology is that you have a justification for saying no at that time, because you can show them, “Okay, if you want the button to be blue, and you over here want the text to be flashing and bright pink, but honestly, constantly flashing, those are two different features.

This feature is going to take five hours, this feature is going to take eight hours, we have 20 hours total to work with, so I can fit both of those things in, however, something that is, you know, equivalent to those 13 hours that that’s going to take has to go.

So what’s going to go?” And so it gives you the opportunity to have those conversations in a very concrete way that helps people say, “Oh, okay, that’s why you’re saying I can’t have this right now.” And so then it goes back into the backlog, and you say, “Great, so now we’re going to do this two weeks from now,” you can give them more of that concrete timeline, like, “We can’t do it now, but once this sprint is done, and we start working on the next one, it goes into the next one, because we have a new set of 20 hours to work with.”

Christopher Penn 21:07

That makes total sense.

And I like that because it allows the ownership, if you will, of what gets cut out to be pushed back onto the stakeholders.

Whether you get the stakeholders to agree, “Okay, yeah, we’re not going to do that,” unless you have completely unreasonable stakeholders like, “Oh, well, you could do it all, it all happens.”

Katie Robbert 21:25

If you think about those scenarios where you have competing stakeholders, it’s an opportunity to bring it to them and say, “You’re both asking for something, there are only so many hours available, so I need your help making this decision.

I need the two of you, or the three of you, or the 12 of you to come to some sort of a shared decision and let us know.

Otherwise, you know, we’re going to find other things on the backlog to get done while you’re making your decision, therefore making your thing fall further down the list.”

Christopher Penn 22:01

So to wrap up, if someone wants to become agile, what are the first steps that they, as a marketer, should be taking?

Katie Robbert 22:11

The first thing, honestly, is really understanding why you feel that Agile is the right solution.

What is it about agile that you think is going to give you a competitive advantage, you think is going to make you more efficient? There may be parts of agile that you can borrow, like, so we still do a daily standup every day, but it’s very informal, so I wouldn’t call us agile because of that.

But there may be things that you can borrow from agile, there may also be things that you can borrow from waterfall.

Basically, what it comes down to is being organized, having a plan, always having that direction, and having the ability to say, “Well, I’ve decided that I no longer want to do this thing, I’m going to do this thing over here.

What does that mean for the work that I’ve already done? What can I easily change out? What is it going to cost me? What does that mean for my resources and my stakeholders?” So to get started in Agile, first figure out why agile, why is that the methodology? And are you disciplined enough to truly follow it? Do you have the information? Do you have the resources? Because it’s not easy.

People make it look easy, and that’s the point, but behind the scenes, it’s not easy at all.

Christopher Penn 23:29

Alright.

Well, if you’ve got some thoughts about how you might want to adopt agile, or you might say, “It’s not for me,” and you want to share them, go over to our free Slack group, go to TrustInsights.ai/analyticsformarketers, where you have over 3,000 other marketers asking and answering each other’s questions every single day.

And wherever it is you watch or listen to the show, if there’s a channel you’d rather have it on instead, chances are we’re there.

Go to TrustInsights.ai/tipodcast where you can find all the listening and watching options.

And while you’re on the channel of your choice, please leave us a rating and a review.

It does help to share the show.

Thanks for tuning in, and we’ll talk to you next time.

Need help with your marketing AI and analytics?