It was only at a recent Econsultancy web project management course (yes, I can definitely endorse it) that “agile”, a meaningless piece of jargon to me before, gained meaning. It’s actually something I’ve known and practiced for years without knowing the name or theory.
For those that don’t know agile project management, it’s a way of getting things done based on repeated executions that steadily gain additional functionality. Imagine a spiral. You have a complete circle. Then you draw a similar but different (larger) circle. And continue.
It’s opposed to waterfall approaches, whereby all of the functionality of a project is the only target, and each part of the project is unlocked by completion of what (needed to) come before it. The waterfall approach gains its name from the look of the GANTT charts that it uses.
Most pieces of marketing collateral proceed, hand-in-hand with a happily obliging agency, as a waterfall. A project is established with a closed-ended contract for Z, and a project is established to get from A to Z. Ideally, Z is the end-all, be-all and everyone will be delighted when Z is delivered.
One of the big problems with this approach is that life intervenes. Somewhere between B and Y, things change. Or things get held up at D, and E can’t even get started. Many projects simply fail, far short of Z. Nothing is shipped. All is lost.
An agile approach would say “the simplest implementation of what we’re after is D. Let’s deliver that first.” Then, all stops are pulled out to deliver D – a fully functional, high-quality product that can be shipped. The client can start enjoying it. It doesn’t have E, F, G….Y or Z, but it does a job.
Then, once D is live, you reassess. Maybe E doesn’t make sense anymore after D is alive. Maybe you find that D is a huge success, but skipping straight to S makes more sense.
Let’s escape the alphabet soup and imagine an example: A company wants to create a demo for a new product. Why not do this in complete iterations? The first executions would be based on a series of professionally commissioned sketches, and used in the blog and on the web-site. Feedback to this demo subsequently influences the product’s development. The second demo is an improvement on the first, and demonstrates the change in the product. And so on and so forth, for a number of iterations.
This way of thinking has boisterous supporting arguments, among the best being Mark Suster’s brilliant JFDI defense. How many marketing departments freeze under the influence of analysis paralysis? Get something good enough out there. Ship it. Then study it. Reprioritize. Renew. Republish.
Even progressive journalists are adopting this kind of thinking. The most influential among them may be the Jeff Jarvis’s and Mike Arrington’s of this world – both of whom argue that journalism works best in an iterative, dynamic process. A news story remains dynamic and is edited and improved again, and again, and again, as facts come to light and understanding grows.
I’m applying this methodology in my work as a digital marketer, and not just on web-site builds. How? By developing fully-formed products that fit the bill (you have to keep clients happy), but then – crucially – studying the product’s performance, reporting on it and coming back with a reprioritization. “Based on what we know now, here is what we do next. Here is how we make things steadily better.”
Critics/competitors will say that this leads to sub-optimal results. “If Z is wanted, why not go for Z?”, they’ll ask. For some things, yes, like the annual report or something. You’re not going to iterate that product too many times.
Most marketing ideas and pieces of collateral, however, would benefit from a project design that delivers what is needed and no more, shipping it, then reassessing before you proceed.
Enjoyed this article?
Take part in the discussion
Related blog/content

Killed by the buzz: Why we’re losing words to the buzz effect (and what to do about it)
Here’s a question for you: What do buzzwords and That One Guy You Hate™ have in common? You guessed it. They both sneak into every conversation…
Nur Caplin | 20. 09. 2023

How to break free from the benchmark trap
If you’re turning to industry benchmarks to set your performance goals – make sure you’re asking these two questions.
Agustin Rejon | 06. 09. 2023

The B2B generative AI design shootout: Part 2
We put different models of generative AI to a heftier task in Part 2 of our three-part design test shootout.
Brian Terry | 29. 08. 2023
-
Ryan,
Thanks for your kind comments about the course presented by my colleague Denis Howlett.
I thought your readers might be interested in finding out more about Agile – http://www.indigoblue.co.uk/project-management/agile-common-sense-approach-project-management – gives an introduction.
You might find it amusing that we have a blog post taking slight issue with your reference to Wikipedia’s definition of Agile – http://www.indigoblue.co.uk/project-management/article/why-wikipedia-wrong-about-agile-and-how-it-should-adopt-agile-itself – in essence, we believe that Agile can be used for large programmes as well as small projects (which is what Wikipedia says).
Alex McLachlan