Home » Posts tagged "marketing" (Page 7)

The other day I had lunch with Sarah from Unruly Media. We had a great conversation about agile methodologies, in particular agile in marketing. She certainly knows her stuff around agile – her company (of which she is a co-founder) started out in a very different place from where it is today but as the whole company was founded on agile principles, they pivoted to becoming a 100 person company across multiple countries selling a social and viral video enablement software to media agencies and their clients.

Sarah asked a really interesting question that I thought gets to the heart of why marketing should be agile. She wondered, if we already have plans for marketing, in a way we don’t necessarily have for other departments, like number of events or case studies per quarter, why do we need to break marketing’s task down into smaller stories?

My personal answer to that question has to do with the agile idea of continually adding value through numerous small releases. A marketing department can easily spend the quarter working their butts off to produce one fantastic event, however there’s really only one point at which the team delivers business value to other departments or customers – the day of the event. What if agile allowed marketing departments to turn that single event into a series of releases that added value to the business?

By breaking larger tasks down into small stories, each with the aim of adding value to the business, a marketing department can do two things. First, they can see where they need to focus their time in the lead up to a big event (or whitepaper release or new website launch, any activity works here really) because they’ve defined their stories in a way that helps the team understand where they are adding business value. Secondly, they can use these smaller yet valuable “releases” within marketing to delight customers and other departments more regularly throughout the process.

Let’s take, for example, hosting an event for new and prospective customers. One could easily argue that this project is only fit for a waterfall style release (you work on everything until it’s all finished then release all at once) and there is no way to deliver value to the business from this project until the event actually happens.

But look at the assets produced for that one day – handouts, speaker bios, marketing materials, case studies, training documents, video footage, email comms to attendees and event promotion. Why shouldn’t a case study be released to the sales team as soon as it’s produced, delivering value to their sales process? Couldn’t speaker bios be turned into blog posts showing your company’s involvement in supporting individuals in the industry, delivering value to your readers? Post video footage on YouTube early, make marketing materials the content basis for your Tweets, allow sales or support to piggy back on email comms – and most importantly show your company and your team how marketing is continually adding value.

The upshot of this is that marketing gets the recognition for the ongoing work they are doing and the company gains the momentum that comes with having continual access to new marketing and sales materials throughout the quarter.

Do you agree? Why do you think marketing should even bother with being agile?


Before getting started with an Agile methodology for our marketing team, we had to make some decisions about how to prioritise our stories, sprints and workloads. The first step was to decide what was really important in terms of the actual marketing channels, the objectives for each channel and the metrics we cared about.

This led to the creation of our Marketing Priorities Venn (shown below). Three circles for our three primary areas of focus – content, inbound lead generation and research and CRM management.

Marketing Channels Venn

Anything that didn’t fall into one of these circles or their overlapping areas was out – there would be no stories in our sprints that didn’t fit in our Marketing Venn. Although the Venn might seem quite all encompassing, it was an eye-opener to see what tasks we had undertaken in the past that didn’t fall under any of our key channels, often related to supporting other departments or doing unnecessary admin.

But it wasn’t enough just to know what we should be doing – we needed to have a clear picture of why we were doing it so that stories could support the overall objective of each channel and iteratively drive us towards reaching those goals. Therefore we added a second Marketing Venn to illustrate the objectives for each channel – allowing us to eliminate stories that matched a channel but didn’t support our key objectives.

Finally, we wanted a way to understand how well we were achieving our objectives and created a final layer to the Marketing Venn with a list of marketing metrics that were relevant to each channel. The metrics list we fully expected to change over time as we determined which metrics were most relevant in helping us recognise our objectives but as a first pass we wanted to be sure that there was a quantitative way to assess the success of our work.

I’ve found the Marketing Venns particularly useful in deciding what stories to write in our upcoming sprints – not only does a quick glance remind me of our priorities but it also helps to ensure we have an even balance of work across all parts of the business for which we as marketing are responsible.


This is Part II of Challenges in Setting Up an Agile Marketing Team. Part I is available here.

Challenge: Measuring and assigning points to marketing stories

Agile is a great method for quantitatively measuring productivity because each story is assigned a point value. The sum of points from all stories completed during a sprint defines the team’s velocity. This velocity should be fairly consistent week on week and any sprint plans for the future shouldn’t include stories with a point value higher than the current velocity. Within a development environment, when, generally speaking, product developments are all created within the same framework (a programming language) with varying levels of complexity, the point values are relatively easy to define – a more complex project, requiring a greater knowledge of the coding language, is worth more points.

On the marketing side, however, assigning point to stories has been a real challenge. There is no consistent measurement of complexity across the very different types of projects we undertake – for example is designing a lead flow process for lead nurturing more or less complex than generating a detailed report analysing dead leads over the last six months? And if we can’t consistently evaluate complexity, should we use time to indicate point value – so should a very simple, repetitive task that takes an entire afternoon be worth more points than a task that only takes half an hour but requires a significant level of expertise? Should points indicate seniority – tasks that require executive sign off getting a higher value than those that do not?

Where We Are Now:

