Should You Be Sprinting? 

Episode Transcript

Hello, and 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've traded chaos for clarity and never looked back. And because no Sherpa summits alone,

I'll be joined by trailblazing guests, coaches, practitioners, CMOs, and other experts, sharing the sharp tactics and hard won lessons that keep them on the leading edge.

So lace up those virtual hiking boots, limit your WIP, and let's start ascending. This is your weekly shot of practical, no fluff, Agile insight so you can deliver more value with less busy work and love your marketing again.

Hit follow wherever you listen, and let's carve the next switchback together. Hello, and welcome to this week's episode of The Agile Marketing Edge.

This week marks the first time I'm welcoming a guest into the studio, and we are all very lucky that it is the lovely and brilliant Monica Georgieff.

Monica has not only been on her own Agile marketing journey for over a decade, she has coached some of the most complex marketing teams that I have ever heard of.

So she's spent, also spent time running marketing for a Kanban specific project management tool, and really, there's nobody better to join us for a critical look at sprints and all of their alternatives.

So thanks for being here today, Monica. Thanks for having me. I'm excited. It's gonna be fun. All right.

So first, let's you and I talk about sprints, 'cause they're kind of the best known version, sort of the flavor that everybody's familiar with when they hear about Agile.

And how do they fit into marketing specifically, before we kind of get into what their alternatives are? So let's start with the basics.

What's a sprint? Why do we have them? What's their core purpose? Yeah. Sprints are extremely popular. I feel like after you learn the word Agile, you learn the word sprint, and the two sort of go hand in hand. To me, sprints are what provide like a fixed timeframe for, um, a project that you're gonna execute, or multiple projects, your planned work, and they usually are two to four weeks in duration. And what they allow teams to do is to manage their tasks in these smaller bite-sized pieces or, or chunks, and to allow them to stay focused on delivering specific outcomes within the scope of that, um, fixed sprint, and they're really great. I, I'm not against sprints, uh, in any regard. They're great if you want to incorporate this like regular inspection and adaptation, this cycle, um, and teams can really use them to learn from each iteration or each sprint and then continuously improve either their process or their product or whatever they're delivering.

And what they actually enable us to do is deliver value incrementally, which is such a big part of what Agile is, and these regular feedback loops I think are sometimes missing from the processes that teams take.

So being able to make those adjustments on the fly and learn from customers as you're developing something is, I believe, where sprints were born. And in marketing, when we might take six months historically to develop a campaign, this is a really powerful tool potentially for us to get into a, a nice habit of breaking down our work into smaller bits that can get into the market faster so we can learn more quickly. Yeah. They limit the overwhelm, if I'm honest. I've seen teams really take on these big complex projects and break them down into sprints and sort of take a, "Okay, now it looks like something we can actually do step by step."

Mm-hmm. Mm-hmm. And so it sounds like there's some cases where they work really well, and are there times when maybe they don't fit so nicely into the work that people are doing? Yeah. I've seen both. I've seen sprints be like the savior of the project, and I've also seen them sometimes be just something that we're trying to fit to work that doesn't necessarily break down in that way. So as I said, they're really helpful for complex projects that have changing requirements where every two to four weeks we're able to sort of incorporate the novelty or new customer feedback that's coming in so that rapid feedback and, and iteration loop can keep going, and that can really enhance the final deliverable that we put out there in front of customers.

They're great for fixed scope as well. So if you have a project where you can afford to iterate every two to four weeks instead of every two to four days, and this is the caveat here, um, then you can really focus on that period of active work that is the sprint, um, and iterate that way. But if you need to react immediately, and this is a big but, and I think for marketing that's often the case, where you do need to react in the moment and you can't really wait two to four weeks to make an adjustment, then in those cases, I find that trying to fit your work to the sprint becomes more of a burden than an advantage.

And in addition to that, I think that sprints are really effective when there's a culture of collaboration and communication that's really strong already. Otherwise, teams sometimes might struggle to work in that way because the sprint is not for you alone, right? It's, it's for you and your team and the work that you're sharing.

Right, and I think that's an important nuance about sprints that we should underline here. The goal of a sprint is to commit as a team to a, to a clear and defined amount of work for the set time box. So, in the next two to four weeks, we as a team will accomplish this agreed-upon amount of work, with the goal of releasing it into the world in order to provide some really solid value, right? So that's what we're doing and that's why we are doing it, and we shouldn't be doing anything else. And so if we can't- Exactly. ... commit and we can't confidently say, "This is all we're going to be doing for the next two to four weeks," sprints can become difficult to manage because we've got all this new stuff coming in, stuff gets overlooked and, and we don't meet our commitments. And so that's an important maybe, uh, if that doesn't sound like you, then you may struggle to, to manage your sprint appropriately. Yeah, absolutely. That moment of commitment I, I think gets lost sometimes when teams say that, "You know, we're doing sprints but we don't really commit."

