“Can you do agile marketing?” can seem like a scary existential question. But what if it was just another toolbox: a useful way to enable taking a different approach for the projects that can best benefit from it.
Software developers have long known about agile methodologies, and have been using them to develop solutions for goals that are ill-defined (where it is necessary to develop understanding as development progresses), or to create minimally viable products while development continues on on furtther functionality. But the approach is valid for more than just software development.
The traditional way of managing a project makes a detailed map before beginning. Agile means starting with the destination and a compass, then iteratively improving navigation while learning more about the landscape.
In marketing terms, you do not need to work in an agile way if you are updating a product brochure: you know what to do, who to involve, and how to get it done. But it may be time to consider agile when accountability is vague, the subject matter expertise you need is unclear, or when you are unsure how to interpret (or are missing) relevant feedback or insights. That is, if it is not possible to create a clear and comprehensive briefing. This might be because you are doing something completely new (for example, implementing a new type of sales tool), or because you are operating in a new constellation (such as, a first time collaboration with a new business partner). It might also be an approach to consider if you are unsure why you are not achieving the KPIs you expect.
Finding the right problem
The essence of the agile methodology is discovering what the real issue is. This means making the value the project should deliver explicit. The biggest hurdle here can be a reluctance of some stakeholders to let go of being the expert, and instead to be truly curious and open to different perspectives.
The result of this part of the process should be a consolidated set of “stories”. Each of these stories is a problem statement, told in the terms of one of the roles involved. The template formulation is “As <role> I want to <do something> so I can <achieve value>”. For example, “As an IT decision maker, I want relevant information about product deployment, so I can gauge the impact on the IT team’s workload”. Or, “As a sales person, I want easy access to information on interoperability, so I can present the facts quickly and thus increase the IT decision maker’s confidence in our competence”.
The second key part to each story is the set of acceptance criteria that this part of the deliverable should meet. For example, for the sales person’s story, this might mean offline access to the current specifications of the supported interfaces, to be able to answer questions, even in a building with no cellphone reception.
Finding the right solution
The full set of stories provide the development team with both the big picture, and the blocks of work. Importantly, the goal is to implement incrementally – the deliverable of each “story” should be handled separately – and iteratively, with frequent reviews. This may mean that the initial deliverables are incomplete, but it allows for the early collection of feedback, so the deliverable can be refined (or redefined) before it is too late, or too expensive. In agile, development is not about implementing decisions, it is about continuously testing the best way of achieving results.
(The full methodology includes ways of dealing with open issues, as well as prioritising and planning work, but that is beyond the scope of this blog. There’s more background info here.)
Finding the right methodology
Not every organisation is ready for fully agile marketing. Not least, budgeting procedures might mean a project needs to be fully scoped sooner, rather than in the course of development. However, the agile methodology provides a toolbox that also lets you assemble hybrid projects. This might mean defining the stories, but then using these ast he specifications for traditional development.
It’s not a question of either/or. It’s a question of using the best tools to achieve the right results.