The Top Floor Flat

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.