This particular issue hasn’t entirely been resolved. We’ve tried a number of different ways of measuring the point value of tasks but have resorted to ‘gut feel.’ We assign points as a team, during our sprint plan, so there is a check and balance but it’s not a particularly scientific process. This has been reflected in a somewhat inconsistent velocity – although we’re in the same ballpark week on week, our velocity doesn’t have the fixed value we’d like to see. Generally points are based on a combination of the perceived complexity of the task, the amount of time it will take and whether or not other resources are required from outside our department. Hopefully this process will become clearer.

As a side point, we used the same point values as our development team – 1, 2 or 3 points as the only options. Given the different variables we need to take into account and the inconsistency of measurement, we might find it easier to get a lock on our velocity with another scoring system.

Other Challenges:

A couple of other challenges that we considered before starting with Agile:

–        Abundance of ‘chores.’
Chores are stories that don’t deliver any real value but must be completed. Some examples are following up with the winner of a competition, cleaning email lists or unfollowing irrelevant accounts on Twitter. Chores in our sprint plan give the appearance of productivity without any value-add to the department, and makes it more difficult to accurately measure our velocity (chores don’t get any points). We tend to have a lot of these within marketing and are working to tie these in as tasks related to proper stories, rather than just stand alone stories without value.

–        Lack of resources and skills for partner work
Many Agile teams recommend having paired teams of workers complete stories together. While our challenge is based more on the siloed skills sets within our team, our small team size and general need for speed has deterred partner pairing as well. However, we’re lucky enough to have some fantastic interns working on the marketing team and although they are not generally part of the sprint plans or responsible for stories, their support helps us recognise some of the value of pair work.

–        Reliance on other company departments
Within the development team, much of their work is self-contained however in many cases, our marketing team requires support from other departments to complete a story – whether that’s a product release from dev or testimonials from support. Reliance on other departments makes planning stories incredibly difficult because if we don’t get what we need from the other parts of the company, the story can’t be completed. We haven’t found a great solution for this one yet, although we have tried to write fewer stories that require outside resources and if one is required, create a chore to request the resource, then a story only once we’ve received what we need.

So, as you can tell, numerous challenges although it’s been an important process to think about these because they affect the team’s output regardless of the methodology we’re using. Agile has helped to highlight some of the ways we can improve and given us a framework for doing so.

Next post will be about how we prioritise work, define projects and write stories.


So we had decided to commit to an Agile methodology for our marketing team based on the reasons I’ve written about already (quick overview; ability to prioritise work, to be more flexible in responding to campaign success or failure, to get more out of our small team and to better understand our actual productivity levels). However just because we had decided we wanted to go Agile doesn’t mean that the process happened over night. In fact even before we got started, I sat down and made a list of all of the challenges that would affect us in moving to this new methodology.

Some of these issues we were able to address before starting with Agile, some we needed to work through in the first few months of using Agile and some are still not satisfactorily resolved. There were, in fact, so many challenges to write about that I’ve broken this up into two blog posts.

Here are some of the challenges I expected we would face in using Agile for marketing:

Challenge: Individuals were already responsible for clearly delineated types of tasks within the team

We only have three full time members of the marketing team and although the size isn’t necessarily a deterrent to using Agile, the way we had organised the team was. Each of us were general responsible for diverse tasks – one of us for content and social, one for lead research, qualification and management and one for inbound lead campaigns. Although there was some overlap, we had siloed ourselves.

Tasks within Agile sprints, called stories, are generally meant to be relevant to anyone on the team – because stories are prioritised by importance and everything needs to be completed within a sprint, if a member of the team finishes their story, they should pick up the next story in the sprint, not just the next one relevant to their expertise. If we had a sprint with a dozen stories related to content, but only one or two related to inbound lead generation, what would that mean for our division of labour? Would we have to plan sprints based on equally allocated stories (thus letting our individual skills drive our sprint plans more than actual marketing department needs)? If we did try to create sprints with stories for each member of the team, how would that be different that just creating our own individual task lists?

Where We Are Now:

As it turned out, we did end up planning our sprints based on individuals within the team bringing their own tasks to the weekly sprint plan. However this had an unanticipated benefit. It meant that many of our projects were truly iterative – the person responsible for the story one week had a clear picture of how they wanted to bring that story to the next level, or add value to the ongoing project through work they had already accomplished, and were therefore better able to define a related story for an upcoming sprint. Had different individuals been responsible for different parts of a marketing campaign, a lead research project or a white paper, for example, then the overall vision of the project, despite being well articulated to the rest of the team, might have lost some of its clarity and focus.

Additionally, we have started to reach a point where certain stories are completed by someone who didn’t initially expect to do them. Usually this will happen towards the end of the week when we’re reaching the end of the sprint plan and there are just a few stories to go but it’s been a good experience and hopefully will lead to even more flexibility within the team in taking on, and successfully completing, stories outside their immediate comfort zone.

Challenge: Numerous ongoing or daily tasks without a clear end date

