Scaling Agile Marketing the Smart Way

Episode Transcript

When it comes to scaling our ways of working, where's the flexibility sweet spot? If we go too rigid, we risk boxing people in and becoming the framework police. Far too much time and energy gets wasted on worrying about whether we're doing things right, instead of focusing on doing the right things. Of course, it's easy to go too far the other way, too.

If we let everybody just do their own thing, then it's impossible to collaborate. If we don't have any shared rhythms or systems, then nobody knows when or how or where' to even communicate. We end up wasting all this time and energy just trying to figure out how to move work forward. So where's the Goldilocks zone between these two extremes? In today's episode, we will try to find it using some new thinking from  Scaled Agile as the lens in our magnifying glass as we search for clues.

So, grab your Sherlock Holmes cap. It's time to go sleuthing for the perfect blend of rigor and flexibility as we scale.

Welcome to The Agile Marketing Edge, the first podcast dedicated to turning Agile theory into real-world marketing breakthroughs. I'm Andrea Fryrear, CEO of Agile Sherpas and your guide on this climb to smarter, faster, outcome-driven marketing. Every week, we unpack the what, who, and how behind Agile marketing, from building high-velocity workflows and slashing waste to measuring what really matters and scaling success across teams. You'll hear quick hit strategies you can deploy today, plus candid stories from marketers who have traded chaos for clarity and never looked back. Hit follow wherever you listen, and let's carve the next switchback together.

In a lot of Agile marketing transformations, there's a front-runner, a team that leads the way. They try out practices, they adopt tools, they test out frameworks first, and some of the things that they try work, and other ones are total duds. They get tossed out faster than that slimy spinach that is in the back of your fridge and you forgot about. Over time then, other Agile teams come online who weren't around for those tests and trials and they wanna see for themselves whether that tool was worthy of the trash pile or if that practice was really as slimy and gross as they heard that it was, and maybe they decide they actually like some of the things that the pilot team rejected. As more and more teams adopt Agile ways of working over time, this adoption/rejection dance happens more and more. Sometimes there's so much difference in what certain teams accept and reject that we end up at the point where the word ile has lost all shared meaning. It's completely unrecognizable from one team to another.

If you spend some time working with one Agile team and then you move and try to go work with another Agile team, you can't even understand how to work with one versus the other because there's just so little overlap in the way that they work. In the worst cases I've seen, teams don't even share tools or metrics.

You might have one Agile team using Wrike and sizing their stories using Fibonacci, and then you've got another one in  Jira and they're sizing using dog breeds.

I am not making this up. I have seen this happen. But then, of course, we have the other end of the spectrum which can get just as absurd. I have actually seen a Scrum Master meeting devolve into an argument about which marketing team was doing Agile the most right, complete with quoting sections of the Scrum guide to one another. There was no concern about whether the adaptations being used were maybe generating better outcomes, there was no curiosity about why the adjustments had been made in the first place. There was just blind fixation on enforcing what everybody perceived to be the rules, and I was sitting there kind of listening to all this happen and they actually asked me to weigh in on who was right, in this debate, and they got really disappointed when I told them, "Nobody's right because none of your teams are even delivering any work." So clearly, in both of these extreme cases, nobody has found the flexibility balance that we need and it's hard to get there, but this is a really important topic for marketers in particular because we are already customizing Agile from the word go.

So we have to be careful not to get crazy with it' or we're gonna risk losing all of the discipline and rigor that makes Agile so powerful. So this isn't easy to do but it' is absolutely worth the hard work that it takes to get it right because when we do get there, we have data from our State of Agile Marketing report that shows that it-... delivers much better outcomes. So we have found that when all marketing teams are aligned around these shared ways of working, they are 16 percentage points more likely to effectively contribute to the organization's long-term success. They are 14 points more likely to feel very confident that their teams can contribute, or excuse me, can take advantage of emerging opportunities. And they are 15 percentage points more likely to feel able to handle fast-paced work. Anybody, anybody got fast-paced work out there?

Yeah, there's a lot of that going around. And in one team that we worked with on' their transformation, when they had their pilot team, only their pilot team online, they saw a 4.5% increase in their projects being completed month over mo- over month. But after the full rollout to the whole marketing organization, that number jumped to 34.9%, so big increase. Same thing when we track the decrease in the number of days that it took to complete a project. When we only had the pilot online, that number went down 5.4%, so pretty good, but after the full rollout, it went down 20%. But the only reason that we were able to get those kinds of numbers is because there was a shared, basic, essential foundation of ways of working across all the teams. Not every single tiny component was identical, but the crucial components were aligned. So scaling, very much worth it, and scaling doesn't have to mean 100 teams. Scaling can mean two, three, five teams and getting consistency across those teams is very much worth it. But finding that sweet spot between flexible frameworks and disciplined delivery can be tough, but it is not impossible. There are five things that we have to do to bring it within reach.

