Want more awesome content? Sign up for our newsletter.
In a time of lean resources and an ever-accelerating business pace, marketing teams need to be more responsive than ever before. Designed initially for complex software development projects, Scrum is also a useful approach to help marketing teams identify and focus their efforts on high-value activities and continuously improve the results over time. In this post, you’ll find out step by step how to use Agile marketing to increase transparency and efficiency, and build a marketing team that delivers results (and actually rocks!).
Have you ever heard the saying “constant dropping wears away a stone”?
Well, this is what happened to me while working in a company where the R&D department never stops talking about Agile methodology: slowly, day by day, my curiosity has grown.
After months watching groups of people stand at the beginning of each morning (don’t worry, I don’t see through walls: we work in an open space) talking about story points, backlog, stories, sprints, retrospectives, epics, etc., my exploratory spirit could no longer resist.
So, after a quick search on Google and a bunch of questions to my colleagues, I started connecting the dots until the painting became clearer.
Then, as I became more and more familiar with Scrum, I started to understand why many companies have dropped the waterfall methodology in favor of this software development model.
Once you get into the mechanism, in fact, the benefits become so evident that you cannot help but wonder why it’s not being applied to other teams and sectors.
However, incredibly enough, surfing the Internet, you can find many examples of Agile method applied to development, but very few cases where it’s used within marketing teams.
That’s why I decided to join these pioneers and venture out on this unexplored green land to see how far you can go.
Introducing Scrum into the Marketing team.
If you’re a software developer working into an Agile team, the following information will appear obvious to you (and, probably, not exhaustive). If you are a Scrum Master (especially one of the two exceptional guys that work in my company and shall forgive me as they read these lines), you’ll find several inaccuracies and maybe too many adjustments comparing to the Scrum book.
On the other hand, if you are a marketer, hereunder you may find some useful tips to help you get stuff done through a framework that keeps your team’s members synchronized, flexible, transparent and insanely productive.
How Scrum works.
I don’t want to bore you with unnecessary details, but, in order to fully understand the real advantages deriving from the adoption of this approach, I think it’s essential to define some key terms and roles, and the main steps of the process.
Stories, epics, sprints.
At the heart of Scrum methodology, there are the backlog items, that we treat as “user stories”, just like our R&D department.
In fact, stories are nothing but the items that form the building blocks of a Sprint.
They must be expressed in a few short sentences, following the pattern “As a (role) I want (something) so that (benefit)“. For example, “as a salesperson, I want several use cases to be shared with partners so that they can remember Imagicle strength points when they talk to customers.” In a nutshell, stories represent the stuff to do.
Whenever a story can’t fit in a Sprint, it becomes an Epic, a big chunk of work with one common objective to be split into smaller stories.
So, for example, in our team, we have Epics like ”Launch a new website”, “Adopt a marketing automation tool” or “New video series for applications”, stories related to an Epic or free-standing stories (e.g. “create the storyboard of new Imagicle Call Recording video”). Plus, a few small tasks that don’t require further subdivisions and act as a reminder for little activities to be carried out during the sprint (send an email, update an image on the site, etc.).
I’ve been talked about the Sprint. If you work in an (Agile) software company, I assume you know what it is. But just to be clear, the Sprint is a time-boxed unit of work in which the scrum team will deliver the Sprint goals. The length of the Sprint may vary from 1 to 4 weeks.
On our team, we’ve decided to set a Sprint length of 2 weeks, because a week seemed too short a time to carry out broader activities and to plan and reviews the Sprint. At the same time, activities that take more than two weeks are likely to become dispersed, while the team’s focus is likely to diminish.
As PO of the team, I’m in charge of the backlog; so, first of all, I’m responsible for sharing the vision and priorities with the team.
Ok Bernardo, but in practical terms, what do you do?
Basically, I make sure that backlog is visible, transparent, and clear to all members, and I prioritize the items in the backlog in order to produce the maximum value from the work of the team.
In Imagicle we’re lucky: we have 2 amazing Scrum Masters (you can learn more about them here and here).
But, once again, what does a Scrum Master actually do?
As I like to joke, they are the evangelists of the Agile concept: they show us the way, and they make sure that we stick on it helping us to get the most from Agile approach.
A Scrum Master should manage Sprint Reviews, plan meetings, stand-ups, and grant the overall facilitation of the Scrum process. At Imagicle this is not always the case, since the Scrum Masters must also take care of some R&D projects and other teams, but that is certainly the right direction.
All members of the marketing department (included me) are part of the team and, as such, they contribute to the entire process described hereunder (by the way, we’re looking for new talents to join our team…Take a look !).
To be clear, there’s nothing like a hierarchical relationship: we all are on the same level, and each of us contributes to getting the job done. The success of the team is everyone’s success, and so are the failures.
The backlog includes all the Epics and Stories that we’d like to do.
With the approval of the Product Owner, every team member can put things in, taking inputs from several stakeholders or individuating new activities on his own. For example, after a meeting with a colleague of the Sales team, as a team member, I could add a story regarding a new demonstration video.
It doesn’t matter how many stories you have in the backlog: at the beginning of each new Sprint, the most important ones will be at the top of the list, highlighting the first things to take care of.
Sprint Review and Planning.
Every 2 weeks, on Monday morning, we have a meeting with the whole team to review the activities performed in the previous Sprint and plan the next ones.
To be honest, the part dedicated to the review is quite informal and fast; we review the stories day by day as they are closed.
We are aware that this isn’t the very best practice, but often it’s difficult to wait until the end of the Sprint to complete a story (think to the several deadlines required to organize an event); in that case, we may need to perform the review during the ongoing Sprint, perhaps involving a relevant stakeholder.
At the moment of the Sprint planning, instead, we analyze the leftovers of the previous Sprint and the existing backlog. The remaining activities are not necessarily included in the next Sprint: if they haven’t been completed, in fact, maybe they are not that compelling.
As I said before, the items at the top of the existing backlog are the most significant: so, we will start moving them in the upcoming Sprint. Also, we add new things based on what we learned in the last Sprint and/or what came up from other stakeholders, until we reach the average velocity of our team.
The velocity is expressed by the number of story points that, on average, completed in the previous sprints. The story points are based on the Fibonacci Sequence (0, 1, 1, 2, 3, 5, 8, 13, 21, etc), where every number after the first two is the sum of the previous couple of numbers. This sequence represents the complexity of the story transcending mere temporal metrics (humans are quite bad at estimating effort, especially when complexity increases).
At this point, the sprint can start and everyone has a clear idea of what to do and when to do it.
Scrum approach includes a meeting that takes place at the same time and place every working day, in which attendees typically participate while standing and talk about progress since the last stand-up, the anticipated work until the next one and any impediments, taking the opportunity to ask for help or collaborate.
Within Imagicle marketing team, we have translated this practice into an informal approach. We can do it over coffee, by phone or by videoconference at any time of the day, as long as we can provide others with a clear picture of the current status of the activities.
Many tools in the market can help a team to become Agile.
At Imagicle (not only as marketing team), we’ve chosen Jira Software, the software development tool designed for Atlassian’s Agile team. It was born within the Software framework for the management of development teams, but over time it has also specialized in offering a series of “Business” type projects. These are essentially the Kanban boards responding to specific needs (such as monitoring opportunities, recruitment, drafting docs, etc.) with accurate workflows.
As a marketing team, we prefer to use Jira’s classic software projects to take all the advantages of the tool like Sprints (not available by default in Jira’s Business projects), burndown/velocity/reports and, above all, the possibility to customize the tool based on our needs. Also, we add specific subtask items to track the task of our graphics agency. This way, we have a single pane of glass to visualize and control all our activities.
Probably, as a marketing team, we were already more Agile than we realized. We’ve always been highly responsive to market changes and customer needs, so much so that Agile came somewhat natural.
Anyway, while moving toward the philosophy and the “rules” of a proper Agile approach, we had to change our mindset.
By breaking our activities into smaller segments of work, prioritizing those tasks and working through them in a specific timeframe, we have succeeded in staying focused on the main tasks respecting an urgency scale that is renewed, and changes, with each Sprint.
Sprint by Sprint, we’re getting better at estimating each activity workload, we become more and more aware of our velocity. We know what we’re able to do and what needs to be postponed. Last but not least, all the team members are self-organized and happy (as I said above, we’re looking for new talents that help us to speed up…take a look at our ).
Possible improvements and what’s next.
This first experience is just a beginning, and we are aware there are many aspects to improve. After all, Agile itself requires continuous improvement based on everyday experience.
First of all, we have to work on the transparency (one of the most important Scrum principle) outside our team. The idea is to share our marketing dashboard with all stakeholders at the end of each Sprint together with the tasks accomplished, in order to keep them updated about what we’re doing and what we’re going to do.
A further area of improvement concerns handling unplanned work during the Sprint. If you’re a marketer, you know what I’m talking about. It’s not unusual that during a 2 weeks Sprint a colleague from the sales dept., for example, asks for support on a presentation that came out of nowhere, or that your CEO requires you to stop doing whatever you’re doing to work on a specific opportunity. As my Scrum masters said, in the long run, this should impact on the velocity, but I think it’s better to learn how to measure the unplanned work and take the appropriate countermeasures.
Finally, in the past months, I’ve been very interested in a (quite) new marketing field: Growth Hacking. Someone said that the term Growth Hacking is mainly used within startups, while Agile Marketing is the term used for enterprises. I’m quite sure this statement is wrong, but I found something similar in these two approaches, and I believe this relationship needs further investigation.
Perhaps in another post
I’m happy to reply to any of your questions or suggestions on this topic.
Drop a comment below, I’ll come back to you!