Whenever people are involved in a complex, creative effort, whether they’re trying to send a rocket to space, build a better light switch, or capture a criminal, traditional management methods simply break apart. - Jeff Sutherland, Scrum
When they hear the phrase “agile marketing,” most people think of Scrum. It was the original Agile methodology for software, and it still gets the most press.
Featuring timeboxed sprints, clearly defined roles, and multiple required ceremonies, Scrum is one of the most popular -- and most prescriptive -- frameworks for transitioning a team to Agile. It was developed in the late 90s by Ken Schwaber and Jeff Sutherland, who pioneered the system to address huge problems in the world of software development.
Before Agile software development and Scrum came along, development teams tried to produce functional, useful software based solely on massive requirements documents. These tomes were supposed to contain all of the requirements for the software or feature, but they never did.
New things always came up during the development process that increased the size of the project; you know this phenomenon as scope creep. And the developers themselves often underestimated the complexity and difficulty of their work; they had become all too familiar with the whooshing sound of yet another deadline flying by.
Incomplete requirements, scope creep, and overlooked complexity all rained down on development teams, creating projects that were over budget, late, and barely functional.
It’s not hard to see why they were desperate for a new mode of operating.
The original goal of Scrum was to embrace the uncertainty and creativity that already governed software development. “At its root,” Jeff Sutherland believes, “Scrum is based on a simple idea: whenever you start a project, why not regularly check in, see if what you’re doing is heading in the right direction, and if it’s actually what people want?”
(See what I mean by Agility being based in common sense?)
To make those simple goals possible, Scrum provides a framework that creates a culture of transparency, inspection, and adaptation while making it easier for team members to produce consistently great products.
That framework has two basic parts: events and roles. The events, also referred to as ceremonies, create a regular, predictable cadence for Scrum teams. They include:
Scrum events translate fairly easily from a software team to a marketing department. The second half of Scrum — the roles of the people who occupy the framework — doesn’t adapt nearly as well. Typical software Scrum roles are:
Most marketing teams who adopt Scrum as their methodology of choice adjust the roles; we’ll get to that soon. By keeping the components of Scrum that work well (events) and adjusting those that don’t apply (roles), we can arrive at a framework, for marketers, that enables us to creatively and effectively use Scrum. Let’s start with the events first.
The Scrum framework consists of only four formal events: Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retrospective. Here’s an overview, drawn from my experience and from The Scrum Guide and Jeff Sutherland’s Scrum, of how to structure these ceremonies.
Note: each event has a purpose within the Scrum methodology.
It can seem, especially in the early days of adoption, that you spend all of your time managing the process, and you may be tempted to ax one or more of these meetings. Give them a chance before you cut them out.
“Each event presents a formal opportunity to inspect and adapt,” The Scrum Guide reminds us. “Not including an event will risk losing transparency and missing opportunities to improve the Scrum process.”
I’m not the Scrum police, so I won’t come haul you off to Scrum jail if you eliminate your Sprint Reviews. Chop components if you must, but only to improve your process and performance.
It’s what it sounds like. You get the team together to make a plan for what you can get done during your next Sprint.
To keep things manageable and releases rapid, Sprints always last less than four weeks. Experiment to see what Sprint duration makes sense for your team, and then stick to that; it doesn’t work to set a one-week Sprint and then a three-week Sprint.
During the meeting, the entire marketing team creates the Sprint Plan based on what’s at the top of the Backlog, the prioritized to-do list that governs the work of all Agile marketing teams. The creation of the Backlog can be a group effort or the responsibility of a single person, but it typically happens through collaboration between a Marketing Manager, Marketing VP, or other leader, and a representative of the marketing team, most likely a Product Owner (or equivalent).
While stakeholders create the contents of the Backlog based on business goals and departmental priorities, the Agile team chooses when and how to accomplish that work.
A key outcome of the Sprint Planning meeting is the Sprint Goal, the primary objective of the coming Sprint.
For marketing teams, the Sprint Goal can focus the Sprint on completing a project or a shippable piece of a long-term initiative; without the Sprint Goal, it’s easy to fixate on completing one-off tasks that don’t help achieve larger marketing goals.
Keep in mind that a Sprint Goal “can be any other coherence that causes the [Marketing] Team to work together rather than on separate initiatives.”
Remember that!
Team members often work simultaneously on widely disparate tasks and projects. Sprint Goals can remind us that we’re all driving together to one finish line.
At the end of the Sprint Planning meeting, the team commits to completing their chosen amount of work within the coming Sprint. This should be a formal process of agreement, because it’s now the team’s responsibility as a group to get all that work done.
No one should be able to change or add to their workload once the Sprint has begun.
This team sanctity is one of the most important pillars of Scrum, particularly in the interrupt-driven world of marketing, so make sure executives and other departments are clear about your team’s Sprint goals and what work they’ve committed to completing.
An obvious question comes up at this point: how does a team know how much work they can do in a Sprint?
To figure this out, you need to estimate the size of the work in the Backlog so that you know how much your team can realistically handle during the next few weeks. Jeff Sutherland recommends never trying to estimate in hours, “because people are absolutely terrible at that.”
Instead, he suggests estimating by relative size, such as t-shirt sizes: x-small, small, medium, and large, or with the Fibonacci sequence: 1, 2, 3, 5, 8, 13, 21.
The Fibonacci sequence is often more helpful than t-shirt sizes because there is more distinction between the estimated sizes. A size-2 project or task is exactly one-quarter of a size 8; the difference between a small project and large project is entirely arbitrary and subjective.
(You can mitigate this lack of precision by assigning numerical values to the t-shirt sizes: x-small is a 1, large is an 8, and so on; but then you might as well use Fibonacci.)
Experiment with work-estimation methods to see what works best for your team and the kind of projects that you typically work on.
After a few Sprints, data tells you how much work you’ve done. You want this value, known as the team’s Velocity, to increase consistently, which is why you spend time on task estimation.
If your Velocity starts to dip, it’s time to take a look at process and team performance to see what’s changed or needs to change. If your team experiences external interruptions that impact Velocity, your objective data shows you the real-world consequence of outside forces on your Sprint.
Finally, estimating your marketing work enables you to track the team’s ongoing output with a Burndown Chart – the number of points needed to complete the Sprint vs. the number of days left in the Sprint. Ideally, you plot a steep downward slope that simultaneously crosses zero on each axis.
The second Scrum event, and one of the most powerful in the whole methodology, is known as the Daily Standup or Daily Scrum.
It takes place every day during a sprint; it is attended only by those who contribute directly to reaching the Sprint Goal; it features each team member discussing his or her progress and impediments.
It’s strictly timeboxed to 15 minutes, a limit to be enforced by the Scrum Master. During this Daily Scrum, each team member outlines:
Strictly speaking, no one who is not on the marketing team or directly contributing to the Sprint Goal(s) should attend the Daily Scrum.
Because team members rarely work on just one thing, it can be a challenge for each one to stay engaged while others share their updates. To counteract this common problem, follow Jeff Sutherland’s suggestion that the team adopt an approach to Daily Standup that’s closer to a football huddle than ticking boxes on a checklist:
A wide receiver might say, “I’m having a problem with that defensive lineman,” to which an offensive blocker might respond, “I’ll take care of that. I’ll open that line.” Or the quarterback might say, “Our running game is hitting a wall; let’s surprise them with a pass to the left.” the idea is for the team to quickly confer on how to move toward victory -- i.e., complete the Sprint. Passivity is not only lazy, it actively hurts the rest of the team’s performance. Once spotted, it needs to be eliminated immediately. I want aggressive teams -- ones that come out of the daily meeting knowing the most important thing they need to accomplish that day. One person will hear another say that a task will take a day, but another team member might know how to do it in an hour if they work together. I want teams emerging from that meeting saying things like, “Let’s nail this. Let’s do this.” The team needs to want to be great.
Sometimes called a Sprint Demo, this meeting happens at the end of a Sprint once the work has been completed.
Unlike Sprint Planning and Daily Scrum meetings, Sprint Reviews are open to anyone who wishes to attend.
The team shows off what they achieved during the Sprint, including content, social-media posts, email campaigns, new ads, etc. This is no time for quality assurance or edits; it’s a moment to review work that's completed and approved.
If you have work that was released earlier in the Sprint, you can share any preliminary performance data that you’ve collected.
Sprint Reviews often result in changes to the Backlog, as stakeholders in attendance make adjustments based on what they see. They might want to adjust priorities to further iterate on an unexpected success, or they might choose to pull the plug on some dud in the backlog.
Finally, conduct your Sprint Review with an eye to your upcoming iteration.
Spend time considering next steps for any projects to be included in future Sprints. For example, if you create one branch of an email nurture campaign and plan to add another during an upcoming Sprint, discuss and document any lessons from this iteration that might improve execution of the next.
During the Sprint Review, look at changes in the marketplace, departmental priorities, budgets, or timelines so that they can be incorporated into future Sprint Planning.
The final piece of Scrum is the Sprint Retrospective, a vital meeting in which the Scrum team inspects itself and its processes for opportunities to improve. Hold this meeting after the Sprint Review and before the next round of Sprint Planning, because outcomes from the Retrospective (sometimes abbreviated as Retro) almost certainly impact the next planning meeting.
Again, the Retro isn’t just about preparing to plan; it’s about creating and using a safe environment in which the team does the work of identifying ways that they can improve and where they can grow as a unit. Post the Retrospective Prime Directive somewhere in the Retro meeting room:
Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.
Traditionally, the Sprint Retrospective is structured around three questions: What should we stop doing next Sprint? What should we start doing next Sprint? What should we continue doing next Sprint?
And, while these can certainly be helpful in launching a discussion about how the team can continuously improve its process, asking them over and over again during every single Sprint Retro can quickly lead to stagnation. Here are a few alternative ideas to help you mix things up. Even just shifting the questions around can generate new insights:
Regardless of the structure you use, make sure that every member of the team has plenty of room to contribute.
People who are uncomfortable speaking up may not work to make their voices heard, so the Scrum Master (or whoever is facilitating the meeting) needs to help them. Simply asking everyone to write their thoughts down on sticky notes first, and then having them share in turn, can prevent dominant personalities from taking over the meeting.
Make sure that your intense discussion culminates in some action that can be incorporated into your next Sprint. To be effective, the concept of process improvement, also known as the kaizen, requires concrete, measurable changes. It frustrates a team to spend hours coming up with ways to function more effectively if, Sprint after Sprint, nothing changes.
They sound like something fancy, but for marketers Sprints are simply discrete periods of work done to achieve an objective. Some teams structure their Sprints around completing a campaign or finishing a piece of a larger, ongoing project, but you need only ensure that the team is working on the most important set of tasks.
In the software world, each iteration exists to produce a potentially shippable piece of code – one that functions well enough to be released – but there’s no requirement to ship, or even release, at the end of each Sprint.
For us, each Sprint is an opportunity to rebalance priorities and adjust the plan based on new information. Since we work in a fast-paced digital world, systematizing this practice is enormously powerful, as Scott Brinker points out in Hacking Marketing:
Overall, the management metabolism of short sprints isn’t about working harder or faster. It’s about dynamically reallocating our efforts more frequently, to take advantage of new information and innovations more quickly than quarterly or yearly plans permit. Yet it lets us do this in a considered and balanced manner, avoiding a chaotic, interrupt-driven frenzy. That’s agility.
So far we’ve stayed pretty true to the Scrum practices that were created for software development teams. Sprint Planning, Daily Standup, Sprint Reviews, and Retros all work much the same for both. But when it comes to Scrum team members, we need to make more significant adjustments to make Scrum work for marketing.
Software Scrum teams consist of a Product Owner, the Development Team, and a Scrum Master, and The Scrum Guide states how these teams function:
These functional ideals – self-organization and cross-functionality -- apply, and we optimize our Agile marketing teams for flexibility, creativity, and productivity; but our team structure often differs.
Agile teams work best without hierarchy among the team members.
But someone needs to manage the process of continuous improvement -- the traditional realm of the Scrum Master -- and we must have a liaison with stakeholders outside the team who manages the contents of the Backlog -- a function usually filled by the Product Owner.
Scott Brinker suggests changing the Product Owner to a Marketing Owner, a title that makes more sense on marketing teams that aren’t actually producing a product.
In the case of the Scrum Master, most marketing organizations lack the resources (if not the will) to dedicate someone’s entire day to managing the Scrum process. The Marketing Owner may do double duty, serving as both the protector of the Backlog and the process facilitator (as illustrated above), or the responsibility may shift, monthly or quarterly, from one team member to another.
Moving Scrum Master responsibilities around like this can better help team members with little Agile experience see how the process works and why it runs as it does. It’s also an opportunity to regularly get a new perspective on the process and how it could work better for the team.
Don’t worry about getting each and every team certified as a Scrum Master if you plan to migrate the role, by the way; a basic understanding of Scrum principles is all you need to get started.
The traditional formulation for Scrum team sizing is 7 plus or minus 2. Anything larger, and coordination becomes too difficult. The team – especially a distributed team – falls out sync, and camaraderie and shared ownership fade.
Departments too big to fit into a single Scrum team can form multiple Scrum teams, based on project types (website, content, social media) audience segments, products, stages of the buyer’s journey, or whatever cross-functional groups help you achieve the greatest velocity.
Smaller teams can also work -- Jeff Sutherland says he’s seen Scrum work teams as small as three -- but lighter-weight methodologies, like Kanban, often work better for teams of that size.
Although Scrum is the most popular methodology, that doesn't mean it has to be your default choice.
Think carefully about your team's needs, and be sure you're selecting a methodology that works in your unique context. You may want to check out these introductions to Kanban and Scrumban so you understand all the alternatives available to you!
Also, be sure to check out the library of microlearning content we developed based on years of working with Agile marketing teams, and the following 4 microlearning paths in particular:
Each of them contains 10 bite-sized lessons, 20 short engaging videos, and 10+ downloadable resources that can boost your Agile knowledge in minutes even during the busiest days.
Before you move on, why don't you take a second to get the most recent State of Agile Marketing Report?