First, we have to make sure that we have a baseline configuration to work from before we start layering in customization. Two, we have to agree on use cases when customization is okay. It is not always on the table. There are only certain places where customization is allowed. Three, we have to document the ways that we will try out a customization. Four, we will roll out and monitor each customization carefully. We will treat them as a hypothesis with a desired outcome and with metrics. They are not just a willy-nilly thing that we are going to try.

And five, we will change our baseline configuration as needed over time if certain customizations turn out to be valuable enough to be rolled out to all the teams. And now I want to give a quick hat tip to Scaled Agile's customization approach, which they rolled out in September at their summit, and which really helped kind of crystallize and clarify my thinking around this. So we'll put a link to their approach in the show notes, uh, which really, like I said, helped me clarify. We've been doing things like this at Agile Sherpas for years, but this was a really nice way to put some real clarity around it. So thanks to them for the way that they have been approaching this.

All right. So starting with our first point of the five here. We need a baseline first. Before we can customize, we have to configure and people need to understand the difference between these two, because a configuration should be standardized, it should be documented, and ideally, this should be driven by experienced Agile practitioners because there are so many common mistakes that you're gonna make your first time.

And so just avoid those. Just get somebody who knows what they're doing in to help you. Just ask somebody for help who has done this before and then you'll avoid these common mistakes. There's no point in making the same mistakes that everybody has made before. Just avoid them. Ask for help. Ask Agile Sherpas for help. Ask an internal Agile coach for help. Ask the internet for help.

Just ask someone for help. You don't need to make the same mistakes over and over and over again. And you do also need to make sure that the configurations are clearly communicated to all the teams who are going to be working in them so that they understand what a configuration is and what's available for customization. And so things that should be part of the configuration that are set and not up for customization are things like, what is a team and how is it going to be set up? Which roles are full-time and which can be fractional? How are we going to plan and at what cadence?What is the mechanism that we are using to document our goals and objectives, and what are the mission critical tools and systems, that need to be standardized across teams? All of these are part of the configuration and none of them are customizations.

Customizations are when new stuff gets added or when these baseline things get modified. Now, if any of this is happening, there needs to be a really good reason and a clearly documented experiment period to figure out whether that customization was viable or not. And especially if it's a core part of the configuration, there needs to be like a really, really good reason for it.

Which brings us to our next piece here of making sure that everybody understands when it's okay to customize and when it's not.

Because it's not just all things all the time are open to customization. It can't just be that somebody doesn't like or believe the results of a previous experiment.

So I'm gonna give you three kind of common useful categories that can help you guide people toward areas that are often useful for a customization. All of them start with A. So the first is augment.

So the original configuration might turn out to have been missing something that you want to try adding on, and this is really common because early on you want to keep things simple. You don't want to over-complicate an initial Agile rollout, and so you probably left some things out, which is fine. And so we want to then augment. In a lot of the Agile marketing teams that I've supported, things like estimation are not always part of the first round of Agile teams that get rolled out, but that's a really valuable component, a really valuable practice that might want to be an augmentation for later teams or a later addition to a configuration.

Same thing for a larger scale planning cadence like big room planning or PI planning where multiple teams come together to align strategically and to share resources and things like that. That might be an augmentation to the original core configuration that is very much worthwhile going forward.

Second, we might want an adaptation where we change a practice or maybe a role to suit a unique situation that a new team is encountering, and especially in marketing when we have different teams that have new functional purposes or have a different focus area this can happen. So for instance, early teams may not have a dedicated Agile support role, not a dedicated marketing owner or not a dedicated scrum master or Agile lead, but a new team might decide they really need that dedicated role, particularly a shared service like a creative service team benefits a lot of times from a dedicated marketing owner role who can liaise with other teams and focus on ensuring that the backlog is constantly prioritized with the most important work. That can be a new adaptation to roles that might not be currently in the core configuration. That's based on the new context of a new team that's come online, totally valid customization.

And our last A is to advance, potentially advance the configuration. So we might be bringing in new, more advanced practices that are gonna allow the Aile marketing implementation to grow its impact. So maybe we are bringing sales into our PI planning, or maybe we're trying to bring more interconnectedness to our visualizations, our boards that we use. Maybe they are currently isolated and we want to try and make them more aligned and more interconnected so that we can have rolled up data and shared metrics across teams. These are more advanced practices that we might want to add in as the implementation scales, as more teams come online. These are all really great opportunities for customization, all up for grabs, all great moments, and good reasons to potentially customize. As we start identifying places for customization, we do need to make sure we are focusing what we are doing. And so as you will recall, no doubt, the Agile marketing operating system has nine components and potentially any and all of them could be an area where you are going to implement some kind of customization, but just like with anything that we are doing in an Agile system, we're going to want to limit our work in progress.

We don't want to try customizations across all nine at the same time in every team, so we want to have a good level of rigor that we are applying.... regardless of which component we might be tackling for customization at any given time. So, really get down and think about why are we customizing in the first place? What outcome are we expecting to see after we make this adjustment?

