Agile marketing sometimes means deciding what you’re not going to do

The following is a selection from the e-book “MarTech’s agile marketing for teams.” Please click the button below to download the full e-book.

The best agile marketing teams have bigger goals that allow them to work on the right work at the right time. In this chapter from “MarTech’s agile marketing for teams” e-book you will learn how you and your team can push back on requests that aren’t in alignment, allowing the most valuable work to get completed while building trust with your stakeholders.

Show the impacts to other work

When your team gets in the habit of committing to work in a sprint (a one or two-week time box), when new work gets requested, something else isn’t going to get done. Let’s dig into how we can respond to Jim’s request for the product sheet.

A good response here might be, “I see the urgency with your tradeshow happening, but the team is working on the direct mail postcards you asked for a few weeks ago and we’re right in the middle of them. If we stop to do the presentation, those won’t get done. If we continue, those can get mailed this week. Which one is more important to you?”

Dig deeper: Why collaboration and teamwork are essential in agile marketing

If the sales manager says the direct mail postcards, then you’ve proven that the new request wasn’t as urgent as he made it seem. If he says the product sheet, you’ve set realistic expectations that he can’t have both.

There’s definitely an impact to the team when they stop work they’ve already started, so it should be a team conversation as to how much this will impact them. In other words, change isn’t free. It comes with a price, and that price is time. Stopping and starting work is one of the biggest suckers of the team’s time. However, the trade-off conversation is a much better one than what typically happens—everyone just saying yes to any work requests.

Catch up on the Agile Marketing Navigator series!

• Aligning on a Guidepoint
• How to hold a successful Brainstorm session
• How to determine the minimally viable launch
• Creating a blueprint
• Building a Marketing Backlog
• The Daily Huddle
• Cycle Planning
• The Team Showcase
• Team Improvement
• Customer Stories
• Story Points
• Work in Progress Limits
• Cycle Time
• Waste Removal
• Partnering
• Teams
• Marketing Owner
• Agile Champion
• Supporting cast
• Practice Lead
• Stakeholders

Saying “no” to pet projects is necessary

Not all work that people want is good for your company or your customers. There are always way more good ideas than there are people to do them. An empowered product owner on your team should understand the goals of the business and recognize when requests come in that are “pet projects.”

Saying “no” is really difficult, but it gets much easier when there’s a shared understanding with leaders about what’s important.

Let’s say that a finance manager comes up to you, the product owner, and wants to know if you can do a social campaign about a new loan offering. A good response is, “Thanks for the suggestion Jenny, however, we have a big quarterly goal centered around another product. It’s just not the focus of our team right now.”

If you’re not in the product owner role, it’s really important that any request for work get in front of the product owner to evaluate how it stacks up against the big goals.

Building stakeholder trust

When the team gets better at either making trade-off decisions with work or saying no altogether, they’re better able to gain trust with their stakeholders.

I worked with a team at a large company that had a terrible reputation for never getting any work done on time. The stakeholders had really pegged them as a problem team and they had a bad reputation to overcome—but they did overcome it and became a role model team.

I came in as their coach and noticed that their product owner changed priorities for the team about every 45 seconds. They were stopping and starting so often that they couldn’t ever get any real work done.

To bring visibility to this problem, I started having them show a sprint burndown chart every morning at their Daily Scrum. This chart is a visual indicator to show what work was committed to when they did planning, when unplanned work got added and how close they were to getting all of their work done each sprint.

When work got added during the sprint, the orange line would go up rather than down. This opened up the product owner’s eyes to exactly how his constantly changing work requests was impacting the team’s ability to get anything done.

This really helped the product owner get better at managing stakeholders with “What aren’t
we going to do then?” “Not now” or “No.” And the truth was, the stakeholders respected those decisions because they were able to see how much better the team performed and how the work they were expecting got done on time more often than not.

So the horrible team became a high-performing team that was asked to be a role model to executives.