This post is based on my talk at MeasureFest in September 2019, which in turn is based on my experience running cross-functional marketing teams using Agile/Scrum frameworks.
Let’s start with - what is Agile?
Agile is a software development methodology that is described fully in the Agile Manifesto. The agile process has the following core values:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
Agile focuses on flexibility in the face of changing requirements and an emphasis on consistently shipping minimum viable software instead of an all-singing, all-dancing, comprehensive solution.
Alongside this focus on continuous delivery, agile also focuses on sustained improvement through continuous learning from new work pushed live and adjustment to fluctuating factors.
It’s a process that is tightly aligned to the software world, where speed to market and the ability to pivot are key factors in success.
How can a software development process be relevant to marketing?
As cross-functional teams become more common, alongside the requirement for greater collaboration between Marketing/Product/ Development, it is my opinion that marketing teams will be required to fully adopt agile processes.
Alongside better alignment with the speed and objectives of other teams and the wider organisation, adopting agile marketing processes can have a profound impact on productivity, team satisfaction and managing workloads.
If you want to delve into agile for marketing further, an Agile Marketing Manifesto already exists with the following seven core values:
- Validated learning over opinions and conventions
- Customer focused collaboration over silos and hierarchy
- Adaptive and iterative campaigns over Big-Bang campaigns
- The process of customer discovery over static prediction
- Flexible vs. rigid planning
- Responding to change over following a plan
- Many small experiments over a few large bets
What the hell is this Scrum thing then?
Scrum is an agile process framework for project management, with an emphasis on software development.
The best way I’ve found of thinking about it is to imagine Scrum as a flavour of agile - a variant that shares the base underlying principles, with a layer of implementation guidelines added on top.
Atlassian do a really good job of describing the difference between agile and Scrum:
People often think Scrum and agile are the same thing because Scrum is centered around continuous improvement, which is a core principle of agile. However, Scrum is a framework for getting work done, where agile is a mindset. You can’t really “go agile”, as it takes dedication from the whole team to change the way they think about delivering value to your customers. But you can use a framework like Scrum to help you start thinking that way and to practice building agile principles into your everyday communication and work.
Scrum is designed for teams of three to nine members, who break their work into actions that can be completed within time-boxed iterations, called sprints, which can last between two and six weeks.
How can I implement a Scrum Process for a Marketing Team?
Now you may be thinking at this stage, “OK Bethan, all off the above sounds pretty good, if not very jargon-heavy - how do I actually make this work in a marketing context?”
That’s a really fair question.
Below are a number of my tips and thoughts on taking Scrum and making it work for a marketing team or department.
At this stage I must be very clear that I am not a trained agile professional, nor am I an absolute expert on the subject. Everything I layout below is based on my experience of trying to implement a Scrum process in a cross-functional marketing team.
We certainly had a number of our own situational factors that made this transition both harder and easier - you will undoubtedly have your own.
Getting this right is going to take a leap of faith and a focus on both continuous improvement and experimentation. Thankfully this build -> measure -> learn -> try again process is absolutely at the heart of the Scrum methodology.
Step 1: You’re going to need to put in the work to get buy-in
When changing any process, whether at a team, departmental or organisational level, you need to recognise that humans aren’t robots. We can’t just ask people to flick a switch and accept change without question, especially when people have been using the same old processes for a long time without any deviation.
Before switching over to Scrum, whether you’ve been working using some kind of agile framework or not, you need to sit down your team and explain the reasons for change and why you think it’s worth trying out a new process. This can be a difficult discussion, but putting aside a reasonable amount time to do this ensures you can respond to any objections or worries in an open and honest forum. You’ll know the dynamics of your own team and whether you want to do this in a group or individual setting, but it’s really important you don’t skip this step.
Alongside getting the buy-in of your immediate team/department, you may also need to convince “higher-ups.” My best advice for this is to ask for a test period - it’s much easier to push through change if you can frame it as a reversible experiment.
Ask for a 6 month period in which to test out a Scrum process and outline what you’ll be measuring to evidence whether this experiment is a success or not (the great thing is that the Scrum process has an in-built mechanism for measuring output and velocity).
Step 2: Shifting around Roles and Responsibilities
Before I start talking about Scrum roles and responsibilities, I want to make it clear that I’m not talking about job titles - those do not need to change to facilitate this process.
Below I will outline the “traditional” scrum roles and the names I would use in a marketing context. The responsibilities each role takes on don’t change substantially whether you’re in a development or marketing team, I have changed some names just to avoid any confusion.
Product Owner -> Marketing Owner
The PO/MO sets the direction for the rest of the team and represents the needs and desires of wider stakeholders (anyone with skin in the game concerning the output of the work undertaken by the team).
They are responsible for curating the backlog of work to be done and ensuring this is ready to be presented to the team.
In the case of a marketing team, this role will probably be held by the marketing lead (marketing manager, director, etc.)
It can, in theory, be held by more than one person, but I would caution against this unless your team is extremely aligned to clear goals and values. Too many cooks and all that.
Scrum Development Team -> Scrum Marketing Team
A Scrum Team consists of three to nine members who are able to self-organize so they can make decisions to get work done. They are responsible for delivering the work through the sprint.
Scrum recognises no titles for team members, regardless of the work being undertaken. The team are trusted to self-organise to ensure that the work defined in the sprint is completed.
Scrum Master (This stays the same)
The scrum master assists the PO/MO with sprint planning and sprint reviews to ensure that deliverables and values are clearly communicated to the team.
They also help the team in the daily standups through ensuring that work is happening and that blockers are being removed (e.g. when the team/individuals is asked to do work that falls outside of the current sprint). They’re kind of like the team medic, staying on-hand should to ensure the team functions efficiently and that team members stay on-track.
This role is undoubtedly challenging and requires excellent people/negotiation skills, however I personally felt it was a great way of giving junior members of my team real responsibility and the chance to really understand how work is delivered and the external forces acting on the team.
The Scrum Master role doesn’t have to be assigned to one person forever. We used to rotate it in each sprint in order to give everyone exposure to the role and the wider context of the work.
Step 3: Developing and defining your backlog = your to-do list
The backlog is essentially a prioritised to-do list of deliverables the team want to get out the door. In the traditional Scrum process this is called a Product Backlog, in the case of marketing we will simply call it a Marketing Backlog. The most important items are shown at the top of the backlog so the team knows what to deliver first.
This list should contain all the work you wish your marketing team to execute on, from large campaigns to quick down and dirty press releases - we included everything. This list forms the roadmap for your team - the path they are going to follow to reach strategic team and company goals.
These roadmap initiatives are broken down into epics (big themes), and each epic will have several user stories, which then have tasks attached to them.
In case you’re a bit confused (I was in the beginning!), this is the difference between epics, requirements and stories:
Epics - large bodies of work that can be broken down into a number of smaller chunks (called stories). An example of an epic could be “ensure all marketing ops are GDPR compliant by the deadline”
User Stories - short requirements or requests written from the perspective of an end user - e.g. “as a user I want to be able to opt-in to our newsletter in a GDPR compliant manner” (please note the user could be a team member’s perspective - e.g. “as a marketing assistant, I want all of our web properties analytics to be contained within a single account so that I can access them easily”
Tasks - self-contained (e.g. fully executable on their own) tasks that form part of a user story. e.g. to facilitate the user story above, one task might be “ensure all analytics properties have centralised access from [email protected]”
Epics usually have several user stories and user stories can have several tasks associated with them. It’s essentially a granular hierarchy that breaks work down into exactly what needs to happen for the work to be “done” - e.g. completed and shipped by the team.
These tasks form the acceptance criteria of each story - for the story to be considered done. All acceptance criteria must be done. The team may also reject stories presented in the planning meeting if the acceptance criteria are not clear - they need to know the definition of done.
The backlog is reviewed by the marketing owner before each sprint to ensure that it has been correctly prioritised and feedback from the last sprint has been incorporated.
Step 4: Undertaking your first sprint
So by this point I’m going to assume you’ve bought in your team, defined team roles and developed your backlog.
How do we get going with our first sprint?
Decide how long your sprint is going to be
For development teams working on software, sprints can be up to 6 weeks.
Marketing has always been a bit faster paced, so I would argue you’d want to get down to 2-3 weeks. This is the pace I worked at with my team and it seemed to work well.
Set a start date and an end date and let the team know beforehand when kickoff and the retrospective (we’ll get onto that), is going to be.
2. Hold a Sprint Planning meeting
The purpose of this meeting is to define what can be delivered in the sprint and how that work will be achieved. The meeting will also present the sprint goal - a short, one- or two-sentence, description of what the team plans to achieve during the sprint.
The whole team attends the sprint planning meeting and during this meeting they will estimate how long the work will take - as they need to define what can or cannot be done in the sprint.
As I said above, ideally the team would be working during the sprint on nothing but the work defined during this meeting.
Marketing is undoubtedly a reactive environment and it’s sometimes impossible to predict some great media coverage that needs to be capitalised on, or a PR emergency that requires immediate attention.
To give my team breathing room for reactive tasks, I always made sure 20% of their time was left unallocated to deal with last minute requests. This gave us breathing room and if we didn't use it up, we simply added the next highest priority user story into the mix to ensure everyone still had work.
Also a note for managers - I always estimated the available time managers had as half. This ensured they always had time to be effective managers to their team.
A final note on training - I personally think training should form part of the user stories that go into the sprint. E.g. “As a team, we want to run a workshop on Google Tag Manager to ensure everyone has a basic understanding to help with future tasks”
3. Run the sprint
During the sprint the team will work through the selected work in the order it has been prioritised.
If anyone gets stuck or needs assistance to complete the work, the Scrum Master should be on-hand to help team members find answers and get help.
If it becomes clear that you won’t complete all the work selected in the planning meeting, don’t sweat. It just means you might want to re-think estimations or the scope of work for the next sprint.
During the Sprint the team will check in together daily for a quick stand-up meeting (the name comes from the idea that this meeting should be short enough that team members can stand throughout). Each team member will cover:
- What they did yesterday
- What they are planning on doing today
- What (if anything) is standing in their way - e.g. I don’t have correct permissions on Google Analytics
Stories are considered complete when all of the tasks (acceptance criteria) associated with them have been completed.
4. Hold a sprint demo
The sprint demo takes place at the end of the sprint and is attended by the whole Scrum team, including Product Owner and Scrum Master, as well as relevant stakeholders, management and developers from other teams.
During this meeting, the team shows off the work that has been completed during the sprint. It’s important to understand that the Sprint demo is not a sign-off meeting.
Sign-off is top-loaded in this process and should have happened before the PO/MO presents the stories for the sprint planning meeting. Discussion and feedback are welcome, but it shouldn’t change whether existing items are considered done. That’s why you have acceptance criteria.
5. Hold a sprint retrospective
The Sprint Retrospective is an opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint.
The team will ask together:
- What should we start doing?
- What should we continue doing?
- What should we stop doing?
The Scrum Master usually facilities this meeting an ensures any appropriate actions are taken before the start of the next spring.
6. Iterate and know it won’t be perfect the first time (or the second, or third)
If you’re not used to this process, the first time you do it will feel uncomfortable. Your team will feel clunky - definitions of done won’t be good enough, there will be confusion about who’s responsible for what, your backlog won’t be very well defined.
This is totally normal. Scrum is a process designed to facilitate iteration and it itself is a process designed to be iterated on. You will want to make changes to a lot of my suggestions above to find what works for you. That’s why checking in with your team during the daily standup or sprint retrospective
Thank you so much for reading
I hope this was useful for anyone planning to run a Scrum marketing team. If you have any questions about the above, or if I didn’t cover something you want to know more about, please contact me on twitter or email. I’d be happy to help.
(Likewise if you have any tips for me on improving the above, I’d love to hear them!)