https://defradigital.blog.gov.uk/a-guide-to-agile-communication/

A guide to agile communication

This guide is intended for:

people planning communications activity on behalf of agile teams
people doing the communications activity (especially blogging, presenting, or filmmaking)
people who manage the people described above, who want to understand what they're doing and why

The government service standard encourages teams to work in the open as much as possible, echoing item 10 in the government design principles, “make things open, it makes them better”.

This guide was written to help teams do just that.

Agile Comms for agile teams

The traditional approach to comms is to do a lot of planning up front. Many teams will embark on a “comms strategy”, or perhaps write a set of “comms principles”, and then set about filling a calendar or grid with expected messages at expected times. Most of these are unnecessary when doing comms for agile work and agile teams.

You probably don’t need a new comms strategy

Your comms strategy should simply be “Show the thing. Be clear. Be brief.” Any time you spend trying to come up with something that says broadly the same thing, only using many more words, is probably wasted time.

You probably don’t need any comms principles

The government design principles aren’t just about “design”, they’re also widely applicable to almost anything else, including comms. If you use the design principles to guide your comms work, you’ll be fine.

The problem with grids and calendars

Planning your communication in advance on a grid is largely a waste of time. This is because items on comms grids very rarely end up being used or published when they were planned to be. The whole point of agile is that you learn and develop and build as you go; it’s daft to try and predict what will be learned or developed in advance. You might be able to plan some high-level stuff beforehand - if you know you have a 10-week discovery planned for a particular date, you can be reasonably confident that you’ll have something to say at the end of that discovery (in week 11). But you should not waste effort trying to predict what that message will be. Nor should you plan to write about alpha and beta either - they might not happen at all, depending on what happens in discovery.

Agile ways of working encourage research and iteration. Don’t try predicting the comms about agile work, because you don’t know what the research will uncover, or what the iteration will result in.

Agile comms understands this, and deals with it by responding to the work as it happens.

It's still possible (and a good idea) to plan ahead, but keep the plans high-level: "By September, we should be talking about this. By December, we should be saying that." Don't try to shoehorn specific announcements about products into a detailed grid, because you will end up creating unnecessary work (and stress) for the team.

Some things that are worth thinking about in advance: who do you want to influence? What do you want them to know or understand that they didn't already? What's the best way to communicate with those people? To reach many colleagues across government, a blog post is probably a good plan. To reach specific senior leaders, perhaps a presentation or a brief email would be better. Target your communication to meet the needs of your audience.

Agile communication is different because:

It shows the thing

Above and beyond anything else, agile communication shows the work that’s been done, or is being done. If the news is about a team and what that team has learned, show the team, and show what they learned. If it’s about a prototype, show the prototype. If it’s about a live service, show the service. If it’s about problems that teams are tasked with solving, show the problems.

It’s more about the process and the people than it is about the technology

(But where there’s a story about technology worth telling, it can still tell it without overwhelming non-technical readers.)

It reflects the work that’s been done, not the hopes of management

It’s not about what may happen in future, or what the management would like to see happening in future, but about what’s happening right now or very recently. Focus on the work, how it’s done, and the people doing it.

It moves fast

It should be possible to write, edit and publish an important piece of news within hours. That’s not to say that everything must be fast, just that it can be fast when it needs to be. That said, responding to the work means that agile communication is usually done at a faster pace than traditional communication.

For example:

It should be possible to write a blog post about a teams’ discovery phase within a couple of days of the discovery ending. A writer sits down with one or two members of the discovery team and asks them what the team actually discovered. They write a draft and share it back to the team, who make edits and suggestions. Continue until there’s a post that everyone’s happy with. The discovery team make sure that the post is accurate; the writer makes sure that technical jargon is explained (or left out), and that the post is useful to a wide audience.
Good agile communicators can go from idea to product within days. If someone has an idea for a poster or a sticker that might help spread a useful message, an agile comms team can rapidly iterate through ideas for words and designs, then send something to be printed.

It iterates

As a by-product of being fast, agile communication can and does iterate as it goes along. It should be possible for a writer to draft something, discover it contains errors or needs re-writing, and then re-draft it again - all within a few hours. The broader message can change as new facts emerge and as teams learn new things. Through iteration of the story, agile comms reflects iteration of the product or service.

It removes barriers between writers and subject matter experts

It encourages use of pair-writing to make sure that messages that go out from the team are both accurate and readable.

It communicates simply, clearly and briefly