Um, if you look at the original version of, like, scrum and sprints being a big part of that, um, that moment of commitment is really emphasized, and there's tons of work that doesn't really cater to that, that moment of, you know, locking in a certain amount of scope for two to four weeks, which is actually a really long time if you think about it. Um, especially if you've got multiple projects, multiple stakeholders, there's a lot that can change within that period, and the chances of you meeting your commitment, a lot of the time that might not be possible.

So then why are you doing sprints anyway? Okay, so very important for us to think critically before just jumping into, "Yes, sprints are good. Let's do sprints." Think about the kind of work that you do and whether or not this is really gonna jive with that, 'cause they're very powerful but not necessarily for everybody.

So, as I said before, Monica's spent a lot of time coaching a lot of teams. So, Monica, maybe if you have some, uh, some juicy stories for us, like times you said you've heard sprints save the day and save the project.

Maybe some times it didn't, uh, didn't go so well? Juicy. Hmm. So I, I don't know how juicy these stories are, but, um, I have seen sprints work really well and I have seen them sort of crash and burn, um, in both cases.

So, the, the time that, uh, they worked really well, I remember a website launch, um, which can be really overwhelming because you've got a lot of different stakeholders involved. You've got marketing team, uh, with a lot of accountability for the new website and what it's gonna look like. And so in that case, sprints really did allow the team to sort of rapidly iterate on their strategies based on real-time analytics and audience feedback, and ultimately it did end up increasing the conversion rates of the website which was ultimately the goal in, in putting out a new website in the first place. And I remember that the first sprint, the inaugural sprint if you will, um, it took a small piece of the website, like a landing page, put it in front of customers, got some feedback in the moment, and then that influenced the next iteration and so on and so on.

And so breaking that huge project that was very complex into chunks, and understanding that you cannot put out new website pages or a new website every couple of days, you sort of had to batch the work that you were doing for a particular page, do the layout, the design, the copy, put it out there in front of customers and then incorporate that feedback, I think gave the team a lot of structure and removed a lot of the chaos that could have ensued in a project like that. And then the crash and burn. Um, so you mentioned that I worked in a kanban environment before with a process management tool vendor that was focused on kanban. So we did, um, have a lot of arguments against sprints at the time, and one of the examples was, for example, a customer support environment. That's a very typical case in which you have to react immediately, and your success sort of hinges on you being able to, um, react in the moment instead of committing to something that you had no visibility over, and then two to four weeks later, depending on your, your sprint cadence, having to react. I mean, you were, you were already late to the game, right? You missed the opportunity entirely. So if you're in that sort of environment, even if it's not a customer support environment per se but, like, a shared service team that is reacting to requests that are coming in daily, um, you may not be very well-suited to, to a sprint cadence. And so teams that tried to fit that work into a sprint ended up missing a lot of opportunities as a result. To me- Yeah.

... a failure. Yeah, I've, I've seen specifically, um, creative teams really struggle with the sprint time box because they, they do tend to support a lot of other teams and need to be responsive in a meaningful- Yeah. ... way, and when people say, "Really, really need this graphic from you within the next few days," and, and to say to those people, "I just started a sprint and I can't possibly do that for you-" Yeah. "... until the next sprint starts-" Or- "... in four weeks," is just not a, a reasonable thing to say. Same thing with, like, PR or comms teams, right? There's this major breaking news event, but we're in the middle of a sprint and we just can't...... can't react to it right now. It's just not... it's an insane thing to say to somebody.

Yeah. So, just some, some instances where it might not be the right, the right approach. But, in the show notes, we will share a deep dive article on Scrum, which includes more detail on what sprints are like and how to run them if you wanna go deep and learn more about the mechanics of these, because they are useful in a lot of cases. Uh, and so if you wanna get really granular on those, we'll give you some more resources on that. Uh, but now let's kind of turn our attention maybe to the most popular alternative, which is  Kanban.

