Defining Agile Marketing, Part 1: You Say You Want a Manifesto?

This is the first of two articles on Agile Marketing and what it means.  The second, A Framework for Agile Marketing, will be published shortly after this one.

Why Define Agile Marketing?

With the recent announcement by the 4A’s that they are including “Agile Marketing” in their Fall Strategy Festival, we can safely assume that the term “Agile” is truly trending in the marketing world.  There are books out there, and Facebook pages and Meetup Groups…yet, as an Agile practitioner who did his first iterative-style project back in 1982 (rapid prototyping) and who now works daily with Agencies, I feel like the term is being used with far less rigor than is appropriate.  I’ve read the books and a bunch of blogs, and even attended the SprintZero conference this June, and I still feel that way.

For example, I was working with an agency the other day and I asked an Account Director why he had rescheduled a critical project discussion at the last minute.  Moving the meeting had resulted in a lot of confusion within the project as much of the team had not been able to participate.  His reply was, “We’re just being more Agile about things!”

That’s actually poor, chaotic management, and pretty much the opposite of anything that one should be calling Agile, in my book.  Agile, done well, is the epitome of collaborative management, empowering and engaging everyone involved so they have a voice in decisions and understanding and ownership of the outcomes.  I know my example above may seem extreme, but I see the term being tossed around in some pretty casual ways, often just referring to changing one’s mind, or doing things in small pieces or short steps. Agile practices have huge potential to help agencies, clients and improve the marketing they produce.  I think it is worthwhile to stop and think about what we really mean when we say we’re applying Agile practices to marketing.

Since I started thinking about this a month ago, there has been a continuing flood of  new definitions and declarations about “Here’s what I mean when I say ‘Agile Marketing.’”  One blogger posted a summary of 15 different definitions on the Agile Marketing FB page.  Many of the definitions I read are about doing what I would call “adaptive” marketing, and are focused on how companies should adjust to the needs of the consumer.  Some of the case studies out there are about adaptation, not what I think of as true agility.

Other recent events, such the Agile Marketing Group’s SprintZero conference, and the recent publication of a draft Agile Marketing Manifesto by this group, also make this more essential.  If marketers are going to get behind a vision and value system that serves as a new paradigm for how we do marketing, let’s make sure we nail it!  Why?  Because if it is not well defined, it is not repeatable.  If it is not repeatable, then it is artistry and cannot be professionalized to new individuals, nor can we build a practice of it inside an organization.

So the first part of this two-part article is focused on the “Manifesto” – what is a manifesto, do we need (another) one, and what forces should be shaping it?  I’ll play armchair historian a bit here, but only to illustrate how profound most manifestos are, and especially how much of a culture-change the Agile Manifesto for Software Development really was.

I truly believe that we need some sort of manifesto, and that the more profound our manifesto is, the more profound the change that will follow; it worked for them and those that followed…I think it can work for us too.

What is a Manifesto?

Manifestos are value statements. Typically, the values reflect a significant change to the existing culture.  A great example of a manifesto is the US Declaration of Independence – it outlines the values that its authors held in opposition to the prevailing form of government and representation.  Other great manifestos include: Martin Luther King Jr.’s I Have a Dream speech, JFK’s Land a Man on the Moon address, and the Ten Commandments, to name a few.

The Agile Manifesto for Software Development (hereafter “the Manifesto”) signified a break with the status quo – the existing culture of software development – and changed the dialog in software development.  While most people are well-versed enough in the history of the American Revolution to understand how dramatic (and, um, revolutionary) the Declaration of Independence was compared to the status quo, the origins of the Manifesto are not all that obvious to people who were not involved in software development back then.

So What Was the Manifesto Addressing?

While many people associate the Manifesto with (better) project management, the relationship between it and the project management discipline is not as flattering to the project management discipline as one might assume.  From my perspective, it was an outright rejection of what project management had become, as well as how projects themselves were being structured.

The Manifesto was drafted in 2001, but its origins go back to at least the 1970’s with the publication of The Mythical Man-Month, a book that explained, via case studies, the futility of trying to do large software projects. Specifically, big pieces of software couldn’t be broken down into pieces that later get assembled…it was too complex.   These projects struggled massively with overly-optimistic budgets and schedules; time and cost increased geometrically with project size.

In the decades that followed, project managers tried to fix this problem through an increased focus on solution design and more detailed estimation, tracking and management. By the 1990′s project management had become highly “professionalized.”  The Project Management Book of Knowledge (PMBOK) had been recently published by the Project Management Institute, and it listed 23 separate roles for project management in a project!

This growing arsenal of specification tools and management processes helped make projects go better for a while, but as projects became (even) more complex, and customers wanted to have things faster and cheaper, things started to break down. From the 1990’s on, project plans, estimates, reports and schedules began to rule projects…rather than the customer and the team.  Add to this a new class of worker (business analyst) who would abstract/describe business needs into huge requirements documents, flow diagrams, etc.  Also, most new project managers didn’t come from skill roles (developer, tester or customer), but rather, were part of a breed of new managers that wanted to be “in charge” of teams.  With these changes, more than half of any software project, often 60%+, was comprised of people who didn’t write software, nor ever had!

