Tactics for Adapting Agile Methodology to Your Marketing Department (Part 2)

In my last post I touched upon the origins of Agile and Lean in the software industry and focused briefly on how to start sowing the seeds of Agile within your marketing group. In this post I will cover the Agile tactics that solve the three biggest pain points teams experience.

 

Most marketing teams are channel-driven, yet there is still a need to align on brand voice and even campaign themes across these channels. The most common complaints I have heard in this vein are:

 

  • Lack of visibility into inter-team projects (working in silos)
  • Lack of communication
  • Lack of predictability in releasing projects

The issues above are related and solving one will help unravel and solve the others as well. Let's examine each in turn.

 

Lack of visibility into inter-team projects Inability to see what other teams are producing can lead to wasted effort, divergent/discordant brand voice or themes, and duplicate assets or content. If you employ SEO to optimize your search rankings, you are painfully aware of how search engines beat you up for producing duplicate content. And efficiently reusing content and assets increases visibility into projects across teams, which can ultimately lead to increased speed-to-market when a product is delivered.

Agile simply asks teams to be more communicative and collaborative almost daily through Scrums, and to release projects in smaller chunks. This rapid release of smaller, more manageable projects inherently leads to more frequent releases.

 

 

Lack of communication Using a daily or bi-daily scrum can help alleviate any lack of communication felt within a team. A Scrum is a 10-15 minute stand up meeting amongst team members to touch upon the following:  

 

  • What each member is working on
  • What each member might they be struggling with in order to finish their task(s)
  • What the next task on a teammate’s list is

Usually the team stands around a physical board (if they are all co-located), with the columns describing your usual workflow and with the rows calling out the project--or “user story” in Agile terminology-- being discussed that moves across the columns depending on its status. How is this helpful, you ask? Suddenly you are visually made aware of the following:

  • Which projects are planned and which are in play. Here, a project could break down into smaller independent user stories with each user story describing a task
  • Who is working on those projects. Some teams create avatars per team member for both fun and easy identification of who is on it
  • How long projects have been in play or in planning, also called “cycle time.” In the sample board below, I have denoted cycle time using tick marks against each story. Each mark represents every day that the project has been worked on, which helps the team determine whether or not additional help is needed to resolve any blocking issues. The "planned" column usually aligns with business priorities and work should get pulled from the top. Agility is also maintained by ensuring that as business priorities change, these changes are reflected in the relevant column, pushing the most business critical goal to the top of that queue.

Screen Shot 2014-11-20 at 11.49.13 AM

 

As we all know, not all teams are co-located. In order to bridge that divide, scrums can still be done using digital boards (Excel spreadsheet or Google document) and using tools like Google Hangout or a group Skype conversation. There are many other vendors like Atlassian, Rally, VersionOne and Thoughtworks that make cloud-based Agile project management tools as well. Depending on your level of Agile maturity, investing in one of these systems may be wise.

You will notice that I have color coded the stories in the above chart. Color coding adds another layer of visibility. Marketing teams might decide they would ideally like to release a certain mix of assets every month, or whatever the release cadence might be. Every color indicates a type of asset that at the end of each release cycle allows for the team to take inventory of what they are releasing the most of (eg, videos, blogs, etc.). Seeing a lot of the same color can quickly inform a team of what assets or products they are producing more of, which can help teams determine whether or not they want to keep that mix or focus on other content they might not be releasing a lot of.

Among other Agile practices, weekly sizing and weekly, or bi-monthly, retrospectives are also recommended.

 

 

Lack of predictability in releasing projects Retrospectives should ideally be bi-weekly or even monthly based on the project release cadence. The discussions should be around process, skill and tools improvements. It’s best to categorize the discussion under what worked, what didn’t and any action items that come out of the “didn’t work” category. Obviously, during each retrospective reflecting on what worked is great for fostering good team morale as it helps to reinforce those good habits!

Another way to more accurately predict release dates with Agile is to size projects. Sizing in the Agile world isn’t about labor hours, but about relative effort on a project. Although over time, when there are enough data points, you can start to correlate size to labor hours. In my experience, team dynamics affect the sizing: as the team understands each other’s skill sets better, project sizes become more consistent. Also when the true nature of the project is not well understood, you can choose to time-box the effort of discovery before actually sizing a project/story. Some teams use T-shirt sizes – small, medium or large for effort – or they use the Fibonacci system. Agile adoption doesn’t prescribe which method is better, so it’s best to experiment to find out which one works best for your team. In my opinion, simpler sizing systems work best.

 

 

After using the various Agile methods I described above to increase visibility, communication and better prediction of release dates for projects, there is one last thing that will tie it all together. This is the idea of Stop Starting and Start Finishing. The idea is to finish what you started instead of juggling too many projects and finishing none. This can be enforced by using WIP (Work In Progress) limits for the team based on headcount. Stemming from Lean’s roots in the manufacturing industry, WIP is intended to limit wasted time and resources in the production process. Getting projects released quickly into the wild so you can realize faster economic gains is in the company’s best interests. In addition, you also get valuable feedback to make iterative product improvements, thereby staying relevant to customer needs.

Is Agile for you? Which of these can you start using today? Let us know in the comments.

 

 

 

 

Loading next article