Tue 27 Jul 2010
10 Steps to Successful Marketing using Agile and Lean Practices
Ah, Marketing. Enter a world of countless project requests, numerous stakeholders, limited resources and rapidly changing market conditions.
Sound familiar? In fact, marketers face a lot of the same challenges as development teams, and Agile can be a powerful way to alleviate those common issues and intelligently plan our work.
In steps 1-5, I’ll explain how Rally’s marketing team conducts our version of Release Planning. In steps 6-10, I’ll explain how we run our iterations to meet those commitments. Our planning processes continue to evolve, though this method has worked for awhile now.
10 Steps to Successful Marketing using Agile and Lean Practices
1. We recognize that Marketing has challenges that are different from Development.
- There is no unique product owner. For example, if we chose Sales, then we would always rank lead generation over branding, customer programs or analyst relations, and that could ultimately hurt our company. Therefore we have to use some best-guessing to prioritize our backlog and determine what is most important.
- We face hard event deadlines set far into the future. Sometimes we have no choice but to commit to an event or sign a contract months ahead of time.
- Each team member has unique expertise, i.e. writing, event planning, PHP development and so forth. So one shared backlog is inefficient.
Now that we’ve reviewed the challenges, we give ourselves permission to do what we need to do, have patience and adjust anything that isn’t working for us.
2. Conduct an ORID to learn from the past
Before planning for the next quarter, we hold a retrospective in the form of an ORID, “a means to analyze facts and feelings, to ask about implications and to make decisions intelligently”, a process created by the Institute of Cultural Affairs. We gather as a team to share:
- Observations (O) – What do we know?
- Reflections (R) – How do we feel about this?
- Interpretations (I) – What does it mean for the organization?
- Decisions (D) – What are we going to do?
This strategic overview helps set context for us to prioritize our focus for next quarter.
3. Align ORID decisions with company strategy
At Rally, we conduct quarterly and annual planning using the Plan Do Check Adjust methodology as explained in Getting the Right Things Done. As we look at the overall company direction and goals, we keep these in mind as we hold planning at our own level. Ideally, our major commitments support and align with company strategy. This also helps inform our “stop doing” list.
4. Poll our stakeholders
As part of determining quarterly commitments, we poll our major stakeholders for their top requests. We use a Google survey to rank these requests by importance, size each request and bring these epics into our release planning meeting, to be included as part of our ranked backlog.
5. Conduct Release Planning to prioritize and agree on quarterly commitments
Now that we have all of our inputs, we hold our quarterly Release Planning session. We write each epic on a sticky note and look at all of the possible work we could do this quarter. Then, we evaluate epics based on importance taking company goals, stakeholder wishes, market realities like conferences and our own passions into consideration. We decide what we can realistically commit to, and agree as a team. We keep in mind that making and meeting commitments is a huge deal, and we try really hard not to over-commit.
Part 2 – Meet our Marketing Commitments
6. Create a task board
Since our marketing team is mostly co-located, we pin up several large sheets of paper to use as a task board. This is where we review our commitments on a daily basis as a sanity check that our stories are prioritized correctly and that we are tackling the right work as the quarter progresses.
As a team, we write our quarterly commitments on the task board with the definition of done assigned to each one. We also include our “foundational” work – recurring work like website updates, online ad campaigns, field events, press releases and other important work that we need time to do.
Note: this is not a Kanban board because we do not have a shared backlog nor do we have a team-wide WIP limit. As we break into smaller project teams that do share a backlog, we often use AgileZen to manage this work.
7. Hold iteration planning every 2 weeks
Every 2 weeks, we hold an Iteration Planning meeting. Each team member has her own sticky note color, creates stories on those notes and manages her own prioritized backlog using T-shirt sizing to roughly estimate each story. In this hour-long meeting, we begin by expressing appreciation for team members who gave exceptional assistance. Then we hold a brief retrospective on what worked and what should change for the next iteration. Finally, we each read out our prioritized stories for the iteration, putting them on the task board’s backlog. This gives everyone visibility to what’s happening, identifies if someone is over-committed and lets the team swarm any epics with looming deadlines.
8. Conduct a daily stand-up
At the same time each day, we hold a stand-up meeting (with a consistent conference call #) that is at most 10-15 minutes long. We form a semi-circle in front of our task board and share no more than 2 cross-cutting significant actions or take-aways from the day before, no more than 2 that we are planning to accomplish that day, and whether our work is blocked by any issues beyond our control. As we start working on stories throughout the iteration, we move them from the backlog into their section of the task board to show what we are working on. When the story is complete, then we move it to a place on the task board labeled “Done”. Once the commitment’s Definition of Done is met, we check off that commitment and feel good about completing it.
9. Be patient as things change
It would be lovely if nothing changed during the iteration, but that just doesn’t happen. The goal is ultimately to respond to change rather than cling to an outdated plan. As new opportunities arise, new time-sensitive information appears and new requests are made, so our iteration work changes and that’s ok. We try to just document what we’re working on and create new stories so that we can make intelligent prioritization decisions during the course of the iteration.
10. Retrospect, inspect and adapt
As we keep running our iterations and fulfilling our commitments, we are always looking for ways to improve them. Ultimately, we’re using Agile to improve the quality of our work life by using objective, smart ways of planning how we spend our time. And we’re learning a lot from the journey.

Jessica, Thanks so much for this empowering post on Agile marketing! In a company that has rapid Agile development cycles on the product side, it can be so tough for marketers to get into the rhythm of rapid adjustments. Longer-term planning necessary for events, ad contracts, etc. often get in the way. That’s why I love your #9 – patience as things change!
Anne – Thanks for your comments! I really appreciate the insights you and the rest of the team provide in terms of being comfortable with change, remaining flexible and open and willing to learn. I hope that others can incorporate this attitude into their team culture.
Spot on! On other aspect of agile marketing that has amazed me: As Agile marketing teams get into an iterative rhythm, we tend to see their often relied on external resources (think advertising firms, graphic designers, PPC vendors, media sales etc) fall into that same rhythm! You then have a highly leveraged, very agile marketing resource model – Magic!
Great post!
Okay Jessica, Anne and Dru – we want to visit and see this in action. This sounds like the answer to some of our own marketing initiative efforts. I’m figuring from Dru’s comment we’re participating in this as your partner – we just don’t know it. :)
James and I would now like you, Dru and Anne to come to our offices and walk us through everything you know. How can we make that happen? :-)
Jason and James,
Name the time and place and we’ll make it happen. I bet we could learn a lot from how your team works as well. Thanks for posting!
Great post. We do something similar here but with a little less formality and few additions.
First, we divide our work into various types of tasks and use color-coded cards to represent the task types. The primary types are Fixed projects (large, long-term, immovable projects, like conferences), Flexible projects (things we plan to do but can slip a few weeks if needed, like redesigning a brochure or completing a new whitepaper), Recurring projects (daily, weekly, monthly tasks, like social media updates or a customer newsletter), and Breaking News (unplanned items that inevitably arise from other teams but must be completed).
Our philosophy is that a marketing team is similar to a news organization. In the news analogy you have some weekly columns that must go out like clockwork and you have some larger editorial pieces you want to complete but can easily be bumped if a breaking news item like a fire happens.
So we color code our cards so that we can visually see what tasks cannot be moved and which ones can if a breaking news item occurs.
At the beginning of each week we plan out the next two weeks. On a daily basis we review / update the board during our stand-up meeting. Cards fall into one of four phases, Planning, In Progress, Peer Review and Published.
As breaking news arises from internal teams or outside forces (press releases, product updates, maintenance windows, etc) then we place them into the backlog and then depending on the urgency we discuss them in the stand-up and determine the Story/Audience/Channels for the breaking news item. We then write-up task cards and insert them into our timeline, perhaps moving some of the Flexible project tasks cards back to the backlog for future consideration.
Like the post, and there some great insights. One question though. Have you noticed any bad outcomes wrt to individual accountability and long term vision since each team member maintains their own backlog w/o a product ower? If so have you designed any techniques to account for this? I see that you mention the shared task board which help identifies bottlenecks/overcapacity, but has that been enough?