4 mistakes we made implementing agile marketing in iira

Unless you are superhuman, you will make plenty of mistakes implementing agile marketing in Jira. And that’s OK. According to Albert Einstein, “Anyone who has never made a mistake has never tried anything new.” So don’t worry about it. You are in good company. Or you will be once you start implementing Agile Marketing. Here is the good news, you can learn from the mistakes of others. You can learn from our experience. Our marketing team at ServiceRocket ran agile marketing methodologies for all of its work and made many mistakes along the way. This blog is an adaptation of a talk I gave at the Palm Beach County Atlassian User Group (AUG) on November 7, 2018. AUG leader Fabian Lopez was gracious enough to include me. The response was positive, even from people in the room who are not in marketing. It turns out, a variety of teams struggle with the same issues we faced implementing scrum in Jira.

Struggle less. 

Read on.

Bill Cushard book - agile marketing


Mistake 1: Working in One Jira Project with Multiple Issue Types

In an attempt to make things simple, we decided to create one project, and we created issues types for each type of work we do. Here is an example of the issue types we created:
  • Podcast
  • Webinar
  • Event
  • Web optimization
  • Graphics request
  • Schwag request
  • Content
  • Advertising
  • Social media
  • Press / Announcements
  • Sales collateral
  • Blog posts
  • White papers/guides
  • Web site bugs
One of the main reasons we set up Jira is way is to make reporting easier. Who does that? We thought we were smart thinking ahead like that. We knew we would want to run performance reports in Jira to measure our work, so we took a design step up front to make reporting easier. It turns out, we didn’t report on our work like we thought we would and this long list of issue types ended up causing a lot of friction in our work.

How?

As you can imagine, the way our team was divided up, different members of the team did most of their work in only a few issue types. So every time someone created an issue, they had to scroll up and down the list picking the issue type they wanted. This doesn’t team like much of a problem until the main issue types you use are near the bottom of the list and required you to scroll down the list every time you created a new issue.

Trust me. 

This sucked.

To make matters worse, structuring Jira this way, required us to make scores of micro decisions each each about what issue type to use. We created many issue types like this to make it easier to divide up our work. We would use the social media issue type for social media posts and the webinar issue type for tracking webinars. But what do we do when we want to do some social media to promote a webinar? This seems like a small thing, but if you magnify this by all the combinations of issue type choices, we found that people started using fewer issue types and just used a lot of sub-tasks, negating the need for all of these custom issue types.

Lesson: Use more projects and fewer issue types.

Mistake 2: Over customized issue types and thought everything was special

Have you ever used software that had so many fields on a page that it seemed like you used almost none of them? Salesforce comes to mind. So does our own issue types. When we designed our issue types, we added so many custom fields that it felt like we created data entry jobs for ourselves. Our intentions were good. We thought we would actually report on this data.

We never did.

This is what our webinar issue type screen looked like:
  • Guest speaker
  • Webinar typeLine of business
  • Target audience
  • Target product
  • Call to action
  • Webinar goal
  • Webinar date
Look at the last one: webinar date. 

Looking back, there is no reasons we could not have just used the due date field. It’s not like we replaced the due date field with webinar date. We had both.

Yuck!

Sure, there was a reason for that. There are still several tasks to do after a webinar date. Tasks like upload the recording, send out thank you emails, and promote the recording to name a few. That seems logical, but we never used the webinar date field, opting to just use the due date field as intended. As for all the other fields, we naturally just put most of that data in the description field and in the comments throughout the lifecycle of the webinar planning process.

Lesson: Before you create custom fields, be honest with yourself about whether you will actually use them. Or suffer the consequences of unwinding them.

Mistake 3: Customized workflows, because in progress means different things to different people

If you consider the long list of issue types we created, you can imagine the equally long list of workflows we created. Because, of course, each issue type really does have a different workflow right? This is a partial list of workflow steps we created in our different workflows:
  • Setup
  • Publish
  • Requested
  • In progress
  • Working
  • In review
  • In legal
  • Awaiting approval
  • Review
  • Done
  • Finished
  • Completed
Really? Done, Finished, AND Completed?

Don’t do this. 

Don’t let each micro team on your team create their own workflows in isolation because they will invariably create their own words for done. Gather your entire team and agree on the same terms for workflow steps as much as possible. You don’t want to be in a position in which you are creating filters and have to scroll up and down a list of dozens of workflow steps to find a list of issues that are currently in progress.

Lesson: Use as few workflow steps as possible. Agree as a team what to call in progress and done.

Mistake 4: Undisciplined stand ups

When we started running scrum, the team at first resisted the daily stand up. What kept them engaged is that they knew the meetings would be short. Fifteen minutes max. And we kept to that very well. What we did not stick to was addressing tasks in the sprint. Here’s what I mean. We ran each stand up with these three questions:
  • What did you work on yesterday?
  • What are you working on today?
  • What is getting in your way?
That seems fine, right? 

It does. 

Until team members start answering these questions with only the things they are working on that were NOT planned in the sprint. People would update the team on meetings they had scheduled, unplanned tasks that came up that morning, and worst of all update on “going back and forth on email with Neil and Sandeep to talk about those website changes.”

Good grief.

We finally got a handling on this drifting when we changed the questions to:
  • What did you accomplish yesterday to advance the sprint?
  • What will you accomplish today to advance the sprint?
  • What is getting in your way?
That changed everything. 

When someone started wandering off the path, the scrum master would ask, “What is the issue number for that?” When there was none, team members modified their update. It didn’t hurt that we put the board on the screen during our meetings and used quick filters to display that team members issues while they gave their update.

Lesson: Advance the sprint. Don’t give status updates.

Get the book: The Art of Agile Marketing: A Practical Roadmap for Implementing Kanban and Scrum in Jira and Confluence

No. These were not the only mistakes we made. We made many more, but you get the idea. One of the best things about using Jira to track all of your work is that you can configure it to suit how you want to work. The problem is that we don’t always know how we want to work until we start working. So let this be a lesson to you…that it is OK to make mistakes. Mistakes are inevitable. It is better to start, knowing you will make mistakes, than we wait until you get it right the first time. Chances are, you won’t.
You can learn from even more mistakes we made in the book, The Art of Agile Marketing: A Practical Roadmap for Implementing Kanban and Scrum in Jira and Confluence. It will help you get started and also avoid some of the mistakes we made.

Comments