Ideally, we would wanna tie it to one of the As that we talked about above, right? So like augmentation, adaptation, and advancement. Maybe this is something that has surfaced during a recent retrospective, that people are citing as an issue, or an opportunity, or a challenge, or maybe just a hypothesis that we want to test. All these are fine, but we need to put really clear definition around the proposed changes. Which aspect of which of our nine components of the operating system is going to be adjusted? We want to be as specific as possible. And then we wanna determine, does the proposed change really require a customization of the operating system, or the core configuration itself, or might there be a lighter weight, more MVP approach to getting at the outcome that we want?

Is it really a core system change, or is there another way to get there? Because changing the core system is a big deal. Customization should be treated with respect 'cause it's not a small thing. So if there's another way to get at what we want, we should try that first. Right? If you recall earlier episodes where we talked about theory of constraints, we always wanna try the focusing steps that disrupt the system the least, we wanna try those first. Those same principles apply here. We wanna try things that are less disruptive first. We also wanna ask ourselves, "Are the changes that we're proposing being proposed because they are the right thing to do, or are these an excuse to maintain the status quo?

Or might they be a way to avoid a painful but necessary evolution of our ways of working?" We will, as humans, bend over backwards to avoid painful change a lot of the time. So we need to be honest with ourselves about why we're looking for customization. Is it really what we need to do, or are we just trying to avoid change? And we also need to remember that the customizations have the potential to affect the whole system. Once we have Agile implemented across many teams, a change in one part of the system could have ripple effects. So we do need to think about what impacts this might have broadly before we start rolling things out. All right. Once it's time to implement some of these customizations, no team can just run off and do these things willy-nilly in a vacuum. We have to treat each customization like a proper test-and-learn experimental cycle. So, is there an MVP? That is always our first question.

Where is the smallest amount of change that we could try to validate or invalidate a hypothesis quickly and safely? Could the change be rolled out to a single team, to a handful of roles, against a single project or campaign? Where could we try this with the least amount of risk and disruption? We need the MVP wherever we can find it. And we, we need to tell people what's going on. It's amazing how often people just go and try things, and nobody knows that this was being tried. This needs to be communicated.

Agile leaders and team leaders need to tell other teams what is happening, because maybe somebody has tried this elsewhere and knows whether it worked or didn't work there. They might be able to give guidance that gives a better chance of success.

Go back a couple of episodes and listen to my conversation with Elizabeth Venter Botha about change management if you need some guidance on how to communicate. here, because comms is critical around these kinds of change. And then as things go along, you also wanna communicate, "Are we seeing the results we expected?" Make sure that you are measuring the impact of your experiment against your expected outcomes. And then whenever possible, you wanna build a two-way door here. So, a two-way door means that you can walk back out of it if you need to, right? A one-way door means it's closed behind you and you can't get back out.

So if you can get a two-way door going here, that is your best case scenario, because sometimes the answer to your question of, "Will this make our work better" is gonna be, "No." And that's okay. Or we should at least design the experiment so that it's okay if the answer is no, because if the answer is no, we need to roll it back. Only if the answer is yes will we roll that change out broadly and make it permanent.

So we need to be prepared to walk things back if the test turns out to be unsuccessful. So be prepared for that.But our last, fifth step here' is to potentially adjust the core configuration if our customization is actually, according to the data that we have collected, a successful change. If it's really good, we should roll it out across more teams, because we want to maintain consistency across teams wherever possible.

The caveat to this would be if the change was implemented because of the unique context of a particular team, it may not be applicable to every other team; and in that case, you don't need to change the core configuration. But in the case where it is a broadly applicable change, make sure that you go back to step two and communicate what happened. What were the outcomes, how do we measure it, and then what's gonna change about the core configuration as a result?

Which part, which of the nine parts of the Agile marketing operating system did we test? How did we measure it? What did we see? What do we expect to see as we roll this out more broadly? Keep your communications going. This is an ongoing process, and if there's going to be future follow-up experiments as a result of what you learned in this round, talk about that as well. Maybe this is a phased roll-out and not a unilateral one. That should be part of the communication also. All right, so there's your five steps. This is how we get to the right balance of rigor and flexibility so that we can have a configuration that allows us to work together, but still makes room for the customizations that we need to make sure that Agile feels like it matches our unique context. 'Cause when we balance this rigor with an openness to experimentation, then we get the flexibility that we need to scale Agile marketing broadly. And it takes vigilance and commitment, but it is absolutely worth it so that we can get everybody in the whole marketing function working in lockstep and see the benefits that we're looking for across the entire marketing function.

If you think that you are ready to scale your Agile marketing ways of working, whether that is inside of a SAFe organization, an organization using the Scaled Agile Framework, or elsewhere, Agile Sherpas is standing by to help you do that in the right combination of flexibility and rigor. Visit us at agilesherpas.com/contact-us to complete an interest form, and one of our experts will reach out to schedule a discovery call.

Until next time, I'm your host, Andrea Fryrear. Remember, the struggle is real, but so is Agile marketing.