So, Monica, can you start with maybe like a 30,000-foot view of, of what is Kanban, and, and why is it a thing? Yeah. Kanban is sort of like the story of the underdog, but if I'm honest, it's actually older than Scrum. So, it was first on the scene, if we're looking at, uh, lean and Agile frameworks, it's one of the oldest lean and Agile frameworks for embodying this, this way of work and this methodology in general. And it's focused on managing workflow by visualizing tasks, sometimes on a physical board or a digital board and a process management tool, in order to highlight what's being worked on and where the bottlenecks in the process might be, and to really optimize the flow of value through the existing process of a, a team or a department using work in progress limits, um, which is a, a key component in Kanban that I feel like often gets missed, that Kanban, capital K Kanban, is not just the Kanban board that people might have seen. It's also, um, being able to limit the amount of work that you are not just starting but also, right, finishing. Focus on that. And it comes from, uh, the factories of Toyota, which is why I say it's the story of the underdog, 'cause Toyota in the 1940s was a very, um, you know, niche car manufacturer. And, uh, they introduced Kanban on the factory floor so that they could really monitor their process and find efficiencies so that they could maximize the value that they were creating with the resources that they had.

So, Kanban's focus is much more on efficiency and eliminating wasteful activities in the process than it is iterative working, which is much more Scrum. All right.

So I think two things you said there that I, I feel like we really need to double-click on. Uh, one is work in progress limits, or WIP limits, right?

Mm-hmm. Which we, we call out in the intro to this show. So definitely a thing that I, I love and think is super valuable. So let's, let's explore that for sure, and then one of my favorite phrases in, in the whole universe of Agile, which is the stop starting, start finishing, which also comes from kind of the Kanban tradition.

So, maybe take us through, through both of those a little bit more, 'cause I think they are at the heart of, of why Kanban is such a powerful framework, uh, especially in a marketing context. Yeah. Yeah, absolutely. So the two are related, right? Work in progress limits are exactly as they sound. They try and put a limit on the amount of work that you are keeping in progress, and maximize the amount of work that you're actually passing through the process to the finish line, which is resulting in value for your customers. So work in progress limits, the way that they function is sometimes on the individual level or the team level, even more powerful, you're saying that you only wanna have a maximum of, let's say, 10 items in progress at a certain amount of time. If you don't have that, what ends up happening is you accrue sort of a, a queue of hundreds of started work items that are not doing anything for you in front of customers because they're not released yet. So you've put all this resource, all this time, effort, money, into that work and it's only half done, and it's just sitting there. So it's not creating anything, um, for the people that you're trying to serve. And so what Kanban aims to do is maximize the amount of work you're actually able to put out there in front of customers by keeping the amount of work that you're context switching between and trying to finish up very small, so that you can actually focus on five or six items at a time as a team, and then release them, and only then start on new stuff. And I, I'm totally with you. This is what attracted me to Kanban as well, 'cause I've been in the situation where you've got 100 things started and nothing is finished and everyone is frustrated.

The work in progress limit is strict. It's hard to keep, but it's very helpful if you're able to do that on the team level and actually focus your efforts. Ooh, that was thunder.

That's amazing. That's amazingly loud if it, if it's coming through on the, on the podcast. That's good, it's good, uh, ambience for us.

Um, so I wanna, I wanna, um, explore this just a little bit more in case people aren't familiar with the concept. So, um, if we have it as a team, right? So let's say it's 10. Our WIP limit as a team is 10, and we've got 10. Uh, between our team of five, uh, we have 10 things that we are working on. We have hit the ceiling. We've hit our WIP limit, and somebody comes to us and says, "I really need you to start this task right now, and that would be number 11 and would put us over our WIP limit." What are we supposed to do? So there's two things that you could do. You could finish something maybe that's closest to the finish line and pull that out of your in-progress queue, which leaves you with nine, right, in the example you were giving, and so that's fine. You can bring something new in because you're not working in a sprint.

So you can actually react to something new that's coming in if you've got that free spot. But if you don't, then you can say, right, "Once I finish something, stakeholder, I will come back to you and then we can pull this in." Or maybe you can, if you've just...... push something into your In Progress column and you've just hit 10. You could say, "Okay, maybe I won't start this today, as I was planning.

Maybe we can do a trade-off and I can push that back to the backlog or the unstarted column of your board," and then do a trade-off, and actually prioritize or reprioritize something new that's come in. So, that's a benefit of Kanbans, that you can actually react just in time, instead of having to wait for the next moment where you're able to commit every two to four weeks, if you're working in sprints.

So, there's, yeah, there's negotiation when it comes to this, and when you have a work in progress limit, you're sort of asking yourself, or forcing yourself, to have these conversations, because your capacity is not unlimited, and admitting that is, is key. Right. And that's, you know, if you wanna learn more about backlogs and prioritization, we have an episode on that, so you could go back and listen to that episode.