The Standish Group (which surveys project success rates) notes that, from the late 1990’s onwards through to today, project success rates have not improved significantly. Many projects, around 50%+ are over budget or schedule, and 20%+ of all projects are cancelled before completion!  The sole exception to this, in recent years, is that projects run using Agile perform much better than this…about three times better.

What might now be obvious in all of this is that over-budget and over-schedule projects are hardest on the software developers, and these were the “citizens” who crafted theManifesto.  When projects run late, people work long hours and seven-day weeks. Developers do most of their work at the tail end of a project, and any developer who has been on a “death-march” project, never sees appreciation and thanks at the end.  When projects go badly, PMs tend to manage harder – and the people who get the pressure are the developers.  Ask a developer about this…even today the practice persists.

The Agile Manifesto was a frontal assault on heavy-handed project management.  The vast majority of projects that either failed (cancelled) or were significantly challenged in schedule or budget meant that most of the time, developers were not happy.

Deconstructing the Manifesto

So let’s take a look at what the Manifesto was saying from this perspective.

The first value is “Individuals and interactions…over processes and tools.”  This is a rejection of the role-based “silos” of specialization within the project.  Each specialist often did their work in a vacuum, often using tools that described designs, processes or requirements in a specialized language.   (We’ve named this effect, “Read My Book,” where rather than gaining understanding through discussion, someone points to a tool, or a specification)  It was a rejection of the idea that developers were automata, who would just crank out work while ignorant of the larger picture and related components.

Developers (who are “creatives” at their core) need to share thoughts and questions, understand the business context and needs, and develop consensus views to make development go faster and better.  And they want to have a larger voice in what is being built.  Often that voice makes for better solutions as well.

The second value is “Working software…over comprehensive documentation.” There is something very radical in this statement: traditional projects would focus on “deliverables,” many of which were not software.  People on a project typically had individual deliverables: PMs had project plans, analysts had business requirements, testers had test scripts, etc. and most of them were (merely) forms of documentation.  But the only deliverable in a project that really mattered was working software.  When the software didn’t work or wasn’t done, the finger was pointed at developers; and often everyone else pointed at their “completed” deliverable as evidence that they were not to blame.

In reality, project success is a team effort, and the only valid metric is working software.  By de-emphasizing all documentation and forcing all roles to be judged by the metric of working software, in effect “Yes, but does it work?” the Manifesto brings teams back together.

The third value is “Customer collaboration…over contract negotiation.”  Developers were often distant from the actual customer, especially in the early stages of the project. And when they did finally meet the customer with working software, even if the software matched the business requirements, test cases, designs, etc., the customer was often disappointed.  A “scope change” discussion often followed, with contract negotiations and its attendant pain.  In a way, the software developers were at the tail end of a bad game of “telephone,” perennially disappointing the customer, despite their best efforts, usually because they understood little of what the customer wanted.

Even today, when we coach projects, often there are one or more developers have never met the customer, never heard a customer describe their needs, nor provide any direct feedback.

The fourth value is “Responding to change…over following a plan.”  This last value is the most direct assault on project management.  It also has the beauty of being necessary given the three prior values: if everyone is going to be discussing and re-shaping things (#1) and we’re going to be looking at software, which is probably changing frequently (#2), and you’re also going to have the customer involved and they might change their mind (#3), then how are we going to stay on plan? This last value says that the plan is less important…project management, and its schedules and resource plans, are no longer the center of the project, and that “getting it right” is the true goal.

These four values effectively proposed disruptive (and massive) change to the collaboration, metrics and measurement, organization, and the management & governance process.

What followed was a wealth of well-defined and specialized methods for running software projects, including Scrum, eXtreme Programming (XP), and various adaptations of Agile. Our own version of Agile (Whole Agency Agile) is designed for digital agencies, integrating the wide variety of roles across interactive project lifecycle (Strategy, UX, Creative and Development).

One Perspective: Do We Need a New Manifesto?

It is not clear to me that a new manifesto is needed for marketing – it may be that the original Agile Manifesto says it all but it just needs a little re-styling to make it a bit more applicable to marketing.  If we take the core of each of the values and do a gentle re-frame, it might look like:

1)    Cross-functional (all marketing functions and disciplines) collaboration – all eyes on the ball

2)    Results-orientation – focus on holistic (program) metrics, test

3)    Customer transparency – bring the customer (client) into the process more deeply, more effectively

4)    Iterate and adapt – plan for change, pivot, mix it up, listen to the crowd.

The actual draft Agile Marketing Manifesto reads much the same (with numbers corresponding to the Manifesto items above):

• Validated learning over opinions (expert or otherwise) and conventions (2)
• Customer focused collaboration over Hierarchical silos (1)
• Adaptive and iterative marketing over big-bang campaigns (4)
• Process of customer discovery over static prediction (2)
• Flexible planning versus rigid plan (4)
• Responding to change over following a plan (4)
• Many small experiments over a few large bets (2, 4)

