When marketing teams transition to agile project management, the effects are often felt outside of marketing. Usually sales is the first to protest – “It’s just a small request” or “I know its last-minute, but you’ve always helped me out before”. The product owner can help set expectations, but it’s up to everyone on the marketing team to retrain stakeholders. Below are some sayings we’ve learned to embrace.

“We’ll put it in the backlog.”
This has become the marketing team’s mantra, but when we began our agile adoption, it was hard. We all like helping people and it’s not always easy to say no. We had to realize that saying “we’ll put it in the backlog” wasn’t “no,” it was saying that we acknowledge your request and it will get prioritized in consideration of all of the other stories in our backlog. We still catch a little flak from time to time, but overall, it’s had the most impact on our productivity.

“You’ll need to go to our product owner.” 
In the past, people were used to going to individual members of the marketing team and making requests – especially a few of our executives, who will remain nameless. They weren’t trying to go behind the product owner's back, often it was just easier to go directly to the person who would most likely be doing the work. This caused the team to work on projects outside of the iteration, and not complete stories that were already committed to in the iteration. The only way to stop this was to have all requests go through the product owner – which they should.

“Is this a higher priority?”
Agile processes are all about embracing change, so when requests come from outside of the department, it’s important to understand if priorities have changed. This is usually handled by the product owner but needs to be understood across the agile team.

Just like with puppies and kids, consistency is crucial. Don’t give in “just this once”. It sends the wrong message to stakeholders and will cause you more pain in your agile transition.
 