Agile communication recognises that most people, most of the time, are too busy to read detail. So by default, agile communicators simplify and summarise, helping their readers to understand the basics very easily and very quickly.

That’s not to say that detail is ignored. Detail is important to some people, some of the time, so it should be available. But it should not be the first thing that people have to read. Good agile communication sums up the detail by default, and then points readers to the detail, wherever it sits. Good agile comms says: “Here’s the essential information you have to know. If you want more detail, you can find it at this location.” Readers have a choice about if, and when, they bother to read the detail.

It builds a narrative over time, particularly through the use of blogging

Most large public sector programmes or work streams are too large and complicated to easily explain in a single document. It’s easier for teams and for audiences to break the story down into a series of smaller posts presented over time. In this way a blog, comprising a series of posts, can become a digital hyperlinked narrative of thought. New posts can link back to past posts. Teams can document what changes, and show how it has changed. They can show how their minds have changed, and what evidence or research brought those changes about.

Everything the team uses to communicate becomes part of this narrative

Blog posts are the best way to create a spine for it, but other things like Tweets, videos, presentations, show-and-tells, team newsletters and other tools can all interlink to it.

Thanks to that ongoing narrative, agile comms acknowledges and responds to the past. If teams have made mistakes, they admit to them (and say what they learned from them). When research shows that work needs to take a radical new direction, or perhaps be scrapped completely, agile comms explains what has changed and why. It doesn’t hide faults and errors. It wears openness and honesty with pride.

It is creative

It tells stories about work, and finds ways to tell them in new ways. It aims to keep audiences interested and inspired, even about subjects that few people would ever try to understand better in their free time. Most work is quite boring. Telling good stories about that work means coming up with interesting ways to tell them.

It avoids clichés and stock photography

Clichés just annoy people. If there’s something to show, show the thing, not a visual metaphor for the thing. Visual metaphors can be misinterpreted, diluting the impact of your message. Best to avoid them completely.

Techniques to use in agile comms

Write like a human, not like a corporate robot

If you want people to read something, give them something that’s readable. Write the way you would speak. If you find this hard (lots of people do), try writing a first draft by saying things out loud. Jot down the best bits on sticky notes as you go along. These stickies can become the outline for your first text draft. Nine times out of 10, the words you would say to someone over a cup of coffee are exactly the same words you should type into a document if you want people to understand it.

Pair writing

Not everyone finds writing easy. Not all writers can be expected to understand the work that an agile team has been doing. So it makes sense to combine two brains in one writing session. Pair writing is when a skilled writer sits down with a subject matter expert to write copy together. Ideally, they will both be sitting down in front of the same computer in the same room, although for more experienced writers and experts pair writing can be done remotely inside Google Docs.

Ghostwriting

Senior people often have plenty of opinions, but not much time. Use your writers to ghost-write for your senior people. Pair writing works well, if the senior people have time, but often it’s a case of interviewing the senior person (or just grabbing them for a chat between meetings) to find out what they think about something, then writing what you think they mean. Their response to the draft will either be “Yes that’s perfect” or “No I didn’t mean that at all!” — either way, it’s useful feedback.

A draft is just a draft

Drafts are wonderful things: you can write anything in a draft, no matter how wrong or weird or wonderful it is.

Anything that’s controversial or technical or unexpected can be fixed later. Sometimes, upsetting people with controversial drafts can have useful consequences: they can spark debate among teams, even on occasions when the draft never gets published anywhere. Sometimes the debate is the most important thing.

Drafts exist to be edited. They’re a way of thinking out loud, with your colleagues. It doesn’t matter if you, as the author, know full well that your draft contains holes and errors. Say as much when you share it. Invite people to help you fill the holes or fix the errors. Be open about how much you don’t know, and invite colleagues to share their knowledge and experience.

Share your drafts with wild abandon

You can never share your draft with too many pairs of eyes. It’s good to get feedback. Try to take negative comments with good grace; most of the time, people who give feedback are just trying to help you end up with a good piece of written work. People who critique your work are doing some of your editing for you.

It works both ways: if you’re asked to provide feedback on someone else’s writing, don’t just be critical for criticism’s sake.

Don’t say: “This is rubbish.”

Do say: “This bit is hard to take in, can you simplify it?” Or: “I don’t understand this section, can you rewrite using simpler words?” Or: “How about moving this section further up, and re-arranging the structure like so?” Your criticism as a reader should address problems you had while reading. If anything’s hard to read, suggest ways to make it easier to read.

Time is an excellent editor

