In part one of this blog series, I introduced you to the concept of Agile Marketing and how it is a methodology instead of a set of rules to follow. In part two, I plan to fill you in on how we went about implementing Agile Marketing in Kentico.
Our Team
First of all, I want to introduce our team and structure a little, so you have a better understanding of how the hell we came to use Agile Marketing in the first place. Kentico is an international company and we have 23 marketing staff and one Scrum Master. The role of the department is, like many others, to create content and campaigns for marketers and developers that generate demand for our products. We also support our partner network with marketing enablement activities and thorough onboarding processes.
The Kick Off
In Kentico, all our Development teams (you know, the people it was actually designed for) work within the Agile Development framework. It is tried and proven and works well for the company. Our Marketing team was working on marketing activities, ad-hoc tasks, running campaigns, creating collaterals, analyzing results, and even acted as a service team for other departments creating content, graphics, website updates, and so on. Management decided to introduce the idea of Agile Marketing in a bid to track, prioritize, and improve the efficiency of the work we do.
So where on earth were we to start? At the time it was introduced, we had no Scrum Master and not many people in our team knew what Agile Development was, let alone Agile Marketing. We figured that if we were to start planning and prioritizing in the Agile way, then we should at least know what tasks we were working on. We painstakingly set about adding all the tasks we were doing into a backlog. Now, if you look into most development backlogs, you might find 50 to 100 tasks that are prioritized. When we did the arduous work of breaking down everything we do into tasks that are achievable within one- or two-week Sprints, we had a backlog of nearly 300 items. Now try to imagine sitting in a planning meeting with over 20 people and trying to prioritize a list of 300 tasks, many of which were for other departments that all had their own priorities they needed our help with. It was a nightmare. But we stuck to it. We were able to see which tasks were being worked on, the complexity of those tasks, and where the bottlenecks were within the department.
Are We Agile Now?
Now it is time to throw a spanner into the works. If you read part one of this blog, you would have read about Sprints, about completing chunks of a project in one- or two-week time frames, about delivering minimum viable products and then building on them. But that is all part of the Scrum methodology of Agile. If you're asking why I waited until now to introduce this, it is because it was about this length of time into trying to become "Agile" before some of us started to realize there was more to it. Agile is a way to help a team to implement value, to work at an optimal rate, to implement changes, and to change focus quickly. But managing the backlog and workflow to achieve these things can be done in a number of ways. I won't go into too much detail about how each of them work, that's what Google is for, but I'll give a brief overview. And I'll be honest, it took me time to figure out how they all work in Marketing.
So, imagine we are launching a new product. We want to advertise it, obviously, and want to try to generate as many leads as possible for our Sales team to follow up on. If we determine the "perfect" campaign, we need maybe a campaign landing page with content, graphics, and a form, we want to write a blog post with information about the release, we want to send a newsletter to all our subscribers to inform them of the new release, we will launch paid and organic social media campaigns, we will have CPL campaigns running, we will create a new brochure, and we will run a webinar series. Now, let's look at how these would work in each Agile method.
Scrum
Scrum, as I mentioned in part one, runs on the principle that "at the end of the Sprint, you should deliver some "value"—some usable asset that, if disaster occurs, can still be used in your campaign". It is called the principle of continuous delivery, where you have a "shippable product", to give it its development name, after every Sprint. So we would probably look to implement a basic landing page with some minimal content, a header image, and a form for collecting data. It won't look good, but if all else fails, there is at least somewhere that we can collect data. Now, in the next Sprint, we would probably look to make that page better, adding extra content, more graphics, and adding some tracking to the page. In the third Sprint, we might choose to work more on the page, or decide that, right now, it would bring more value to write a blog post and add graphics to it, so that people can read about our product and link to the page. As time goes on, we will plan with our team for each Sprint what can be done and what will bring the most value to the campaign. We might reach a point where the greatest value is actually revisiting the landing page and making more improvements to it. If we have planned properly and started early enough, we should reach the "perfect" campaign by the launch date. But if not, we should still have a lot of value ready but might be missing some final banner ads, or not have perfect animation elements on the landing page—some nice-to-haves that might add a little value but are not essential to the campaign
There are some Scrum rituals that have been introduced over time that should help you. Before each new Sprint, you should have some Grooming meetings with your team. These are where you get to discuss the ideas, determine the difficulty of the tasks ahead, and find out just how many people need to be involved. Next, you should have planning meetings at the start of the Sprint. Here, you will decide what tasks will be completed in the coming Sprint and by whom (this doesn't directly fit to the self-organized Scrum team, but Marketing is full of specialists), based on the difficulty and the priority. At the end of each Sprint, have a review meeting with the team and invite any external teams or departments that might be interested to discuss what was completed. And finally, have a retrospective meeting to discover what is working well in the team, what could be improved upon, how to improve the efficiency of the team, and, if there are tasks left undone, to determine why they are not done and whether there is an issue that needs to be solved to complete the task.
Kanban
Kanban, as a methodology, is not as strict as Scrum. Although it is always a good idea to deliver "value" in your tasks, Kanban takes a different approach to controlling the backlog. Looking at the example above, we would take all those things from the "perfect" campaign and turn them into tasks in our backlog. Now, we might not break them down as much as in Scrum but we should still break them down into tasks such as "Landing Page Content", "Landing Page Graphics", "Blog Content", and so on. The process should be controlled by the Team Leader and tasks should be prioritized accordingly. In Kanban, you do not work in Sprints. Instead, you work on the principle of continuous improvement where you don't have a "shippable product" ready but rather finish tasks in the build up to a final release date or campaign launch date. So we might start off at the top of the backlog, where the number one priority is writing content for the landing page. This gets moved to "In Progress" and assigned to a person that can complete this task. The next task on the list is creating graphics for the landing page. Again, we move it to "In Progress" and assign it to someone in the team. We continue down through our backlog moving items to "In Progress" if they are currently being worked on or likely to be worked on in the very near future. When doing this, you need to make sure you do not overload one person, and then move through the backlog assigning tasks for others in the team. Be mindful of the fact that some problems or ad-hoc tasks might arise and you don't want your team to have too much on their plate that they can't change focus. Notice that I never mentioned a role here but rather "someone". As Agile was initially formed for development teams, part of the Kanban methodology is that it doesn't matter who takes the task as long as the highest priorities are being worked on. Many development teams would have many people that could perform the same tasks. This is not the case in marketing where you have specialized graphic designers, content writers, campaign specialists, web developers, and so on. So, keep this in mind before you consider Kanban as a strict way of work. Kanban works by moving tasks through workflow stages where, once complete, they would add some value of their own to other completed tasks. So the Landing Page Content might be done, the Graphics also, and now another team member could move their task of implementation into "In Progress" and work on that part while others move onto other tasks in the list. In Kanban, there is a lot more pressure on the Team Leader to make sure that the items are prioritized, so that people take the most important tasks next, and that the value is delivered as soon as possible. It is slightly more restrictive than Scrum too. If, for example, the content and graphics for the landing page took longer than expected because the assignee decided they wanted to make it perfect first time, then the implementation might have to wait. If, in the meantime, something happens and the team is fighting a major crisis elsewhere, they might not be able to implement the page at all and you are left with nothing usable online for your campaign. So, be more diligent in how you break down the tasks and what you expect from each person at given times.
The rituals involved in Scrum are not used in Kanban. It, of course, depends on how well planned the backlog is and whether the team members are able to work efficiently in this method without regular team meetings. But they are not key to the methodology like in Scrum. The key is having a well-prioritized backlog, limiting the amount of work in progress to move it efficiently through the stages, and making sure people work on the next highest thing in the backlog and not just on tasks they feel are easier. It is really important to stress limiting the work in progress. It is the single most important way to control delivery discipline in Kanban. By allowing only x number of tasks to be in certain stages at any one time, you are effectively encouraging the completion of tasks before starting a new one. It makes sure that you have an iterative approach, that tasks are adding to the overall value, and the final campaign is evolving in a timely fashion.
Scrumban
And now for the Scrum and Kanban lovechild, Scrumban—a mixed-methodology approach drawing on elements of both approaches. Scrumban combines the Sprint idea with the workflow idea and draws on some of the ritual meetings to ensure the team is working efficiently. If we look again at the example above, items are moved through the workflow stages as in Kanban. Highest priority tasks are worked on first and the Team Leader needs to control the backlog to make sure it is prioritized properly at all times. But in this methodology, teams work in Sprints similar as in Scrum. So, if the top priority is again the Landing Page Content (you might need to break this down a little more depending on the length of your Sprint), then this is moved to "In Progress" and worked on by the content writer. The Sprints in this sub-method are more of a time box for checking work done and work in progress. It is perfectly fine to take new tasks from the backlog and add it to work in progress anytime during the Sprint. Similarly, it is ok if the tasks are not completed within the Sprint. But Sprint review meetings occur to determine what has been delivered and to review if the team is working efficiently or not. This takes the principle from Kanban of continuous improvement without needing to have a shippable product ready in each Sprint, but takes the Sprint approach to managing the delivery discipline and focus of the team.
Scrumban draws on some of the rituals of Scrum but the meetings don't take place as often. The planning meetings only need to happen if there needs to be a change in focus, otherwise team members can take new tasks from the backlog as they are prioritized by the Team Leader. The review meeting, as mentioned above, is used regularly to check on the delivery discipline and schedule for the final outcome but not to determine if tasks were closed in the Sprint, like in Scrum.
The Good, The Bad, and The...
So which sub-method did we choose? The answer, none of them! Firstly, because we didn't actually know all about them, and, secondly, because these sub-methods evolved in Development and they are not perfect for Marketing. I started loving the idea of "bending the rules", because we didn't have any other choice.
Scrum, as I explained it above, is probably the most likely to work. But how many internal marketing teams do you know of that work on just one project at a time? And especially a team of 20 people. At a guess, I would say we work on three to four big projects, five to six smaller projects, 10 ongoing tracking and analysis tasks, and probably another three to four tasks for other departments at any one time. Now that is not so easy to work with in a Sprint. And the example I gave is actually one of the few where I could make the steps fit to Scrum because many other things we do just don't work. Creating a whitepaper, for example—remember Scrum should deliver "usable value" in each Sprint—is almost impossible with this method. If, in a given Sprint, you managed to research and write half the content and create a visual style for it, what value does that deliver to the end reader? None! You can't publish half a whitepaper. And we found this to be the case for many of the things we do. Now, you can argue the point that the "value" can be internal value for the team too. That creating the content is a prerequisite for the rest of the campaign, and that is absolutely true. But in 90% of cases we come up against, that is what happens, and the true value doesn't exist until the final date, which is then moving towards the Kanban sub-method of continuous improvement rather than the true Scrum sub-method of continuous delivery.
From there, you could probably say that Kanban is going to work—a prioritized list of tasks that is continuously worked on that keeps adding additional value to previously completed tasks. But remember, in Development teams, a lot of people have similar skill sets and, therefore, each person can work on the next highest priority task. In our Marketing team, and I imagine in most, we have specialists in many fields. One specialist wouldn't be able to do the work of another and so some priority tasks are often skipped as there is nobody available to do the task. Then, if there are tasks for another specialist further down the list that are reliant on some skipped tasks, you won't be able to complete them. The level of control needed is not present.
So let's mix them and go with Scrumban. Yes, this can work. Take the Sprint level of control over the task delivery with the more flexible nature of workflow stages. I must admit, this is probably my preference of the three but it is still not perfect. The issue still exists as in the whitepaper example in Scrum. Delivering "value" within the Sprint is sometimes just downright impossible for Marketing.
So we had to bend the rules. We use a backlog to see what tasks we have and we prioritize them and estimate their difficulty. We use Scrum ritual meetings to try to groom, plan, and review tasks as well as make our way of work more efficient. We try to stick to Sprints, in terms of the length of time to deliver a task. But we combine it with a workflow nature in many instances. We know that the whitepaper is going to take a number of weeks to write, to do the graphics, and to start promoting it. None of those things will deliver "value" on their own within a Sprint, but combined together or moved through workflow stages—content writing, proofreading, graphics, final review, publish, promote—they will lead to a perfectly good campaign. We also have specialists, as with most Marketing teams, and everyone can be working on multiple campaigns at once. So as a team, we can't always complete the pieces needed to deliver value in one sprint as one specialist could have a higher-priority task elsewhere in Marketing.
We're Not Perfect, But We're Agile
It is all about taking the best of each method and making it work for us. People will tell you that you can make Agile and one of the sub-methods work in Marketing. That if you take your time, learn how to do it, meet, plan, talk more, and give it a go, you will be able to work within the guidelines. But is that what you want? To spend your time trying to adjust how you work to fit Agile? Not for me. Agile should help your way of work. So take the best of it and use it to your advantage.
Despite the custom-tailored process that we have taken, we're agile now. We can swiftly adapt to new urgent changes, even if it means to stop working on a long-term item. We are prioritizing our tasks in a more granular level and higher priority tasks at top of the backlog can be worked on. And if something arises that needs urgent attention, we can stop the current sprint, archive the long-term work and start working on it right away, which, although should be a rare occurrence, can happen and is after all, what Agile should help with—being efficient and doing tasks that will bring the highest value.
In the third and final part of this blog series, I will speak more about the actual tasks, the meetings, the team structure, and more that will hopefully shed even more light on what it means to be an Agile Marketing team. In the meantime, feel free to share your thoughts. How did you go about implementing Agile Marketing in your team? Did it work for you? Have you stuck strictly to the guidelines?