But this is how we guard our capacity. We don't just immediately say yes to everything, even in a just-in-time, more responsive system like Kanban, we use WIP limits to manage priorities and to keep from having a million open tasks that just never make it over the finish line. And so this gets us into the stop starting/start finishing mode, right? Because if we start everything the minute that it shows up in our inbox, then we get into that situation where tons and tons of stuff are, are active and nothing seems to ever get done, and sadly, this is where a lot of marketers live right now.

We have huge numbers of open to-dos, and we just, we're not lazy, we're not not working, right? We're working too much, but our attention is spread over too many things. Wow. And it's hard to break that cycle, and so you used the, the phrase earlier, context switching, and that's really the root cause of all of this. So, maybe unpack that for us a little bit. Like, how do we break the context switching cycle and, and stop starting and start finishing? Yeah, context switching is like the plague of our generation. No, not just our generation. It's a big problem, um, for all teams, I think, not just marketing teams, but...

Statistically, if you are context switching, you are losing time and productivity between that, switching between those two things. So, you end up losing some of your capacity, your time, which is your most precious resource, uh, when you do that, because you're, you need to acclimatize, right, to this new thing that you're just starting, and that takes a lot of time. So, it's unproductive time in some ways, and statistically, if you're switching between maybe one or two things, you have a higher chance of completing those two things effectively, at a high quality, because you're able to focus and really get in that flow of work.

And then, if you're switching between, right, 10, 20, 50 things, depending on the size of your team, and Agile tells us, right, five, six team members is a, an average team size. So, if you've got 50 things going on in that size, you're, you're really not gonna be able to be your most effective self, your, your most effective professional, your specialist, um, if you're doing that.

So, the WIP limit, what it does is it discourages you from context switching just by creating that ceiling, that maximum that we didn't have before, and it changes the way that you think, the way that you approach work. You start to think, "Oh,  I'm starting something new today. Could I finish something that I already started instead of starting something new and then pick that up?" Yeah, I could.

Or if I don't have anything going on right now, but there's already 10 things happening within my team, maybe I can help somebody else to deliver their item and free up a spot in that queue so that then I can start something new. So, in that way, you're avoiding creating this long queue of things that you're trying to make your brain switch between and really not doing a great job of it. 'Cause I, I learned from you, Andrea, that only, what, 2% of the world are able to multitask between things, like truly separate the two parts of your brain and focus on two things at a time, and that's probably not us.

So, we need to put some guard rails in place in order to, to be our best selves at work. Yeah, it's 2% of the population. We all secretly think that we're in that 2%. There's a test you can take. We'll put it in the show notes in case you wanna prove to yourself that it's not you, 'cause it's not you. We can't, uh, we can't do it. They call them supertaskers now- Fantastic. ... because, uh, that's so rare. So, it's probably not you. Just deal with it. Um, and yes, like you said, Monica, at the team level, WIP limits are amazing, but even if you're not on an Agile team yet, personal Kanban is such a powerful alternative, and it's a great way to manage your own personal work, and I have a personal board that I've used for years and years, and I just, I love it. My husband and I have one. It's an enormously powerful way...

I know we have someone on our team that managed her whole wedding that way, people have managed renovations this way. It's a, just a great way to keep yourself on track, whether you're doing it with a team or doing it on your own. WIP limits are super powerful. Um, we'll have tons of resources about all of this in the show notes. Um, likewise, we have an episode on small teams. So, lots of places to keep, keep exploring all of these topics, because there's a lot to, to learn here. So, let's continue the, the framework aspect of this. So, we have, uh, Scrum or Sprints as one alternative, and then we've talked about Kanban and its components.

Is this a permanent choice? Do we have to pick a camp and stay there forever and be Team Kanban or Team Scrum and get the T-shirt and get the tattoo and, and never, never pick the other side? I mean, the internet will make you think that that's what you need to do . Um, there's so much content out there that's like, "Kanban versus Scrum. What is the best choice?"

And I think it's a very personal choice depending on the type of work you're doing, depending on how, the team members you have, and their dynamic. It's all these things that need to come together. But no, you don't have to choose one and just stick with it because your circumstances are changing, so you need to be flexible to that as well.

You can... There's one thing you can do. You can take a hybrid approach, and a lot of teams in marketing have been doing this, picking some elements of Scrum and some elements of Kanban and putting them together, and they called it, yes, you guessed it, Scrumban because it's a combo of the two.

