18F/18f.gsa.gov

View on GitHub
_posts/2016-05-31-taking-an-agile-approach-to-content.md

Summary

Maintainability
Test Coverage
---
title: "Taking an agile approach to content"
date: 2016-05-31
authors:
- nicole-fenton
- kate
tags:
- agile
- content design
- design
excerpt: "At 18F, we work in an agile way — in other words, we base our designs on user needs, conduct usability testing, iterate quickly, and release MVPs (minimum viable products) rather than highly finalized releases. We take an agile approach to content too."
description: "At 18F, we work in an agile way — in other words, we base our designs on user needs, conduct usability testing, iterate quickly, and release MVPs (minimum viable products) rather than highly finalized releases. We take an agile approach to content too."
image:
---

So, you’ve recently joined an agile team — congratulations! Here at 18F,
[we work in an agile way](https://pages.18f.gov/agile/) — in other words, we base our designs on user
needs, conduct usability testing, iterate quickly, and release MVPs
(minimum viable products) rather than highly finalized releases.

We take an agile approach to content too. While there’s really no
“ideal” project or process most of the time, we’ve found that these
guidelines help us develop useful services for millions of people.

Participate in the process
--------------------------

Though every team is different, most agile teams follow some common
processes, such as standups (team check-ins at predetermined times),
demos, sprint-planning meetings (where your team decides what tasks to
tackle during the next two-weeks), and retros (checking in with your
team to see what worked well and didn’t work so well during a given
sprint).

The first step in working well in an agile environment is getting
accustomed to your team’s particular process. Here are some tips for
doing just that:

-   **Find out how best to participate.** Depending on your involvement in a project, you might not need to attend each and every meeting. Talk to your project lead to find out which ones are mandatory, and which ones are nice-to-haves.
-   **Use your team’s tracking tools.** There are a lot of different tools to track progress and report bugs. We often use GitHub issues or Trello boards, but other teams may use JIRA, waffle.io, or another task-management system. File content issues for yourself so your teammates know what you’re working on and can ask relevant questions. If design or technical bugs come up, file those, too.
-   **Keep the conversation going.** Make time to chat through content blockers as they come up. You may run into conflicts committing your work to code, or you may need help with your content management system. Regardless of the snags you run into, be open with your team. Good communication helps everyone manage their time (and stick to deadlines, however rough).

Even if your team’s system wasn’t explicitly created for content
processes, find ways to track your work using those tools. In doing so,
you can help your team understand how complicated the writing and
publishing process can be.

Break your work into manageable tasks
-------------------------------------

It’s sometimes hard to know what to do first — especially if you’re
working without a clear product vision or set of milestones. Here are a
few ways to get started:

-   **Start with the most important tasks.** Don’t try to audit the entire website in one go or write your style guide in one sitting. Pick the most important sections or tasks first, see what you learn, and go from there.
-   **Get feedback early and often.** Once you have a rough draft together, share it with a few of your peers or users, and polish it afterwards. Agile has a faster feedback cycle than traditional publishing models — and that’s great for your content, because the more you talk about it, the more conversational it will be.
-   **Be okay with leaving some things unfinished.** This can be really hard for content folks, because we’re detail-oriented and love making things consistent. Part of working in an agile way is staying flexible and responding to shifting demands. If you need help with something, but it’s not a priority right now, add it to the backlog and bring it up when the time is right.

Set squishy deadlines
---------------------

As a writer, you need to balance long-term project work with day-to-day
business tasks, and align your efforts with your team. One way to make
this easier on yourself is to set squishy deadlines:

-   **Map out your editorial process.** Content usually needs to go through a number of review cycles with peers, stakeholders, your legal team, and other folks. For better or worse, this process tends to be waterfall. Agile doesn’t always follow a sequential process, but you’ll sometimes need to make compromises. Being aware of the typical review-cycle times will help you with sprint planning, and will also help you stay on top of other commitments.
-   **Factor in content research.** Agile doesn’t mean you have to start writing right away. Make sure to account for content research, like interviews, audits, copy explorations, or defining your organization’s voice and preferred tones. These things need to happen early in the process, and they may not line up with early technical conversations about integrations or platforms. Work with your project lead to make sure you have enough focus time for these tasks.
-   **Align your content efforts with design and engineering** when it makes sense. Keeping your dev team informed of where you’re at (if only in a general sense) will help them better plan their time, which will improve everyone’s workflow. It’s not always possible to be working on the same thing though, so use your best judgement.

Workshop it together
--------------------

Perhaps more so than adhering to specific workflows or using certain
tools, collaborating with your team is central to agile. We use these
collaboration strategies to work more efficiently, build stronger
products, and also have more fun:

-   **Get stakeholders involved.** Instead of working on tasks individually, bring your stakeholders and teammates together to write user stories, plan product priorities, and actually write the content. Not only will folks have a greater investment in the final product, but the final product will be stronger on account of the diverse viewpoints and voices built into it.
-   **Write collaboratively.** Use a tool like Google Docs so everyone on your team can contribute. Collaborative writing tools help everyone quickly get involved with a project, and they do wonders when you’re working across different time zones.
-   **Put your content in a code-friendly format.** Make it easy for yourself and your colleagues to move drafts into code. We rely on Markdown and plain-text editors to avoid those pesky styling issues that come up in when copying and pasting from traditional word processors. Once a draft is pretty solid, we manually convert it or use tools like [Pandoc](http://pandoc.org/) to speed the process along.

We mentioned it before, but it bears repeating: The best content is
conversational, and the easiest way to achieve a friendly,
conversational tone is to talk about your content with your team.
Fortunately, agile is inherently kind of conversational — the process
encourages sharing ideas, brainstorming solutions together, and getting
feedback quickly. Use the freedoms unique to agile to draft and iterate
quickly, experiment, and get your content in shape faster.