Communications and agile

Communications and agile

In the course of my career I’ve worked with many different technology teams and a range of different approaches to software development.
I first worked with the agile approach at Egg on a project designed to improve the customer experience for credit card applicants.
Agile is all about a better way of delivering software – and I’ve been thinking about how the principles of agile might apply to marketing and communications projects – especially when used alongside the project management approach that the marcomms world is moving towards.
The original creators of agile set out twelve principles that define an agile approach – and I’ve been thinking about what that might mean in a comms team context.
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
For comms project teams this means that we need to think about how we engage the client – the person who we’re working for – during the project. Just delivering a formed campaign plan and creative at the end of a project isn’t agile, but providing regular incremental information, materials or engagement for the client during a project certainly would be. But does that demand skills and time that clients just don’t have or want to make available?
Welcome changing requirements, even late in development. Agile processes harness change for  the customer’s competitive advantage.
This should be a given. The world around us in which we communicate changes every minute. So if we have new evidence to challenge our thinking, let’s hear it and respond to it.
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
Not quite sure how this relates as directly to communications projects – but it could suggest that we need to develop campaign concepts and plans in short iterations and test often – whether with clients or in a quick form of pre-testing for materials or channel selection.
Business people and developers must work together daily throughout the project.
Yes – the combinations of perspectives from communications professionals and service-based clients is more powerful than one group alone.

Build projects around motivated individuals. Give them the environment and support they need,  and trust them to get the job done.
Yes absolutely. Pick the right people that are motivated to deliver the task at hand. And give them the tools, information and, most importantly, space to get on with it.

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
Interesting one. I’m a great believer in the value of written briefs of one sort or another – to define what’s needed from a campaign. Otherwise things can tend to wander about a bit and make it hard to know when you’ve got the campaign right. But that’s no substitute for face to face engagement. I guess the two need to happily co-exist.

Working software is the primary measure of progress.
So in the comms world this means getting something on the table early that shows what the end campaign might be. It may be a rough plan, some creative concepts or a bunch of evidence that points to a strategic direction. That’s certainly better than keeping things under wraps until the final client presentation.

Agile processes promote sustainable development.  The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
I get this completely in software development. But I’m not quite sure how it might apply to a communications team. I can see the value for people and those leading teams to ensure a constant sustainable pace, rather than the peaks and troughs that characterise much of our business, but I can’t see a way to make constant indefinite a pace a reality given the nature of communications work.

Continuous attention to technical excellence and good design enhances agility.
Yep – paying attention to the technical and aesthetic quality of what’s done is important. And valuable.

Simplicity–the art of maximizing the amount of work not done–is essential.
And yes, I agree with this one completely. Keeping things simple is important as it forces a focus on what’s important – in much the same way as it’s more tricky to write high quality concise copy than it is to go long.

The best architectures, requirements, and designs emerge from self-organizing teams. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
And this works for communications teams too. The behaviour and productivity of self-organising teams is better for delivering quality results than imposed teams or strictures. The best teams are able to reflect, understand and re-orientate themselves to optimise what they do. For me, the role of a leader is to facilitate this – creating an environment where the expectation of this happening is clear, but leadership isn’t overly directional.

There’s definitely much in the agile theory that can help communications teams. Have you tried using agile principles in the team you’re part of? I’d be interested to hear if this resonates with others or if I’ve just gone a little bit loopy at the end of a long short week!
Update: 1 April 8.30pm – Sharon O’Dea has reminded me that she’s blogged on a similar theme – well worth a read on the concept of agile in communications project management.


I work with technology-centric businesses as an interim Chief Operating Officer (COO), consultant and advisor. I created the B3 framework® for scaling technology businesses and I write a newsletter called Build for leaders who are building brilliant companies.