Agile Marketing: how to start applying the methodology

Taking advantage of the fact that last week I published a Trello tutorial, I thought it might be useful to explain how I apply the Agile methodology in my projects.

You may not be familiar with agile methodologies.

Or perhaps you think they are only for software development and digital products.

Nothing could be further from the truth: they can actually be applied to any process, project or department.

And this article has two very distinct parts:

• In the first, I'll tell you a little about what agile methodologies are and how it all began. The theory behind them and their concepts.
• In the second part I'm going to explain how I apply the parts of this methodology that I like to marketing teams, so that, if you're interested, you can start applying them to yours right away. The practical, operational part.

If you already know the first part, you can jump straight here.

Let's start at the beginning.

Part 1: What the Agile methodology is about

It is an approach to decision-making in project management that focuses on developing functionality incrementally and iteratively, delivering more value to the user / customer in each cycle.

It first emerged in software development and was quickly applied to other fields, such as managing projects of any kind (not just software), product creation, UX and marketing.

It opposes waterfall models -where one part of the project cannot begin until the previous one has finished- because they are considered too bureaucratic, and it places a strong emphasis on communication between the parties, above documentation.

Sounds good, right? But you may be wondering how all this came about.

Well, now you'll see.

History of the Agile methodology

In the mid-90s a movement rejecting structured project management emerged, culminating in a convention in 2001 in Snowbird, Utah.

There, the term “Agile Methodology” was coined for the first time, the “Agile Alliance” was created and the “Agile Manifesto”, which sets out the principles of the methodology, was published.

The Agile Manifesto

You can read the original document here:

http://agilemanifesto.org/

The four values of the Manifesto

As you can see from the link above, the document states:

“We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.”

And these four values are broken down into these twelve principles.

The twelve principles of the Agile Manifesto

You can find them here:

http://agilemanifesto.org/principles.html

But I'll copy them for you:

1. “Customer satisfaction. It is the foundation of everything. It is achieved by delivering valuable products that meet a need.
2. Welcome changing requirements. Changing course along the way is not a step backwards. Any suggestion or solution is welcome if it improves the product.
3. Weekly deliveries. Dividing work into productive phases is the basis of the methodology. Whenever possible, complete one each week.
4. Progress can be measured. The evolution of processes is not subjective. It can be measured with specific indicators.
5. Sustainable development. The way projects are carried out must itself ensure their continuity. It is not about doing things for the sake of doing them.
6. Close collaboration. Project leaders should work where the tasks actually take place, not from their offices.
7. Face-to-face conversation. The responsible manager must communicate messages effectively, preferably in person. Regular meetings with both the client and collaborators are recommended.
8. Motivation and trust. Processes will only succeed if the people carrying them out are motivated and interact in an atmosphere of trust and solidarity.
9. Technical excellence and good design. Standards should never be lost, nor should the quality of the work. It all forms a whole.
10. Simplicity. Tasks should be as simple as possible. If one cannot be carried out in those terms, it should be divided into iterations until its level of complexity is reduced.
11. Team self-management. Although there should be someone who monitors the work teams, they must be able to organize themselves. Excessive hierarchy creates dependence among collaborators.
12. Adaptation to changing circumstances. Projects do not usually end the same way they began. It is essential that those carrying them out can adapt to the different circumstances that may arise.”

I don't know what you think, but if you've ever been involved in digital product development, it's hard not to agree with absolutely every point.

Very hard.

So much so that today, given its usefulness in its original field, this methodology has, as I said, been transferred to the management of all kinds of projects and even sectors.

People talk about “Agile Product Design”, “Agile Marketing” and “Agile Management”, all of which always try to focus on:

• Face-to-face communication.
• Transparency.
• Customer satisfaction.
• Simplicity.
• Incremental development and continuous improvement.

Are you starting to see the appeal of the methodology?

Let's move on to the essential elements.

Basic elements and concepts of the Agile methodology

Right. Everything explained so far sounds very nice, but to get started we need to bring the theory down to earth and explain the different elements that will make its planning and execution possible.

The framework

Although all agile methodologies share the same principles and values, each applies them differently.

And these different ways of doing things are the different frameworks or reference frameworks.

There are several, each with its own rules, advantages, recommendations and drawbacks. The two most common and best known are Kanban and Scrum.

Kanban

It emerged in Japan after World War II, which left the country mired in economic and technological disaster.

