For better or worse, when they hear the word “Agile,” many people think “Scrum.”
This methodology, the first of three that we’ll be exploring in detail as part of this year-long series, was the first into the fray when software developers started looking for new ways to work, and it remains enormously popular in IT.
You can check out our podcast, IT Project Management For Beginners, for an overview of this niche area of project management.
To put it in marketing speak, Scrum enjoys a high level of brand awareness, which tends to make it the first stop on an Agile journey. One of Scrum’s originators, Jeff Sutherland, describes the approach this way:
“At its root, 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?”
Simple, right? But if that’s all there was to Scrum there wouldn’t be another 2,300 words in this article.
Yes, the concept at the core of Scrum is simple, but over many years and innumerable implementations things have gotten a little complicated. We’re going to get into the nuts and bolts of Scrum in a moment, but I want you to keep that nice, simple nugget of truth in your mind as we go.
There may be a lot of moving parts, but don’t let Scrum’s complexity mask its power. You can get more done in less time with this system, provided you get it (mostly) right.
Scrum is an iterative approach, which means it’s designed to deliver small things rapidly that can build up into something larger over time.
Each iteration, known as a Sprint, lasts just a couple of weeks. The team who is responsible for actually doing the work gets to decide how much they’ll commit to getting done during the Sprint, and nobody is supposed to mess with their workload once they’ve made that commitment.
At the end of every Sprint the team should have produced something that could be released to their audience, although it doesn’t have to be.
Scrum emphasizes rapid releases in order to learn what works faster. We have hypotheses about what our audience wants, but we can’t know for certain until we put real work out in front of them.
Using iterations through Scrum lets us do that faster, and with less risk, than traditional project management cycles that require an enormous amount of up front planning.
Ok, that’s the bird’s eye view. Here’s how it works on a real team.
Typical Scrum Roles
An easy way to envision Scrum is to break it into two parts: roles, or the people on a team, and ceremonies, or the events that those people take part in.
When it comes to Agile marketing, Scrum roles tend to require more adjustment than Scrum ceremonies, so we’re going to start with those.
If you ask me, Scrum Masters have one of the best job titles in the world. Who else gets to put “Master” on their business card without sounding absurd?
But Scrum Masters definitely earn their titles; it’s a tough and sometimes thankless job.
Generally, these are the people who are responsible for helping a Scrum team stay true to the principles and practices of Scrum.
They facilitate meetings, remove any impediments that are keeping people from being productive, and guide team members into a deeper understanding of Scrum. They’re expected to have a thorough understanding of all things Scrum, as well as maintain strong interpersonal connections to the team.
They’re a little bit like the Scrum team’s parent.
The Product Owner role got its name from development, because those teams build actual software products. If the Scrum Master is in charge of the Scrum process, the Product Owner (PO) is responsible for making sure that process is applied to the right work at the right time.
A good PO understands the “who” and “why” behind the work the team is doing.
They communicate constantly with stakeholders and customers, ensuring that the team is delivering work that matters to users and produces value for the business.
Product Owners are a little like managers, but in Scrum there’s a much stronger emphasis placed on their connection to users than any seniority they might have in the organization.
Developer (or Marketer)
The Scrum Master and Product Owner are, traditionally, the only differentiated roles on a Scrum team. Every other team member shares the same title: developer. Or, in our case, marketer.
Ideally each team member should be cross-functional, which means they have a broad skill set that enables them to contribute to all phases of work. This value arose from a common development problem, which was having a surplus of employees writing code, and far fewer who were able to test it.
In addition to being cross-functional, Scrum teams are typically flat; managers and directors are rare.
They’re also designed to be self-organizing, which means they choose the work they do and identify the best way to get it done. The business, in conjunction with the Product Owner, decides what work needs to be done, but the team decides how to make it happen.
How Marketers Often Adjust Scrum Roles
I really like the way Scott Brinker illustrates the changes that marketers make to Scrum roles:
Image source: Hacking Marketing
The biggest change is combining the Scrum Master and Product Owner into a single role. Most Agile marketing teams don’t have the resources to employ a full-time Scrum Master AND a Product Owner, so putting them together is often a practical necessity.
This combination can also ease adoption for marketing teams. When existing marketing managers or directors can learn Scrum, they can continue to operate as the marketing owner they’ve always been while also taking on the role of Scrum advocate and trainer on the team.
The final adjustment that needs mentioning is the flat, cross-functional nature of Scrum teams.
Marketing teams often employ specialists who simply aren’t very cross-functional, but are nonetheless very good at their jobs.
To stay on track, Scrum teams should be able to complete all the work they commit to during a Sprint on their own. Cross-functional team members give them the best chance of doing so.
But, if you’re not fully staffed with cross-functional, t-shaped marketers, don’t despair. With some deliberate cross training you can grow your team’s skill set and start moving in the right direction.
To see Part Two of this post, with information about how you can start implementing Scrum, check out our March 16 post or subscribe to receive our newsletter.
Tune in to our on-demand webinar, Marketing Project Management 101, for tips on honing your project management skills.
Get Blog updates straight to your inbox