It's that time of year again. That time when marketers look at what they've accomplished this year and think, should we be doing things differently?

Well, one new approach which some are taking is agile marketing. (For those unfamiliar with topic, you can read up on it here).

And agile marketing certainly fits the bill of a new and different approach. With its own terms, habits, and outcomes, agile could potentially completely change how you and your company manages its marketing.

But the problem with agile marketing is that while it sounds good in theory, it's difficult to get good information about how well agile works in practice, for marketing departments specifically.

To shed some 'real world' light on the topic, Econsultancy recently invited a number of senior client-side marketers to discuss Agile Marketing at our recent Digital Cream Sydney. At a table led by agile marketing expert Mariella Villa, senior marketing leader at ANZ, a few key points emerged which will help you on your way to making an informed decision about agile marketing for your team.

Before we start, we'd like to let readers in South-East Asia know about an upcoming training course, Content Marketing for Web, Mobile and Social Media in Singapore on November 13th. For more information and to book your spot, click here.

Here are the key points from the discussion.

1) Agile works for marketing

Many attendees on the day had heard of agile, but typically associated it with software development or other large-scale project management.

Those who had been part of agile marketing teams, however, assured participants that agile does indeed work for marketing.

Agile's approach for helping teams deliver continuous value to business combines very well with marketing's overall goals, namely engaging customers and managing ongoing customer relationships.

And while it takes some time to get used to it, few who have been on agile teams indicated that they willingly went back to their old project management methods.

2) But you have to do it 100%

Many people unfamiliar with agile were curious about how to start. Was it possible for just a few people to be agile? Or are there agile principles which any team could adopt to improve performance?

The answer from agile veterans was no. In order for agile to work, particularly when starting out, it is necessary to implement all of agile's principles across the whole team.  "Don't cherry pick," advised one attendee.

Additionally, once you decide to try out agile, it's necessary to do it for at least three months. Reason being that agile, at first, is not so fun. It can be confusing and add time and complexity to previously quick and simple tasks.

Once underway, though, those who were familiar with agile said that adopting its principles had a major impact on performance and brought tremendous satisfaction to those who put in the effort to get it going.

3) Agile brings more benefits that you might anticipate

One marketer revealed that her team had been using agile for marketing for more than two years and named some of the benefits they had enjoyed. Projects took less time to get started, accountability increased, and, most importantly they were able get their work out to customers much quicker.

But besides the well-known benefits, she said that agile also improved team engagement so that everyone felt ownership of the team's successes. Individual performance still mattered, but now everyone felt like they were contributing to a common goal.

Additionally, she noted, team members feel tremendous satisfaction at getting through a sprint, a feeling which is rarely encountered when marketing is run in a fire-fighting fashion.

4) Cool it on the agile language

For those who were starting to research or implement agile, the agile veterans had one more piece of advice – don't use agile language with people outside of the team.

Agile comes with a number of its own special terms – sprint, squad, scrum, etc. – and those who haven't been exposed to them are made to feel like outsiders when people 'talk agile'.

Also, another noted, using agile terminology may make you sound like you're in the 'cult of agile' which, again, is off-putting to those who are unfamiliar with the practice.

Instead, reserve your agile talk for your team and speak to stakeholders using term that makes sense to them: teams, objectives, and deadlines.

A word of thanks

Econsultancy would like to thank all of the marketers who participated on the day and especially our Agile Marketing table leader, Mariella Villa, senior marketing leader at ANZ.

We hope to see you all at future Sydney Econsultancy events!

Jeff Rajeck

Published 20 October, 2017 by Jeff Rajeck

Jeff Rajeck is the APAC Research Analyst for Econsultancy . You can follow him on Twitter or connect via LinkedIn.  

218 more posts from this author

You might be interested in

Comments (2)

Pete Austin

Pete Austin, Founder and Author at Fresh Relevance

5) Agile is a natural partner with Testing. Because you're not so committed long-term, you can immediately do "more of what works" and less of what doesn't - provided you're measuring outcomes (leads/sales/etc) as part of your process.

8 months ago

ViceKnightTA (Google me)

ViceKnightTA (Google me), Agent at Wouldntyouliketoknow

Agile is one of those concepts that - much like "pyramid scheme" or even "communism" as the more extreme examples - looks convincing on paper, but fails if/when you try to execute it without properly considering the ultimate success factors.

For any software project, there are at least 3 general "pillars" of project success; 100% resource commitment, 100% developer expertise, and 100% stakeholder feedback.

There are many times these 3 can never be 100% achieved in the qualitative world we live in, and unless you have really great project management and/or room to fail, even the lack of or weakness in one of those "pillars" will cause the entire project to come crashing down; this failure is further amplified/worsened in Agile projects thanks to the "sprint-like" nature and hapless misunderstanding of the Agile project methodology.

While it won't help to be critical of Agile projects currently underway, it may be useful to those managing, to constantly reevaluate and remind themselves of the pitfalls of the four concepts of Agile project methodology, while mapping them to the 3 general project success 'pillars' to encourage project recovery/restructuring:

1.) "Individuals and Interactions over processes and tools" - requires 100% resource commitment; eliminating a few "unnecessary processes" here and there isn't gonna do squat unless the resources you choose have absolutely nothing else they are working on or bound to other than your project, and that usually isn't the reality; cannot be stressed more, and it's cringeworthy when Agile projects fail because the sprint timeframes didn't consider the obvious reality of the resources. If nothing else, just remember, not all people perform high-quality work under pressure; quality matters to customers.

2.) "Working Software over comprehensive documentation" - requires 100% developer expertise; even if resources code/develop all week, they can only deliver within the limits of their knowledge, and if they're not 'comprehensively' documenting their work, then you're risking a lot of rework when the product fails in QA due to poor design. Be prepared in that case to spend more time/money to bring in another "expert" to 'comprehensively' pick your product apart and try to figure out what went wrong; or have the previous resource 'comprehensively' learn from their 'incomprehensive' planning/designing in order to fix; hopefully they document also this time.

3.) "Customer Collaboration over contract negotiation" - requires 100% stakeholder feedback; even if you had the perfect committed team of experts, you have to also manage the business and user resources to ensure your team has a continuous stream of feedback necessary to strive for perfection. This isn't exclusive to Agile though, it applies to any project methodology. If you're not constantly managing expectations/feedback throughout the project from your stakeholders then brace yourself for a lot of changes as you near implementation at each sprint, which leads us into....

4.) "Responding to Change over following a plan"; I'll admit when I first read this I was literally ROFL, but perhaps that's because I misinterpreted the meaning; contrary to popular belief the aforementioned statement doesn't mean forgo planning, throw all your resources into a room to just wing it, and go wild with every single change that comes your way. No, It means understand that change happens in a project, and what's important is how your team responds by prioritizing the change with your stakeholders and resources, and being able to accept changes into your project without further reprimand or risk; both of which you are otherwise prone to without a proper plan for budget, time, and resources.

Then again, perhaps I could have saved myself (and everyone else) time going with the engineer's or consultant's answer "it depends" on the theres no "one-size-fits-all", and its painful to witness organizations forgetting to distinguish between reality and concept, beleiving Agile is some magical "holy grail" to solve all their issues.

8 months ago

Save or Cancel

Enjoying this article?

Get more just like this, delivered to your inbox.

Keep up to date with the latest analysis, inspiration and learning from the Econsultancy blog with our free Digital Pulse newsletter. You will receive a hand-picked digest of the latest and greatest articles, as well as snippets of new market data, best practice guides and trends research.