Marketing Gone Agile — Wrangling the Chaos

Part 1 — The Roadmap

Created by vectorjuice — www.freepik.com

Marketing and development in many organizations have a symbiotic relationship — but it is a relationship where each party has little understanding of the other.

Marketers live in a world that is constantly changing and they need to pivot and respond quickly to social trends, customer needs and company initiatives. To perform their jobs, they rely on software tools that require skilled technical knowledge to create and implement those tools. If those tools are unavailable or buggy their job becomes difficult — if not impossible.

Developers on the other hand, live in a world that cannot pivot as quickly. Building and implementing tools require time to research and develop, while also working within the constraints of their tech stack and budget. When faced with an avalanche of urgent requests from marketing, developers often resort to quick code fixes or 3rd party tools that just contribute to the tech debt and buggy, inefficient platforms.

How do teams break this vicious cycle?

I’m not entirely sure, but my team and I are attempting to find out by relying on a popular software development process.

Let’s Scrum

Scrum is an agile framework for teams to work together by self organizing, learning from experiences, and reflecting on wins and losses. Scrum incorporates a series of processes performed at regular intervals that the entire team adheres to. These processes focus on developing products in a series of iterations called “sprints,” that break down big, complex projects into bite-sized pieces. This methodology is frequently used by software development teams, but it can be applied to any type of team.

With that dry explanation out of the way, the question is, how are we going to pull it off?

There are many guides and books out there that outline the nuts and bolts of scrum for marketing, but implementing the process — especially as a small team within a larger organization with its own procedures — could prove to be more challenging than what many guides describe.

My current team is a marketing platform development team that provides development on CMS platforms, landing page builders, email marketing platforms, and any number of standalone apps that may need to be created to support a marketing campaign or initiative.

Often we find that many of the conversations that happen in regard to new applications that need to be created, or existing technology modified, are happening in a silo — we are unaware of the need until it is dropped in our lap with little time for development. Priorities often shift with little warning, projects that we invested many hours of development time in are scrapped with little communication as to why or whether the work will continue at some point. Frankly, it can be utter chaos.

Get Outta That Silo!

Our first step was to try to remove some of the information silos. Individuals like our content strategist and UX designer are often at the initial campaign kick-off meetings — so why not make them integral to our scrum process? They work with strategy to define project requirements and manage expectations, so it makes sense to have those individuals serve as “product owners.” Our goal is not to give them additional duties but to help them by keeping the lines of communication open. They will be added to our sprint planning meetings, create backlog items for upcoming projects and us developers can give advice and information that can help them manage stakeholder expectations.

It’s a Sprint Not a Marathon

The next step was to define the length of our sprints. We decided that a two-week sprint would work well with the type of projects we manage and the cadence with which work tends to cycle in and out of the department. In addition, we needed to decide how to determine how much work we can actually fit in a sprint. We decided that using the scrum point system would work well for us as it gives a rough estimate of time, factors in vacations and team capacity, and allows the flexibility to pivot when the inevitable emergencies crop up. The goal is to tackle those short-term and last-minute projects while maintaining a commitment to longer term projects and elimination of tech debt. It will likely take several sprints to determine what our actual capacity is.

Who Did What Now and When Did I Do That?

Lastly, our final step is to tackle accountability. (Cause we all love that!) What tool do we use for tracking the sprints, creating tasks and assigning points? How do we define progress and efficiency, improve our processes and learn from past mistakes? For this we need some type of tool to track all our individual work tasks and store documentation.

There are many agile project management tools on the market, such as Jira, Asana, Workfront — all with a good reputation for managing an agile workflow. Our division as a whole uses Workfront, so this is what we will be using for our task management and documentation. But, no matter how many features and tools Workfront offers, it is only as good as how well our team uses it. It requires all of us to use it consistently, by tracking each task through its different phases of development as well as using the software as the primary tool for communication. Maintaining regularly scheduled planning and grooming meetings as well as sprint retros will provide those opportunities to keep each other accountable, as well as acknowledge the things we are doing well at and learning from our mistakes.

So! That’s our game plan for reigning in the chaos. It is going to take some patience, lots of teamwork and cooperation from our leadership to make it work, but I think we are moving in the right direction.

Stay tuned for Part 2!