In the 50s Toyota designed a production system “just in time” (JIT) in which each part was made at exactly the right time, neither before nor after, which it described as “highly effective and efficient”.

To carry it out, they relied on cards that identified material needs in the production chain.

So this methodology takes the idea of cards and equates each one with a task.

It creates a board with one column for each status that a task has to pass through, for example:

• Defined.
• In progress.
• Completed.
• Reviewed.

This is an example of a simple board, but it can be made as complex as the project requires. An example of a more complex board could be:

• Definition.
• Analysis.
• Development
• Testing.
• Deployment to production.
• Documentation.

The board will be different for each company or team depending on its needs, and it applies both to new development projects (“launch the blog”, “open a TikTok channel”) and to maintenance tasks (“review the website banners”) or recurring tasks (“review affiliate commissions”, “weekly ecommerce reporting”).

The board can be physical (which is recommended so that it is visible and transparent to the whole team) or digital, which is where Trello comes in.

Scrum

It is similar to the previous one because, as I said, the principles and philosophy they are based on are the same.

The name could be translated as “scrum” and comes from rugby, when the whole team packs together.

They differ in small details, perhaps because Scrum is considered more restrictive and, in my experience, is more geared toward digital product development:

• Recommends cross-functional teams. Kanban allows specialized teams.
• Specific roles: Scrum Master, Product Owner and the development team are mandatory in Scrum; in Kanban you may have them or not
• Fixed-duration iterations (between 1 and 4 weeks): sprints (a lot of emphasis is placed on this).
• Changes: what enters a sprint cannot be changed, and desired changes are postponed until the next sprint so the burn process or Burndown can be measured (it's not quite that simple). In Kanban, changes are easier to execute because one of the lower-priority features can be replaced by the new desired one.
• Ceremonies with a fixed duration.
• New board in every sprint vs. Kanban's persistent board.

For all these reasons, I personally prefer Kanban for Agile Marketing, and that's the one I'm going to explain in this article.

In fact, although it is not the most common approach, I have seen and worked with hybrid models:

• Using Scrum for new developments and Kanban for recurring tasks within the same team. That's what we used at Lowi.
• The “Scrumban” methodology, which borrows parts from both.

User stories

Perhaps the core of the methodology.

It is a simple way to describe a concise task that delivers value to the user or customer.

They are usually written on cards (by hand on post-its or digitally) and include:

1. Title: brief, to refer to it.
2. Description: As a [user role] I want [functionality] So that [Story objective]. Example: "As a blog user, I want to see related articles at the end of the article so I can keep reading topics that interest me“.

In addition, they must have these characteristics:

1. Independent: from one another. They must be able to be tackled separately even if they are related. For example, in an advertising campaign, the design task will be separated from the copywriting task, although obviously both must be related.
2. Negotiable: the scope and details are agreed between both parties and renegotiated if necessary, for example by splitting the task into two parts.
3. Valuable: they must deliver real value to the customer; it has to be tangible.
4. Estimable: meaning the effort required to execute them can be analyzed. In time or development points.
5. Small: if they are too large and cannot be estimated, they must be subdivided.
6. Testable: testable, with binary acceptance criteria (it passes or it doesn't).

Once written, the task is placed on the board in the initial column and, as its status changes, it moves between columns.

The Backlog

It is the set of project tasks that have been written and are still pending.

The Team

Depending on the methodology, having certain roles on the team may or may not be essential.

For example, in Scrum it is usual to have:

• Product Owner: business owner of the product.
• Scrum Master: problem-solver and development facilitator. They may or may not be the team leader.
• Development team / specialists (UX, designers, SEO…): basically, the people who will execute most of the tasks.
• Tech lead: the team's technical lead. It may be the same person acting as Scrum Master.
• QA: testing.

In Kanban these roles are not required, although it is true that the better each team member's role is defined, the easier it will be for them to assess the task and carry it out later.

Sprints

The duration of an iteration, cycle or delivery in which one or more prioritized new features or improvements (features) of a digital product will be released, or the relevant tasks for that cycle will be carried out (“create the Instagram content”).

They usually last between one and four weeks. In digital product development they are usually two or three, while in marketing they can easily be one week.

The Sprint goal

In product development, they have a Sprint goal, which brings together most of the features intended to be tackled.

In other types of projects, that goal is not always necessary.

Ceremonies

This is what the team's methodology-specific meetings are called.

These are the most common ones, and each has its own duration, frequency and objectives:

They are used to analyze and iteratively improve development and processes

• Daily: every day, team members briefly say what they are going to do that day and whether anything is blocking a previous task, so the steps needed to remove the blockage can be discussed. It should last about five minutes.
• Sprint plan: at the end of the current sprint, the team meets to discuss how the next sprint will be approached and to estimate the tasks.
• Refinement: this is the step before the previous ceremony. During refinement, the aim is to make sure each story is clear and understandable enough for the team and that its scope is defined so it can be estimated in the Sprint plan.
• Retrospective: after the sprint closes, the team analyzes how things went, what problems arose and which improvement points can be considered for future sprints.

If we're talking about marketing, are all these ceremonies essential?

I'll give you my answer later, because this is where the theory ends.

Now I'll explain how I've applied it from scratch in different teams and projects.

You'll also see that the approach is very simple and doesn't require radical changes or new tools to start applying agile principles.

Part 2: The process of implementing the Agile methodology in Marketing

If you've never had experience with agile methodologies, the first thing I want you to do is read the manifesto and its principles several times because, really, that's enough to understand and apply some concepts.

It's a change in mindset where I'd say the main thing is to talk and reach agreements between the parties (managers, your own team, external teams…) knowing that you're all seeking the common good.

Second, be flexible. Understand that changes will come and you have to accept them. Even if they annoy us. That doesn't mean always “giving in”, but going back to the previous point: talking and agreeing.

Third and finally, measure. Because measuring is the only way we have to know how optimal our performance is, how our team is performing and whether all the actions we carry out are actually worth it.

Right, once you've got that firmly in your head, let's talk about the system.

The Agile Marketing system

The idea behind it is that your team is capable of executing a limited number of tasks within a given time.

We're going to call that period a sprint and, to begin with, the simplest thing is to make it one week long.

So you'll need to organize a system so that the right number of tasks are completed each week (sprint).

How many tasks is that? Well, at first you don't know because you have no history. So, in the first sprints, the best you can hope for is to estimate with a certain margin of error, which will shrink as you and your team gain experience.

You also have no experience writing tasks yet, which adds another layer of difficulty to the estimate.

But don't worry, this lack of certainty won't last long: once you've completed several sprints, measured them and learned how to write tasks properly, you'll have data that lets you estimate each task much better.

So, knowing how this will evolve, the first thing is to find a tool where you can create the backlog and write down all the sprint tasks.

Agile Marketing tools

You have several options, depending on whether you prefer them online or offline.

Advantages of each type?

Well, online tools are more immediate and can have minimal cost, while offline ones, which basically consist of a board and some post-its, make it very clear to the whole team what is being worked on and highlight that work to the business.

My recommendation?

Except in cases where it is essential to make absolutely clear everything that is being done, start with an online tool.

I recommend two, depending on how convinced you are about the system: Excel if you want to test it and Trello if you're convinced this is for you.

Agile Marketing with Excel

I say Excel because it's the most widespread, but any spreadsheet (Google Sheets, LibreOffice…) will do.

The idea here is not so much to talk about Kanban and boards as to start applying agile principles right away.

To do that, you'll create a document where you'll add every task to be tackled, one below another. It will be your Backlog.

You'll also create a series of columns to help you define each task, plan and measure team performance, and measure the effort required by each type of task:

In this case, the columns we have are:

• Priority: although we could put the sprint's highest-priority items at the top, that would prevent us from filtering, so we add a column.
• Brand: if you work with several clients or brands, this will let you segment by each of them.
• Tasks: in this case we add only the title because, in general, these are tasks we already know and don't need broader descriptions.
• Comment: in any case, if we needed more detail, we'd add it here.
• Task type: this will let us know how much time we spend on each different activity and analyze:
• Whether the time invested is worthwhile.
• Whether execution time decreases as the person gains more experience doing the same type of task.
• Person: simply, who is going to do it.
• Task status: Not started, Started or Finished.
• Entry date: the sprint start date, which will allow us to filter what is done in each sprint.
• Start: the date when the task changes status from Not started to Started.
• Start time: the time when a task is started.
• End time: the time when a task is finished.
• Effort in hours: the difference between the Start time and the End time.
• Week: to know the week of the year and be able to compare in the future or make charts.

Each sprint, new tasks would be added with their Entry date, and filtering by that date would give us the new sprint.

Of course, if tasks from other sprints are still pending, we add the previous sprint date to the filter so tasks from both appear.

This method works as long as we don't have tasks spanning more than 2 sprints; otherwise they would pile up too much and we'd need another system, such as creating a new task in the new sprint to replace the one left undone in the previous sprint.

Right, a template like this is more than enough to start planning and applying the three pillars of agility: agree, be flexible and measure.

Then, once you've been doing it for a while -and you see that it works- you may want to go one step further. That's when it's time to change tools…

Agile Marketing with Trello

First of all, here you have a tutorial to get started with the tool.

Once you've read it and created your account, you should know that I've also published this article about how to use Trello to apply the Kanban methodology in marketing, where I go into more detail, but here are a few pointers anyway:

1. Create just one board to start with. It's much easier to manage when you're starting out.
2. On that board, create 3 or 4 columns, no more, which could be:
• Backlog: the backlog with all the tasks: those in the current sprint and all the others added for future sprints.
• To do: move from Backlog to this column the tasks that are going to be executed in that sprint. The highest-priority tasks go at the top.
• Doing: once the sprint has started, when the person responsible for each task starts a new one, they'll move it from the To do column to this one.
• Done: once a task has been completed, it is moved from the Doing column to this one.
3. If the task had to be validated by someone other than the person who carried it out, we'd add a fifth column, "Validated".
4. Once the sprint is closed, all completed tasks would be archived and we'd start placing the new sprint's tasks in To do.

Easy, right?

Now we'd just need to add the analysis layer: see what happened if something wasn't completed, whether the problem was team capacity analysis, task wording, task estimation…

And one way to tackle the issue is through the ceremonies.

Agile Marketing ceremonies

In the theory section we talked about four ceremonies:

• Daily.
• Sprint plan.
• Refinement.
• Retrospective.

Each is carried out with very clear objectives, but I think they are very focused on digital product development and not all of them are essential in marketing.

In fact, it also depends on team size because, the larger the team, the more necessary it is to impose order and listen.

With that clarified, here's my opinion on each one:

The daily is essential. And it is because it greatly helps the team work well and unblock things, as well as making sure we all know where we stand.

The sprint plan is useful, although not essential if the team is small (up to 3-4 people).

And refinement, is even more dispensable because, if the team has been together for a while, you don't need a session to clarify things that can be resolved with a Slack message or a 30-second call between the two parties.

The retrospectives are especially useful if there has been a significant problem during the sprint. Hearing each member's opinion will help us make good improvement decisions.

That said, I don't think it's essential to hold them after every sprint (especially if the sprints are weekly), but they should be held periodically and also, as I said, whenever there has been a fairly significant issue.

To conclude, let's say I believe ceremonies have to be a means to an end, not an end in themselves, as I've sometimes encountered.

Team size

Although I've used the system explained so far with teams of 10 people, I think some adjustments would be needed for a team that size.

However, I think it's perfect for more modest teams of between 3 and 6 people.

If your team is smaller, I don't even think Trello is necessary. Excel and Slack (or Telegram) may be more than enough.

Advantages of Agile Marketing

The main one for me is being able to have a view of all the tasks to tackle in each sprint, so we can clearly see which ones we can get to and which ones need to be postponed. It's very easy to prioritize and assign tasks to people.

For organization, this is fantastic, especially because the team knows what it has to do and can focus on it.

The next advantage is that, once the system has been implemented, we'll be able to measure and analyze each type of task. If you compare the effort with the business contribution, you may be surprised and stop doing tasks you've been doing for years ("Facebook posts").

Or discover which team member is best suited to each task.

Another advantage is that, especially if you use Trello rather than Excel, everything is documented, giving us a genuine repository at our fingertips.

Finally, if necessary, as I mentioned earlier, having a well-populated board or backlog highlights the value of the work done by the team.

Finally, the cost of all this is low:

• In money, because the tools are free or low-cost.
• In time, because although there is a slight increase in workload, I hope I've made it clear that it more than pays off.

Conclusions

Although the article is fairly long, I've barely scratched the surface of the Agile methodology.

It's an introduction so you can consider whether this might be for you or whether your current system suits you better.

In any case, beyond systems, I'd like you to remember what, for me, are its three main values:

• Talk and agree between the parties.
• Flexibility.
• Measurement.

Assuming we're clear that what this is all about is getting the work / project done.

With that said, I hope I've been able to explain the value of applying the Agile methodology in Marketing teams because, when executed well, it really adds a lot of value. I say that from my own experience.

So do me a favor and give it a chance.

In any case, although I'm certainly no Scrum Master, if you think you need help organizing your team on digital projects, just write to me.