If you write a draft, then leave it for a week and come back to it, you’ll instantly see things that don’t make sense and things you need to change. Unless the deadline is very urgent (in which case, employ more pairs of eyes), give your drafts time to cook. Then return to them with an editor’s eye, and be as brutal as you dare. If you see a line or a paragraph or even a whole section that looks out of place, don’t hesitate: delete it. The hardest part of writing is editing, and the harder you edit, the better the end result.

Writing is hard, so break it up into chunks

If you’re stuck at the beginning, start in the middle. Fill in the beginning later. If you need help working out the structure of the thing, stand up with some sticky notes and sketch it out on the wall as an outline or mindmap. Re-arrange them until a sensible structure emerges.

Write in a way that suits you: some people prefer short bursts when they’re at their most awake and/or caffeinated. Others prefer long bouts of silent concentration. Find out what suits your brain best.

Blogging, presentations and video

There’s more to say about each one of these, so we’ll cover them under headings of their own.

Blogging

A blog is a digital publication, with the most recent article (or post) at the top. Posts can be categorised, and readers can focus their attention on just one category. Posts are archived by month and by year. UK government organisations and teams can use the blog.gov.uk platform, which is co-ordinated by GDS.

Blogging is a valuable way of documenting progress, aggregating thoughts, building a narrative, and making things open. Blogging helps your team communicate briefly and clearly. It helps you divide the burden of comms among many people. Having a blog means you have freedom to communicate more often, about topics that matter to you and your users. Blog posts are simpler, quicker and more fun to write than press releases. Blogs are your brain, or your team’s collective brain, over time, on the internet.

Tips for effective blogging

Post often. Short posts every couple of days are better than long posts every couple of weeks.
Keep each post about one thing. If you have several things to say, write several posts. Remember, it’s easy to create links from one post to another - this is an important way of building your narrative over time. Make links from today’s posts to past posts. The simple act of creating links like this is all part of the storytelling, and helps your readers remember that story as time goes on.
Allow some personality in your posts, but don’t allow every single post to start with “Hi I’m {name} and I’m the {job title} at {department}” — that quickly gets boring for readers.
Remember that readers may be government colleagues who understand civil servant jargon, but they may not. So explain things, as briefly as possible.
Show the thing in your posts. Make prolific use of photos and screenshots.
Link everything and anything that’s linkable. Become a good citizen of the web by embedding your blog posts within it. Link outwards at every opportunity.
Every post needs a picture. Show the thing! Avoid stock photography.
Contact the comms team to get your post published. The more work you've done beforehand to iterate and revise your post, get feedback from colleagues, get approval from senior people, find pictures and so on, the easier their job will be.

Presentations

Writing good presentations is every bit as valuable as writing good blog posts. Too many presentations are boring because presenters don’t put in the effort to make them interesting. If you are presenting to an audience, you should respect their investment of time and make sure you inform them with clarity.

Keep your slides simple (don’t treat them as places to copy-and-paste long documents). Make sure the words you say out loud compliment the slides, and that the slides illustrate what you’re saying out loud. Presentations are made of two ingredients: what you say and what you show on screen. The two ingredients are intertwined. Writing a presentation means thinking about both.

Often, lazy presenters simply re-purpose text documents as slides. It’s important to think about the goal of the presentation: if you want people to listen to what you say, make sure you say something interesting, and illustrate it well with slides that are mostly made of pictures. If you want people to read something, provide them with a readable document (and tell them where they can get hold of it) — don’t just put bits of the document on a big screen and expect your audience to take it all in.

It’s beyond the scope of this document to tell you everything you need to know about doing presentations, but:

Tips for writing presentations, and presenting well

Write the first few versions of your presentation as sticky notes on a wall — this makes it easy to see the flow of your argument, spot repetition, and move things around. Standing up also encourages creative thinking.
Your slides exist to illustrate what you say, and keep the audience’s interest up. Make them interesting. Use pictures and pithy, short sentences.
If you put loads of text on a slide, and say other words at the same time as presenting it, you’re effectively asking your audience to do 2 things simultaneously: read the text and listen to you speak. They will fail, and end up only reading some of the words and hearing some of your speech. Don’t put that burden on them. As the speaker, it’s up to you to do the hard work to make your presentation absorbable.
Practice your presentation with a few team members, before you have to give it to an audience. Encourage them to give you feedback on everything: your slides, your speech, your body language, and so on.
Don’t share only the slides after a presentation. If you do this, you’re only sharing one of the two ingredients — you’re failing to share what you said out loud. The best way to share a presentation after the event is to write a blog post which says what you said out loud, and uses a selection of your slides as illustrations. Yes, this is more work, but it’s worth doing.