These all sound like good marketing practices, for sure.  But they don’t sound like a cultural or business revolution.  In fact, they sound a lot like a good social media campaign.

Every agency with half a brain is doing these things, aren’t they?  I don’t know of an agency or a client that does not do some level of cross-functional collaboration (1), or that doesn’t do validation through testing and metrics (2).  Clients are getting more engaged (3) as they in-source agency talent, gain skills and their decision-making moves from glacial-pace towards real-time.  The idea of iterating (4) seems almost redundant.

So where is the revolution?  Did it already happen?

Who Are the Citizens and What Is Their Pain?

Manifestos reflect the needs of a citizenry.  Who are these citizens?  In The Manifesto it was the “Team”, the people who were responsible for building software (led by the developers) that were the citizens.  In Agile Marketing, it is probably a bit more complex…more of a society than just a citizenry: clients leading the marketing function, and their partners in the Agencies, the people who write the copy, develop the strategies, design ads, concept user experiences, buy media, and even the end-users or customers.  So, lots of people with different experiences and skills, all of whom try to make their part of the solution work.

If you work in marketing, whether agency or client-side, you no doubt have lots of thoughts on what the challenges are that we face today. Here are a few challenges we hear when we ask, “So how are things working these days?”

• The Proliferation of New Channels has made collaboration both more essential, yet much, much harder.  The old hierarchical strategy-led creative models often don’t work well when they need to be extended across multiple channels in a synchronized way, often in near real-time.

• These additional channels are home to the new Cross-channel Consumer, who sees the brand and product from more perspectives than before, but also, may see the cross-channel view better than people inside the client or its agencies.  The specialized-agency model (specialized teams that create advertising, media, social, search, websites, etc.) means that almost no one has a holistic view of the integrated brand/campaign prior to it actually being in-market.

• Meanwhile, Increased Channel Velocity means that cycles are getting shorter, feedback loops must be tighter and the ability to pivot quickly is a differentiator, yet it is very hard to do in a traditional multi-Agency setting.  Even in the case of client accounts managed by large holding companies and their family of specialty agencies, the coordination and collaboration just never seems to happen as fast or as deeply as it should.  This not only affects the need to fix/remedy a struggling campaign, but also the ability to drive a “hits” model, and gain cross-channel leverage from big successes.

• And the Improved Intelligence and Measuring available today creates a wealth of information, even in traditional channels (through sentiment analysis, for example), yet this new information is often still balkanized and underutilized as a tool for refining and optimizing campaigns and messaging. Data can only drive insights when provided to those that are responsible for defining the customer experiences within their specialty. Dashboards, while great at providing visibility, often don’t get properly consumed, understood or interpreted consistently by agencies and marketers.

What we hear from agencies and clients both, is that there is waste and pain: so much money and time wasted through the inability to cope with and capitalize upon the changes and opportunities above, and so much pain in the work environment around how to work together without territorial disputes, hoarding of information or other “power games”.

We spoke with one agency recently where the cost of management plus quality assurance was four times greater (400%) than the cost of doing the actual work!  It should be about 50-80% at the most, even lower than that if using Agile.  It’s not fun for the agency to spend so much time over-managing and repairing, and we know that their client can’t be liking it much either.

So do we need our own Manifesto?  I’m not sold on it.  I certainly can see how the Software Manifesto applies to marketing, but I’m not sure that we know enough about what we want our new world to look like. What do we mean when we say “Agile Marketing” and is it safe to “concretize” it yet?  Keep in mind, that the software guys had been doing things better and different for a little while…and having done that, they found some truths to be self-evident.  Likewise, our founding fathers looked deeply into what had worked in other societies, could work and should work, and culled the key principles into the Declaration.

Likewise, and as I’ll discuss in the part 2 of this paper, I’m not sure that we really are all talking about the same thing: “Agile” can be interpreted to include something like “adaptive” (this seems to be common), and “Marketing” is a pretty “overloaded” term: it means many things, including “the total of activities involved in the transfer of goods from the producer or seller to the consumer or buyer, including advertising, shipping, storing, and selling.”  When we say Agile Marketing are we including Logistics?

My proposition: Let’s make sure we understand (and agree upon) what it is we’re talking about, and what we need Agile to help us out with.

 

This is the first of two articles on Agile Marketing and what it means.  The second, Defining Agile Marketing, Part 2: A Framework for Agile Marketing, will continue from this point and present a model for understanding the role of Agile in a Agency-based marketing organization.

 

***

Jack Skeels is the co-founder of AgencyAgile, where he helps agencies adopt Agile.  He  worked prior as the MD of Sapient Los Angeles, VP at BLITZ Agency, CTO of Global Gaming League, and a senior analyst for RAND.  Jack did his first programming at age 13, and started his career as a systems programmer in the 1980’s.