As a marketer, you’ve surely heard about Agile. Your team may be using some Agile practices, like project sprints and stand-up meetings. If so, you’re in the minority. The benefits of Agile are still largely untapped by marketing teams. According to a new report by Workfront and MarketingProfs, only 30% of marketing teams use an Agile approach to manage their processes. The other 70% probably experience the same frustrations my team experienced before we committed to making Agile work.
Our seven-person marketing team at Emplify has been practicing Agile for almost a year. It took us six months to get to a point of practicing it well: producing work better, faster, and with more energy and engagement.
When we started practicing Agile, we made a lot of mistakes. So many mistakes, in fact, that we locked half of our team in a conference room one day and didn’t leave until we had identified and addressed some significant shortcomings in our approach. Fortunately, there was beer and it was a Friday. Still, it was painful, and it took time to dig ourselves out of some deep process-oriented holes.
In this article, I share those mistakes so that you can avoid a painful lock-in like ours. Agile can revolutionize your marketing team’s ability to collaborate and deliver work faster – if you commit to making the process work for you.
Before we get started, let’s cover a few basics:
What are Agile practices?
Agile practices (often referred to as “Agile”) emphasize continual delivery of smaller portions of work over projects with larger interconnected tasks that may span weeks or months (which is traditionally called waterfall-style management).
Agile basics include:
- Scrum team: This highly collaborative team, organized under a scrum master, solves complex problems and delivers solutions in fixed-length iterations called sprints, which can last anywhere from one week to 30 days. A scrum team working on content, for example, might begin a two-week sprint committing to creating a new infographic or data sheet.
- Minimum viable product (MVP): When planning a deliverable, Agile principles emphasize getting the project out in the wild as quickly as possible so that your team can respond early to real problems. To achieve a model of continual delivery, scrum masters encourage teams to define the MVP and to figure out the most creative ways to finish the product within the confines of the sprint. For example, if you start a two-week sprint to create an e-book as your MVP, and your designer gets sick, you may decide to redefine that sprint’s MVP as a series of blog posts and design the e-book in the next sprint.
- Daily stand-up meeting: Team members stand in a circle for 15 minutes or so every morning to discuss the scrum team’s accomplished tasks, focus areas, and blockers that may hinder them from finishing their assigned sprint work. At the end of the sprint, Agile teams deliver a defined set of projects, which are then assessed and improved upon in the next sprint. Some scrum teams also incorporate retrospective meetings, where they discuss process shortcomings that can be addressed in the next sprint.
Why should marketers use Agile ?
National Public Radio uses Agile methodologies to create and test new programming. Think about that during your next “driveway moment.” Although Agile’s roots are in IT management, this form of project delivery can be applied to many functions of a business, including marketing.
Adopting an Agile model of continuous iteration allows your marketing team to quickly test new messaging or campaigns, react faster to product updates, and set expectations with stakeholders who request work from your team.
My team’s shining moment came almost nine months after we began our Agile journey, when we refreshed the content on our website to make some shifts in our product messaging. We defined what we could accomplish in one week, and we delivered that work on schedule. The content that we didn’t have time to update in that sprint, we hid from the navigation. We have been continually adding to and refreshing the messaging on those pages during our subsequent sprints.
What mistakes should be avoided?
If you’re considering adopting Agile on your team, even if you’re looking simply to streamline processes within your marketing team, you’ll want to avoid these four Agile marketing mistakes that our team made:
- We called ourselves Agile without doing our homework.
- We failed to designate problem owners.
- We focused on deliverables rather than on problems.
- We crammed instead of prioritizing (and pretended we could get it all done).
Mistake 1: We called ourselves Agile without doing our homework
When I started with my marketing team, I quickly instituted daily stand-ups to provide a quick, painless way to check in on projects. I figured that I had conducted stand-ups and organized sprints in former roles, so I had experience with Agile, right? Wrong.
Don’t come into work one Monday and announce that you’re “going Agile” as I did. Just because you’re doing work in two-week sprints and having daily stand-ups doesn’t mean you’re an Agile team. The beauty of Agile is that it gives your team the power to commit to projects together and to define a quality deliverable within a designated scope of time. If you’re just trying to cram as much work into two weeks as possible and sacrificing quality to get across the finish line, that beauty is negated.
Before instituting Agile processes on your marketing team, do your homework. Crack open a book or two. I recommend starting with Scrum by Jeff Sutherland (known to many as one of the fathers of Agile) and Hacking Marketing by Scott Brinker. Also, read some of CMI’s excellent articles on Agile marketing.
After you’ve done your homework, prioritize a few simple changes to your existing process to begin crafting an Agile approach that will work for your team.
Mistake 2: We failed to designate problem owners
If the following scenario hasn’t happened, you can skip this section; you have achieved some form of marketing-process nirvana that I have yet to discover.
The rest of you, picture this: You’re 98% through a major team project with a clear deadline, and a surprise stakeholder steps in at the final hour with dozens of revisions. Then, your team is forced to prolong the project an extra two weeks to address those changes because no one can argue that this stakeholder is wrong.
Still reading? I thought so.
Our team’s lack of defined ownership was the biggest hindrance to our progress as an Agile marketing department. We were overwhelmed by work. We were frustrated when multiple stakeholders weighed in on project quality. And we were not getting anything out the door because of last-minute edits and fixes.
If your marketing team is anything like ours was, you struggle to know who the ultimate owner of a project is. Who is the person directly responsible for the success of a deliverable? Who sets measurable outcomes for a task that the team can align with? Who needs this project to be successful so he or she can ultimately be successful too?
To prevent last-minute rework, we now assign such a person – a problem owner – to every project.
Every quarter, we set a sales-qualified lead goal for each of our main marketing channels: advertising, events, organic website leads, and so on. Then, each one of those channels is assigned an owner on our team, and that owner becomes the go-to person for any deliverables that fall under that channel.
Problem ownership has been particularly successful for our team for several reasons:
- It places the onus of success on one person, who is held accountable if goals are not met.
- It forces the channel owner to surface problems early so the team can proactively address them.
- It allows the entire team to be involved with brainstorming a solution and implementing a fix.
- It empowers one person to guide the quality of any given project.
If your team is not clear on who has the final say in your content projects, sit down with your department and ask one bafflingly simple yet challenging question: “Who owns what?” Answering that question – and recording your answers for all to see – will create immeasurable accountability.
Mistake 3: We focused on deliverables rather than on problems
Another game-changing moment for our Agile team was when we stopped looking at our work as a set of deliverables to crank out and started thinking about our work as a set of problems to solve.
Think about the individual contributors on your team: developers, copywriters, designers, and other similar implementation roles. How often are they asked to “design this slide” or “write this e-book” with little context for why they’re doing it?
Simply assigning a task on a to-do list without helping your team understand the real purpose behind the project leads to lackluster work without personal investment from your team.
In fact, having a lack of purpose-oriented work can have severe implications on more than just your marketing tactics. In a survey of LinkedIn members, more than 60% of respondents who were not in purpose-oriented jobs planned to leave their company in three years or less.
On our team, we have a strong rule against starting any project with a prescribed deliverable in mind. Let’s face it, stakeholders don’t always know what they want. Problem-solving helps foster collaboration for better outcomes.
Instead, we start every project with a problem statement, which follows a format regularly called user stories in the development Agile world. That format looks something like this:
When __________ happens, I want to ________, so that we get this measurable outcome: ___________.
Here’s an example of this type of problem statement (or user story) from a hypothetical project:
Each project’s problem owner determines which problems the team will tackle for that project. For example, the owner might consider it a problem if the website is not ranking for a certain keyword or if messaging needs to be updated for an upcoming trade show. No matter the problem, the problem statement never includes a solution. After we decide to prioritize a particular problem, our team analyzes the problem together, ultimately scoping a solution that we can execute within our next sprint.
Solving a problem as a team allows everyone to have a stake in the outcome.
Additionally, this approach forces the team to uncover pain points behind the surface-level problem to arrive at a solution that addresses core needs rather than vanity requests.
For example, our sales team reported that some prospects were not showing up to their scheduled demo meetings and weren’t responding to reschedule requests. Our vice president of sales wanted the marketing team to create an animated explainer video that would better prime prospects for their meeting, even though doing so would have taken months.
After asking some questions about the sales process, we realized that the sales team’s core problems could be solved with improved email messaging prior to the demo meeting. We instituted a three-email drip campaign triggered as soon as a meeting is scheduled. This solution took the team only two days to build. Since building this campaign, we’ve reduced the number of people needing to reschedule meetings by more than half.
Before assigning a task to a team member, ask yourselves why that work matters. By creating a problem statement and collaborating on a solution, we were able to identify a quick fix that has paid dividends for our team. If we had created an animated video, the sales team could have been dealing with the same issue for months while waiting for our fix.
Mistake 4: We crammed instead of prioritizing (and pretended we could get it all done)
If you try to fit as much as possible into each Agile marketing sprint, as we did, you’re doing it wrong.
Without a shared sense of priority, you have no idea where to focus your time. And without focus, you resort to saying yes to everything. And when you say yes to everything and don’t have problem owners for your projects, you find yourself in the thick of a stressful quarter with a lot of half-finished deliverables.
Many Agile teams use estimation to prioritize work and increase velocity as a team. They approximate the amount of effort a project will require or discuss how many hours it may take for individuals to complete their tasks. Over time, many Agile teams arrive at a sense of average output per sprint, which helps them plan new tasks.
In our early months as an Agile team, we set out to do this kind of estimating. Unfortunately, we ended up manipulating our estimates to make it appear that we could get everything done. We guessed at how much work a project would take, and then we haggled down the requirements to make room for three other requests. In the end, we negated the value of estimating work, perpetuating an environment of relentless stress.
We tried two or three methods of tracking velocity (including planning poker, a common way of estimating work). We focused on using estimating as a way to prove that we could get lots of work done, not as a way to become a more efficient team. THAT was our mistake.
I recently had a chat with our company’s director of engineering who manages the Agile process for our product team. When I mentioned that our team had never mastered estimation, he said this:
If your stakeholders are constantly asking for velocity reports or improved estimations from your team, you are likely experiencing bigger process issues that are impairing your team’s ability to deliver work to them on time.
When your well-functioning Agile team is regularly delivering quick iterations of a project and flagging concerns to stakeholders when a deadline is unreasonable, you naturally avoid questions about output or productivity on your team. The project manager or scrum master has a responsibility to course correct and communicate those changes when work is falling behind.
Don’t be afraid to prioritize just one or two new projects (or problems or stories) in your next sprint because you have a few leftover projects in your current sprint. Just be sure to communicate that leftover work in a timely manner to the stakeholder and share your plans to finish the project as quickly as possible.
And don’t be afraid to designate one leader to make the ultimate call on what needs to be prioritized. Our team, for example, banned all people from moving Trello cards to the “priority” sprint column except our vice president of marketing. That placed the responsibility to prioritize on the person with the greatest view of the entire business.
Our team, like every Agile team, is adapting Agile principles in ways that work for us. Whatever Agile approach your team may take, it will work only if you provide opportunities for open feedback on the process and if you’re flexible enough to change your workflow regularly. If I had a log of every tweak we’ve made to our Agile approach so far, it would be longer than this post.
What mistakes have your teams made when implementing Agile processes? How have you addressed those mistakes? Let us know in a comment.
Want to improve your structure for content marketing effectiveness? Sign up for our Content Strategy for Marketers weekly newsletter, which features exclusive insights from Robert Rose, chief content adviser. If you’re like many other marketers we meet, you’ll come to look forward to his thoughts every Saturday.
Cover image by Joseph Kalinowski/Content Marketing Institute
On – 08 Jun, 2017 By Eva Jackson