When you’re starting your transition to agile project management (no matter what department you're in), don’t try to do everything at once – it just doesn’t work. When our marketing team decided to really start practicing agile we wanted to go all in. We failed miserably, even though we were set up for success in every way – we had buy-in at every level, the entire team had gone through ScrumMaster training. Hell, we were even marketing an agile software development tool. 

One of the first mistakes we made was trying to emulate our development team, who has practiced agile for years and had been working together as a team for a lot longer than we had. We figured that if it worked for them, it would work for us. As we’ve matured as a team, we have been able to incorporate a lot of their best practices, but it was just too much to bite off all at once. You need to build a solid agile foundation first.

Our next mistake (believe it or not) was trying to use our own tool to manage our projects. We had no problem messaging to prospects that a tool wouldn’t magically make them agile, but we weren’t following our own advice. We got hung up on all the bells and whistles of the tool before having a good handle on basic agile principles. We had to take a step back, and use whiteboards and sticky notes to manage our first few iterations.

We also made the mistake of trying to plan too much into our iterations. We were already behind on almost every project, and we assumed that agile methods would immediately make the team more productive. Even though we knew better, we didn’t take into account the drop in productivity that inevitably happens when you change the way you work. When we didn’t close out most of our stories in an iteration, it felt like we were falling further behind. Looking back, we were setting ourselves up for failure.

We finally realized we needed help with our agile adoption. Fortunately, we have access to in-house agile coaches. They helped us to slow down and transition iteratively. The team focused on a few important stories each iteration (we called them our big rocks), got into a standup rhythm and established team norms. Next we tackled tasking out stories and getting better at estimating. Now we’re working on fine-tuning our processes, but we’ll never really be done with our agile transition.

Just like most agile terms are defined in the context of agile software development, so is advice on how to overcome common agile challenges. Below is a list of a few agile marketing challenges we've dealt with, and some ideas on how to manage them.

Non-repeatable Work
Sometimes the work associated with a story can’t be used again – in software development projects, this might be considered technical debt. In marketing we tend to call them one-offs. The challenge is how to prioritize, plan and manage stories when the work is for one-time use. Obviously, eliminating (or limiting) one-offs is ideal, but not always practical. To address thes effectively, we first determine whether there is anything we could repurpose: The graphics are good but we need new content, or this was used in a partner campaign and with a few tweaks it could work for our direct sales team. Then we evaluate “bang for the buck” – if the project delivers enough value, it’s a go. Finally, we try to limit the scope of the project – just because we can, doesn’t mean we should.

Manual Processes
As in agile development projects, eliminating or limiting manual processes is ideal, but not always practical. Weekly campaign reporting was taking up a lot of time for some team members, because most reporting was manual. After doing a little digging, we realized that our product owner wasn’t really paying attention to weekly stats but found more value in monthly trends. We still look out for significant changes week-to-week, but don’t waste time with detailed analysis if everything is holding steady. We’ve also invested in tools (or upgraded existing tools) that have helped us automate reporting.

Outside Dependencies
These often come in the form of fixed dates (conferences/tradeshows, third party content or vendor deadlines) and outside feedback. Most fixed dates are known in advance and can be incorporated into upcoming iterations. For big projects such as product launches, or annual conferences, you might have entire iterations focused on creating the deliverables for that project. Last minute deadlines are trickier and often involve scope creep or adding new stories to an existing iteration – both involve the product owner changing priorities and moving things out of the iteration.

Have tips or tricks for overcoming your own agile marketing challenges? We’d love to hear them.
 

When practicing agile project management, defining “done” is critical. It’s often the product owner’s job to define done in the context of value delivered to the business. Defining done in software development projects can be fairly straightforward – there’s even a checklist. But is any project ever really done on an agile marketing team? Of course you can always be improving your website or tweaking your messaging, but there’s a point at which you have to call one project done so you can work on new ones. On our agile team we’ve come up with some standard terms we use in iteration planning to help us define done.

Define
When we have larger projects (Epics), the first story is often focused on defining the project – who, what, where, when. We also use define when we’re unsure of the amount of work involved – also known as a Spike. Typically, define stories involve brainstorming or research, identifying tasks for future stories and uncovering any impediments that would prevent or delay the project. Define stories are done when the results/findings are reviewed with and accepted by the product owner.

Draft/Design
If the scope of the project is well known (i.e. we’ve worked on a similar one before), we skip define and start with drafting (messaging, content outlines, ad copy, etc.) or designing (sketches, mock-ups, wire-frames). These stories usually have feedback or review tasks that the story owner manages. Be aware of how many draft/design stories you have in an iteration to avoid overloading team members (we tend to do that to our designers) or having team members stuck waiting for feedback. Draft/design stories are done when the content and/or images are approved by the product owner.

Deploy
Deploy is pretty straightforward – it’s deployed (live) or at least deployable (able to be pushed live at any time). Deploy stories often also include staging, testing, proofreading, and final buy-in from the product owner. Be aware of how many deploy stories you have in an iteration (especially if they involve outside deadlines) so you can better coordinate work across the team. It’s also important to know upfront if projects require ongoing work, so you can define done for this phase and plan for additional phases in later iterations.

Not every story we work on fits neatly into one of these buckets, but it’s been incredibly helpful to have the entire team being on the same page when defining done.

As with a lot of agile project management concepts, understanding the value of feedback isn’t hard, it’s managing the process that can be challenging. In agile software development, gathering and managing feedback is traditionally handled by the product owner. In agile marketing, the product owner can quickly become a bottleneck (impediment), so on our team, story owners often take on this responsibility. Below are some Do's and Don’ts – these aren’t hard-and-fast rules but merely suggestions based on our team’s successes and the rat holes we wish we could have avoided.

Do's and Don’ts for Planning and Managing Feedback:

• Do add tasks in stories for feedback loops or review sessions to help track progress and identify potential impediments.
• Do try to keep the feedback rounds to a minimum (no more than 2-3) so you can actually get stories completed within the iteration.
• Do take into consideration who (inside or outside the department) may be providing feedback when planning stories so you can involve them early in the iteration.
• Do limit the number of people involved so that consolidating feedback is easier – we all know what can happen with too many cooks in the kitchen.

• Don’t plan too many stories in an iteration that require outside feedback – it’s easy to get stuck waiting around without much to do.
• Don’t wait until the last minute for feedback from outside stakeholders or the team - it’ll most likely just piss them off and you won’t get what you really need.
• Don’t incorporate feedback just because it came from someone “important” – if it’s a good idea, go for it but don’t forget to “put your marketing hat on”.
• Don’t just go through the motions of asking for feedback and then not follow up – no one likes to feel like their time was wasted.

Have your own feedback Do's and Don’ts? We’re always looking for ways to improve our agile processes.

Pretty much everyone outside of marketing thinks they could be in marketing, and they often think every idea they have is the best ever. Sometimes the best ideas do come from outside of marketing – so do some of the worst. Embracing the agile project management concept of getting feedback early and often can be challenging in marketing but extremely valuable. The trick is asking the right people for the right type of feedback at the right time.

Who are the Right People?
In agile marketing, as with agile software development, getting feedback directly from your target audience (i.e. customer) is always ideal. If you don’t, it’s important to have someone represent the customer – especially when the team is working on a highly visible project (ad campaign, major website changes, new product messaging, etc.). Other stakeholders from sales, support and training can also provide unique perspectives and great insights. Don’t forget about your team members. Your team is a great resource for feedback – they should be sitting right next to you and often know the larger context of the project.

What is the Right Feedback?
Getting the right type of feedback relies heavily on asking the right questions. The more specific you can be, the more focused (and potentially valuable) the responses will be. Your target audience can help with things like determining key messages (what are the most important benefits) and how to present them (what’s the best way to deliver the content). Stakeholders often help determine requirements, so getting their ideas on what might be missing or overlooked can often be valuable. Team members are great for brainstorming, narrowing down ideas, consistency, and are especially helpful when you just get stuck.  

When is the Right Time?
Timing often relates directly to who is giving the feedback and what type of feedback you’re requesting. Brainstorming upfront with your target audience can help ensure you start in the right direction, and closing the loop before your deliverable is final makes sure you didn’t miss the mark. Including stakeholders in the process up front for requirements, and again once ideas are thought out (but before they’re final), can help gain buy-in. Getting feedback from your team along the way can help you continuously improve the end product.

Just because you ask for feedback doesn’t mean you always have to take it. Our product owner likes to tell us to “put on our marketing hats” when trying to determine what feedback to use. The next challenge is managing the process so you can actually get stuff done in the iteration.
 

At first, agile project management can seem like numbers game. How many people on a team? How long is an iteration? How many points for a story? What should our velocity be? But it’s not the actual numbers that are important, it’s figuring out what works best for your team and getting into a rhythm.

Team Size Matters
Too big, and one of your main impediments will be just getting through iteration planning. Too small and you may not have enough resources on the team to get much done. But what is too big or too small? The rule of thumb in agile development is 7 plus or minus 2. I think it works well for agile marketing too – if you have less than five people on your team, don’t worry, just try not to split larger agile teams into very small groups. We’re getting to the point on our team where we’re starting to consider the pros and cons of splitting into multiple teams or staying as one. It would be easy if there was a natural split (front end UI versus back end database, or along product lines), but we tend to share all kinds of work across the team. Nor do we have the equal distribution of skill sets needed to split the team down the middle. One thing I would caution against is sharing members across teams – this has a tendency to create bottlenecks, and provides an easy scapegoat for when stories don’t get closed.

One Week, Two Weeks, Three Week, Four?
Determining how long to schedule your iterations can be tricky. One week is rarely enough time to take a marketing project from start to finish (at least for us), and four weeks can be overwhelming (and not always practical) from a planning perspective. We had the luxury of having in-house agile coaching to help us settle on a two-week fixed iteration. Two weeks allows us enough time to complete work and account for changing priorities, without feeling like we’re constantly starting and stopping. But don’t take my word for it – try different iteration lengths on your marketing team. The import thing is to find what works and stick with it.

1 Plus 1 Doesn’t Always Equal 2
Much has been written about estimating so I’m not going to get into the pros and cons of story points versus ideal days versus shirt sizes. What I will say is that marketing projects aren’t always repeatable – we tend to like to try new things – nor can they always be comparable. Something that is “easy” might take days to complete or involve multiple team members, while something that is “complex” might be done in a few hours by one person. One thing we’ve started to do in our planning meetings is to write down each story on a sticky note so we can visualize like-sized stories together. It helps us determine if a story is a 3 or a 5 by comparing the work involved – it relies partly on gut feeling, but has helped us a lot.

No one can tell you what your velocity should be. It’s an individual team thing and pretty much has to be trial and error. It usually takes multiple iterations to stabilize your team’s velocity so don’t freak out when you get very little done in one iteration and a lot the next. Again, it’s all about getting into a rhythm.

Physical changes can have a huge impact on behavioral changes. The opposite is also true – without physical changes, behavioral changes can often be more difficult. Shared workspace is a principle of agile software development, and it's just as important to agile marketing teams. In order to get your team working closer together, you need to get them in the same physical space (more to come on managing remote team members). Get people out of offices and take down cube walls - it's worth the time and effort. An open workspace helps force team members out of their silos, and is the first step in creating a collaborative environment.

Even though open space is shared, it’s important to encourage agile teams to make it feel like their own. In our team room, we have 2 ½ foot walls attached to our desks that we’ve each decorated in our own style. We’ve added decals to the walls and even have a mini disco ball hanging from the ceiling. Our dev team makes fun of us, but secretly I think they’re just jealous.

Marketers love to have meetings, so set up a place in the middle of your team room for meetings. It’s also important to have a designated space for daily standup. It allows other team members not in the meeting to overhear what’s being discussed, and provides space for impromptu brainstorming/collaborating sessions. This makes it easier to stay tuned in to what’s going on with other stories, and allows others to provide valuable information and feedback even if they aren’t technically in the meeting.

Another important element in an agile team room is a visual information radiator (a fancy name for a storyboard or taskboard). It can be as simple as a whiteboard or card wall, or a more elaborate electronic version. If you have a designer on staff or you have a little money in the budget, this can also be a great way to add some creativity into the team room. But having a visual way to track progress during an iteration can make all the difference. It’s also a great way to keep standup on track by focusing the team on what they worked on yesterday and what they’re going to work on today.

Creating a fun, open environment sets the tone for agile teams and helps reinforce collaboration, a key agile tenet. And who better to create a kick-ass team room than a marketing team?

You can read a book about agile development or Google any agile term, and the definition will most likely be in context of an engineering practice or reference to code. The basic concepts in marketing are very similar, but the ways they are implemented can be very different. Below are my translations.
 
Iteration/Sprint – A fixed period of time, usually 1-4 weeks, in which work is planned, managed and delivered. Agile teams commit to working on a set of prioritized stories and nothing else during this time period – nice in theory, not always possible in practice, especially in marketing.  In order to manage fire drills or other work, you can do one of two things – build time into your iteration, or get very disciplined at saying "We'll put it in the backlog".

Backlog – Prioritized list of work items (stories) not currently scheduled into the iteration. As you well know, marketing priorities are often changing (monthly, weekly, even daily) so backlog management can be challenging.

Story/Backlog Item /Feature – Most often in agile software development, it's code that delivers specific functionality and provides business value (What is a feature?). In marketing, the idea of business value still applies, but often times is thought of in terms of deliverables – collateral, online content, events, ads, etc.

User Story – A way to define a story from the perspective of the end user. The typical format is “As a (user) I want (requirement) so that (goal)”. This format works well to describe feature/functionality in software development practices, but we haven’t found it as useful on our marketing team. We structure our stories based on define, design or deploy phases (more to come on this later).

Estimation – The process teams use to determine the size of a story, usually through Story Points, ideal days or t-shirt sizes (small, medium, large, extra-large). The work associated with a story must be well defined/understood in order to accurately estimate. Keep in mind who outside of the marketing team is involved with a story -- even though you don’t include their time in the estimate, these stories usually take more time/effort.

Story Point – A unit of measurement used to estimate the work/effort/complexity of a story in order to give it a comparable size. Typically a 1 is twice as big as a 2 in terms of complexity. The challenge in marketing is that some stories might be “easy” but take a long time and others might be “hard” but not take very much time (more on this one too).

Task – The small, individual work items that comprise a story. Typical tasks in marketing include brainstorming, outlining, drafting, feedback loops, proofing, dry runs, pushing live, sending out.

Taskboard – A visual information radiator which is a fancy name for a whiteboard (physical or online), or wall chart with index cards, or sticky notes to track the status of tasks. Have fun creating a taskboard, but don’t over think it.

Defect – In agile software development, a defect or bug refers to an unexpected behavior in a feature often caused by a problem with the code. In marketing, defects are more likely to come in the form of typos, broken links, unclear messaging, etc.

Impediment – Anything that prevents agile teams from getting their work done. Common marketing impediments include too much feedback (often unsolicited), budget constraints, outside vendors and external dependencies.

Done – This deserves its own post (or even series of posts), but for now, done means that the tasks required to deliver the agreed upon value of a story are completed and the product owner has accepted the story. Life is much easier when done is defined at the time the story is planned and estimated.

These are only a few agile terms you’ll need to (re)define for a successful agile implementation in marketing. Have your own software-to-marketing agile translations? Please share.
 

As I mentioned in my last post, one of our biggest challenges in transitioning our marketing team to agile was changing the idea of ownership. As with most agile processes, the concept isn’t difficult to understand, but making the behavioral changes it requires can be complicated.

It’s not my idea, my work, my deliverable. It’s not your typo, your missed deadline, your mistake. It’s our commitment, our failure, our success. It’s a little let’s hold hands and sing kumbaya but it’s the only way to become a successful agile team. 

Who are we?
We are the individual contributors that make up the team. If you have a larger marketing department (typical teams are between 5-9 people in size), you’ll probably have multiple agile teams -- and in that case, the "we" can include the entire marketing department. The Product Owner is not a member of the team (they don’t work on stories or commit to work on behalf of the team), but they do play the critical role of prioritizing and defining stories for the team(s).

What is ours?
The commitment, the quality and the timeliness of the work is ours. This is often where marketing teams struggle when transitioning to agile methods. The story owner doesn’t own the story. They own the responsibility of getting the story done (more to come on the definition of done).  Story owners, in most cases, shouldn’t own all of the tasks – it’s much better if they don’t. The only way we can achieve a genuine sense of shared ownership is to actually share the work.

Two of the biggest reasons this is so hard on marketing teams is because marketers tend to get emotionally attached to their work, and they are used to receiving individual praise - often outside of the department. It’s hard to let other people work on “your baby” and it’s even harder for other people to share the glory with others on highly visible projects. For team members who have a hard time letting go (I’m including myself in this one), the first step is to have them teach the team about their area of expertise. When they don’t own a story/work they might have owned in the past, encourage them to share ideas and give feedback. Even though agile methods focus on the team, it’s still important for the team and the Product Owner (who is often the "boss") to recognize individuals who go above and beyond.

In successful agile adoption, behavioral changes are the hardest, but they also have the biggest impact on creating a high functioning agile team. What behavioral changes are your marketing teams struggling with? What are you doing that’s working?
 

It sounds extreme, but it’s important to break ties with the old and make way for the new when starting your agile adoption. Traditional marketing practices (hierarchy, working in silos, set in stone plans, perfectionism) have no place in agile. If you have team members that won’t get on board, they should be off the team. The energy used trying to get them on board is often wasted, and they most likely won’t be happy on agile teams anyway. “Rehire” team members who work well in a collaborative environment and are willing to give this agile thing a try.

Get Rid of Titles
The only place titles belong in agile are on business cards, not among team members. Agile methods give everyone on the team the opportunity to step up, and provide visibility into which members are contributing and which ones aren’t. Practicing agile also exposes the difference between people who rely on their titles to manage and those with real leadership skills. At the end of the day, stories are committed to and worked on by the entire team, regardless of pay scale.

Blur the Lines Between Functions or Break Them Down Completely
Functional areas or specializations are a little trickier. Not everybody on the team has the same skills and experience, but you’ll be surprised how many hidden talents you’ll find. Designers can have great campaign ideas and SEO experts can provide insight into social media programs. Team members that have experience in entrepreneurial environments or in agencies are used to wearing many hats and can contribute to stories outside of what they were hired to do. Create opportunities for the marketing equivalent to Pair Programming (i.e. cross training) and you’ll begin to create a true cross-functional agile team.

Sounds Good, Right?
But it’s not easy and it takes time. Breaking down the lines between functional areas was the hardest for me personally. Not because I didn’t want to work on stories outside of my area of expertise (I love doing that), but because I had a hard time letting other team members work on “my” stuff. Traditional concepts of ownership (mine, yours, ours) are hard to break, especially on marketing teams, but giving up the me in team is crucial to successful agile adoption.

We spun our wheels in a few areas we could have avoided when we were transitioning, but hindsight is 20/20. What have you learned in your agile transition that could help other marketers?

If your development team has been practicing agile for any significant amount of time (3 – 4 releases), then your marketing team should have jumped a while ago. You’re doing a disservice to your organization if you don’t. If your dev team is running a pilot agile development project or even thinking about “going agile,” jump now! Regardless of which department is transitioning to agile, it takes time. The sooner you jump the sooner can start realizing the benefits of iterative planning, managing and delivery. Even if there’ve been failed attempts at agile in the past, I would argue the benefits of successfully implementing agile in marketing far outweigh the crap you’re going to get for trying.

Having worked in software/technology companies for the last ten years, I know the frustration of missing release dates. It’s not fun putting marketing plans on hold or having nothing new to tell the market so you keep spinning the same lame story, and nobody likes the crazy hours marketing has to pull right before a release because there isn’t visibility into exactly what features are going to be released until the last minute.

The benefits of having both software delivery and marketing on a consistent rhythm aren’t hard to understand – the Agile Checklist is a great resource for learning to use agile rhythms. Using agile processes, new features are potentially ready to be released at any time and marketing has the collateral, website updates, customer communication, etc. already in progress or ready to go. Conceptually agile is easy – it’s the mind shift from only delivering a final end product to managing near term deliverables and the behavioral changes required to support the process that are challenging. 

I’m going to be sharing my thoughts on the impact of agile in marketing and the challenges I’ve encountered (and sometimes continue to struggle with) as a marketing ScrumMaster. I would love to hear about your own experiences with agile in marketing or other departments outside of development, questions you have and comments. 

We all know the benefits of agile when developing software, but are you using those same principles with your marketing efforts? Treat your marketing initiatives like any other agile project by breaking big ideas into small deliverables.

For example, launching a marketing microsite sure sounds like an epic undertaking but breaking into smaller pieces makes the project much easier to deliver. Start by building a simple webpage with links to existing content (blog posts, articles, whitepapers, presentations) and add new content to the site (podcasts, webinars, videos) with each iteration. Get feedback early and often so you know you’re creating what your audience wants. Once you have enough content, you can divide it into multiple pages and before you know it you’ll have a full blown microsite.