And some implementations are more leaning into Kanban, others lean into Scrum. But again, it's that idea and even having that at the back of your mind that you can choose elements from each framework and package them in such a way that's more reflective of the type of work you're doing and the structure that you have, uh, so you get best of both worlds. And for certain projects, that makes total sense. Um, there's also something that I've seen in the past, teams transitioning between Scrum and Kanban depending on the different types of projects that they're getting. So their demands are, the demands on the team are gonna be different, and if it's something that's more like social media scheduling or something that's more continuous and you need to react to in the moment, then you're probably gonna be a Kanban team while you're taking on that type of work. But then for some reason, right, a big project hits your backlog, something that is complex, your team is tasked to focus on that, you can break that down into sprints and operate as a Scrum team for the duration of that, that large initiative, for example. So I've seen that worked really well, and different project stages as well. I mean, there's, there's a lot you can do, and if you're open to learning about both frameworks, you're in a really good position to tailor a, a system that really works for you instead of trying to take everything by the book and say, "You know, in order to be Agile, we need to practice Scrum by the book or Kanban by the book."

Um, there's a lot more flexibility there, and especially for marketing teams, this is, um, key. I think it's, it's something that allowed us to take Agile to the next level, that idea that we could hybridize, we could switch between. Yeah, and I think this is a really powerful thing that, that non-products development groups like marketing have to bring to the conversation, right? Like, "We don't necessarily have a dog in this fight. We just want to do our work better."

Yeah. "We don't have a historical allegiance to a framework. We can be pragmatic and say, 'This works for us. This combination works for us right now. This different combination will work for us in a different context.'"

And so maybe we can help break this sort of cycle of zealotry that, that the larger Agile community has, has gotten maybe stuck in a little bit over the last several years. And, and I, you know, would love your, your take on this, but I think that's really important for marketers especially, right, not to get caught up in, "Are we doing this right?" but, "Is this working for us?" Yeah, as long as you're keeping the focus on the value that you wanna deliver and the objectives that you've got as a team, you don't need to defend a particular methodology just because there's, you know, a turf war, I think you called it .

But, um, that encouragement of continuous learning and flexibility and recognizing that there are different frameworks that suit different circumstances allow you to be adaptable, a- and therefore allow you to be more Agile as a result, too, in your processes. So to me, being Agile is almost, like, synonymous with being open to different interpretations of frameworks that are out there that might have worked perfectly for software development, but if you're coming for a di- from a different function, if you're coming from a different reality, then that might not be the exact way that you interpret, um, Agile ways of working. Exactly. All right, so here at Agile Sherpas, and on this podcast often, uh, we talk about the what, who, and how of Agile marketing, so would love your take on... We visualize that, right, as sort of a three-part Venn diagram. And where do you think frameworks like Kanban and Scrum fall in that what, who, and how?

Yeah, I, I mean, they ought to fall into all three probably 'cause that's what, we've been talking about here, talking about the what, like, what type of work are you' doing, what are your objectives, who, what's the dynamic with your team, and, and then how. I think they, they do fall very neatly into that how category, um, because in a, uh, in essence, Scrum and Kanban are frameworks that allow us to bring Agile to life in our teams. And so it's not just, uh, a methodology or a set of values and principles. It's how we embody those values and principles in our day-to-day. So in that sense, they are, they are wonderful, but I, I think they need to be more than that. So beyond the frameworks, I think especially marketing needs to have a broader perspective. So we're integrating technology. We have customer insights to think about. We have creative strategy. It's not just operational efficiency. It's not just the how, or at least the how should reflect the what and the who, right, in the back. of our minds.

So taking a more holistic approach, uh, and allowing the how to be informed by the what and, and the who, um, to me are, are critical. So if you're wanting to not just practice a framework but build a more robust work management system, if you will, you need to consider all the factors, what's cultural, what's strategic, the technology, all these different dimensions, um, alongside specific Agile frameworks and how you can pull elements from them, uh, in order to operate effectively on the day-to-day with your team members. Amazing. Well, Monica, thank you so very much for spending time with me today and for sharing your wealth of experience and expertise with our listeners. If people wanna get in touch with you or follow you somewhere, where might they find you? They can find me on LinkedIn for sure, Monica Georgieff, and, uh, y- they can also send me a note, monica.georgieff@agilesherpas.com. Fantastic. Uh, thank you again for your time, and until next time everyone, remember, the struggle is real but so is Agile marketing.