Video

It is possible to make short, clear, good quality videos without having to hire an entire production company. That said, it’s good to have someone on the team who has some experience of filmmaking and audio recording. Shooting video isn’t that hard, and these days you can get good results with a half-decent mobile phone. Recording good quality audio is a little harder, and takes a bit more effort. Editing the whole lot into 2-minutes of video is the hardest job of all, and is best done by someone with some experience. Again, it’s beyond the scope of this document to teach you everything you need to know about making films, but:

Tips for making good videos

Keep videos short. Most of them should be 2 minutes or less.
Keep them simple. One film about one thing. Stick to simple shots, and straightforward interview set-ups. There’s no need for special filming locations. If you’re showing the thing, film where the work happens. That will usually be office spaces, with sticky notes on walls. Don’t try to do anything fancy.
Invest in as much team as you can: one person handling camera, sound and interview will struggle to do any one of those things well. The minimum team is 2 people: one handling camera/sound, the other doing the interview. If you can afford and find them, a producer and a sound recordist are useful additions.
Focus on people and the stories they tell. A good video tells the same kind of story that one person would tell another over a cup of coffee.
Video is very good at demonstrating things, showing things, and making the audience feel something. It’s good at generating an emotional reaction.
Video is not good for sharing detailed arguments, lists of numbers, or policy documents.
Video is a tool for communicating something. It’s nothing special in and of itself. If anyone starts suggesting that the video itself is somehow “special” and needs “launching”, do your best to prevent that happening.
Most of the time, writing a script is a waste of time. Most storyboards are pointless too (unless you’re doing animation, but if that’s the case you definitely need professionals involved). Why? Because scripts are very hard to learn and deliver without looking wooden. Professional actors can do it, but they’re professional actors. Most civil servants aren’t good at it, and look wooden if they try. To avoid them having to, think about the answers to questions like: What do we want to do with this film? What do we want the audience to know, understand or feel after seeing it? What work should we show? Who should we interview about it? Instead of writing scripts, focus on finding good interviewees, and getting good interviews out of them.
A good interview is a conversation that happens to have a camera present. The interviewer should do the hard work to make the conversation flow, and make the interviewee feel relaxed. Most interviewees are nervous at first, but most tend relax after a few minutes.
You can be more brutal with video editing than you can with text editing; this is related to the way that video is good prompting an emotional response from people. Even if you edit a video very hard, you can still tell a good story with it, because the visuals help the audience to fill in the gaps. The same story told in text form would look and sound different, because words would be doing all the work.
Remember that video usually exists in context - embedded in a web page, Tweet or a presentation. Use that context to introduce the topic and add extra detail, if needed.

What to do when you get blocked

Sometimes, there are people or circumstances that create blockers to communication (agile or otherwise). What do you do then? Here are a few ideas.

Low-key comms: just a Twitter account might be enough to get the word out.
Personal comms: you are allowed to have opinions and to write about what you think. Members of your team can write and publish about their experiences of working in the team. They should stick to their personal views and experiences, and not try to formally represent the entire team or an entire government department.
Go wider: if you have a writer who understands agile comms, offer that writer’s help to parts of your organisation that are outside your remit. Hire a writer to help everyone in your organisation, not just the agile delivery teams.
Internal comms: if you’re blocked from communicating publicly, try communicating internally. Even if there’s no official platform for internal comms, a simple email written well and sent to everyone who needs to understand the work can be a big help.
Restricted comms: if you’re blocked from publishing to the public web, suggest a more restricted audience. Perhaps you could publish a newsletter, and control who is allowed to subscribe? Perhaps comms could happen via a controlled-access mailing list, or a controlled-access Slack team?
Whatever happens, keep trying to secure a mandate to communicate in public.

In summary

Show the thing. Be brief. Be clear.
Write for humans. Write like you speak.
Don't be ambiguous. Say what you mean.
Writing is easier when you get help from colleagues.
If you want people to read something, give them something readable.
If you want people to pay attention to your talk, make your talk interesting.
If you want people to watch your video, keep it short and make it watchable.
Communicate in small doses, frequently. Allow your story to develop over time.
If there’s a corporate change of heart, say so. Help your organisation be as open and honest as you’d like your colleagues to be.
Make things open, it makes things better.