Within the marketing team, unlike what I’ve seen of the development team, we have numerous ongoing and daily tasks that I thought would prove difficult to fit into a sprint plan. In terms of daily tasks, our team generates a daily pipeline report for the sales reps, deduplicates the leads in the system, and produces daily stats reports. Ongoing tasks include the management of the company Twitter and Facebook accounts and qualifying leads for the sales reps.

How would these tasks fit into our sprint plan? How could we define a story within a sprint when the story never ends?

Where We Are Now:

When it came to daily tasks, we decided that we would not include these in any of our sprint plans. One of the benefits of Agile is the ability to quantitatively measure the productivity of the team – and this can be used to plan realistic sprints in the future. By taking out daily tasks, we knew that there would be an element of our work that we didn’t track but that this would be consistent – the same projects take the same amount of time every day so it wouldn’t affect our ability to plan sprints in the future. As a side point, the majority of these daily tasks are admin busy-work that will hopefully at some point be replaced by software services so it’s even less desirable to track them as part of our sprint plan.

In terms of ongoing tasks, however, we had a greater challenge. There was much less consistency in the amount devoted to these projects each week so it was important that we could measure how much time was spent and, more significantly, what we actually produced. With that in mind, we made it a goal to break down ongoing projects into individual tasks, sometimes even at the expense of the ongoing project as a whole. Take for example an ongoing project to manage our Twitter account. This might become one or two stories within a particular sprint, with one to schedule daily Twitter content at the beginning of the week and the other to follow everyone on a relevant Twitter list. While this may not deliver exactly the same value as sitting in front of Tweetdeck responding to all relevant comments, it’s a clear measureable that raises improves our Twitter presence and doesn’t do so at the expense of resources or other sprint stories.

I’ll leave it at that temporarily as there are numerous other challenges we’ve faced but with the aim of keeping this readable, I’ve split this into two posts. Part II will be available shortly.


For the last ten weeks, our marketing team has been attempting to organise ourselves, our project plans, and our internal reviews through an Agile methodology. I’d like to write about this process so far, some of the challenges we’ve faced and some of the successes we’ve experienced. I first want to give a background to Agile and why we decided to use a project management method designed for product teams in our marketing department.

Agile, a methodology initially created for use in product development teams, is a project management methodology that is based on very short project cycles, sometimes called sprints, that build iteratively upon each other. These short project cycles not only allow the team to release smaller updates more frequently, continually adding value to the overall product or company, but also mean that the team has the flexibility to respond to changes within the company, economy or competitive environment quickly. The iterative nature of the process means that projects are not stand-alone tasks, but clearly defined pieces of a larger end goal. A product release that might take a large team four months under a typical project plan, with one single release at the end and no room for flexibility throughout the project can, with Agile, turn into eight small sprints, with a value-added release every two weeks and a shift in product design in week eight to incorporate a critical customer request.

Although I had been aware of the basics of the Agile methodology from working at IMVU and reading related books and blog posts on the subject, I didn’t really get a chance to see and understand Agile in practice until it was adopted by our development team. The changes were immediately apparent, even before the Agile method was fully adopted by the team (the whole transition process ended up taking a number of weeks).

The first thing I noticed was the change in how the development team reacted to feature requests and bug fixes. Their response changed from “ok, we’ll see what we can do,” to “we can prioritise that for the sprint after next.” While for someone from the service team with a bug to report, or someone from sales with a feature request, this felt like an exceptionally long wait, what we actually noticed was that instead of being overwhelmed by incoming requests that didn’t get prioritised and therefore would sometimes get missed, every important fix was addressed within a reasonable timeframe while not distracting the engineer from the truly value-add developments that would drive the product forward. They changed from a reactive department to one that was able to clearly plan their work and reach those pre-planned goals week on week.

I wanted that for our marketing team.

We were the very definition of a reactive department – setting campaigns aside to deal with “I need it NOW” lead or content requests from the sales team, or to jump in and help the service team produce marketing materials and reports for our clients. What I saw in our development team, even before truly understanding Agile, was a way to change the marketing team’s reactive behaviour and go on the offensive in terms of planning, reaching department goals and moving the overall bar without either getting completely distracted by internal office requests for marketing’s time or neglecting the needs of other departments.

As I learned more about Agile I saw other ways that the methodology could support our marketing goals. The iterative process would help us make decisions about what campaigns were working, or not, before continuing to produce content for those campaigns. The short sprints would force us to define deliverable projects that we could actually accomplish with our small team. Finally, the planning and review process within Agile would give us a much clearer picture of the work we were accomplishing week on week and give us tools to measure that output in order to define realistic plans for the following weeks.

So, going into our first week of Agile, our goals were to:

– Prioritise our work, and incoming requests from other departments, more effectively so that we are not just a reactive team but moving forward with our own projects and goals.

– Break larger campaigns and projects into smaller ones so that we’re delivering value weekly but have the flexibility to change or switch campaigns if necessary.

– Get the most out of our small team by defining tasks and projects that deliver value but can be realistically accomplished with our given resources.

– Have a better understanding of what we are producing and achieving, have a way to measure that productivity, and use that measurement to better define our tasks and goals for the future.

Next I’ll be writing about the challenges we faced going into an Agile methodology as a marketing team, even before we started working Agile.