The Agile Editor

If you’re a web editor, you might already work in a company that practices agile software development. But even if your company or your clients haven’t made the transition to agile, they probably will. Agile has been increasing in popularity over the past few years, so it’s a good idea to have an understanding of how agile works and how you can champion content and editorial best practices within this new framework.

What is agile development?
Basically, agile is a faster and more flexible way of managing software and web development projects. Traditional software development involves a “waterfall” approach, with defined phases that move from one to another without overlap: from requirements gathering to design to development to testing to launch. In waterfall, project phases tend to happen in silos (development does not involve feedback from designers, etc.) and can take a considerably long time. And requirements usually can’t be changed until the project is complete.

The agile movement started with the agile manifesto. A group of IT professionals created the manifesto in response to the issues they had with the negative aspects of the waterfall process:

• Project roles are isolated and communication between the business owner (and the customer) and the team is non-existent.
• The products take too long to get to the end customer.
• There is no method for adapting to changing business or customer priorities.
• A focus on lengthy, technical project and spec documentation is time-consuming and produces documentation that is difficult to utilize.
• QA and bug-testing are often rushed, so products are frequently released with many bugs.

Agile aims to address these negatives by:

• Giving the team a voice in making decisions
• Releasing the product frequently (usually every two weeks or once a month)
• Focusing on product features that are the most important instead of just features that have been approved, allowing for priorities – and requirements – to change
• Using short, easy-to-understand documentation (or no documentation at all)
• Performing frequent QA testing.

Agile encompasses many different methodologies (for example, extreme programming or DSDM), and all of them follow these basic concepts. But the version of agile that seems to be the most popular is Scrum. Scrum (the term comes from rugby) focuses on “sprints”, which are short work periods used to plan software releases. The length of a sprint may vary; I’ve usually worked on projects with 2-week sprints.

Scrum teams usually consist of the Scrummaster, who records the decisions the team makes and brokers issues between team members; the customer (often the business sponsor), developers, product and project managers, UX and visual designers, copywriters, and the QA team. At the beginning of each sprint, the team holds a meeting to prioritize the product features to be developed. The priorities are broken down into tasks (groups of related tasks are called “stories”), and these tasks must be completed within the sprint. Any product features that are not part of the sprint are relegated to the ‘backlog’, essentially a master list of all of the features that need to be developed and tested. The backlog may grow as new requirements and issues are added or discovered.

Each day the teams holds a “stand up”, a 15-minute check-in meeting. On some agile teams, members will actually stand up to ensure the meeting does not go over the time allotted. Members are asked to describe what they completed the day before, what they will be focused on today, and if there is anything blocking their work that the Scrummaster needs to address.

So how does a Scrum project affect a web editor?
In my experience, working on a Scrum project means an editor needs to work harder to ensure that editorial priorities are being met. One of the challenges of agile is that the focus on individual tasks and stories can cause the team to lose sight of the big picture of the overall user experience. Additionally, UX and content deliverables like wireframes and copy and are often rushed at the beginning of a sprint so that developers can start coding, QA can test, and the team can launch the updated product by the end of the sprint. So a careful review of user interactions, copy, and design elements often does not take place; the team is focused on functionality, not content or UX.

On the plus side, the fact that there are frequent releases means that when you do surface an issue, it can get resolved far more quickly than it would if you were working on a waterfall project and had to put your request into a long queue.

Here are some tips on how web editors can work within an agile environment:

• Focus on relationships. Agile development is built around communication. Team members are encouraged to work together directly instead of through documents, group meetings, or project managers. Get to know the developers and the QA team. You want them to come to you when they have questions about content rather than make guesses or ignore issues (which some people will do if they’re not encouraged to ask questions).
• Go to the standups. Sometimes project managers will go as proxies for their team, or certain team members will sit out sprints if they don’t have a specific task assigned to them. But make sure you attend the sprint planning meeting and as many standups as you can so you can advocate for the product features from an editorial point of view. Inevitably, questions will arise as developers work on new features, and if you’re involved, you can help ensure that the end user and your editorial vision are represented. You can also help steer the team away from solutions that stray from your content strategy, necessitate an inordinate amount of explanatory or directional copy, or don’t align with your brand.
• Train the QA team on content and style. You can’t expect your QA team to be proofreading; their focus is on testing functionality across platforms and browsers. But take the time to give your QA team some background on style guides, design standards, and content requirements. This will increase the possibility that they will help you catch inconsistencies. And, if you’re building relationships as noted in #1, the QA team will be comfortable coming to you with questions.
• Scour the backlog before the end of every sprint. Revisit end-to-end functionality – for example, a sign-on process or a site search.  Perform every step to make sure that the interactions are intuitive and consistent. Review your product with a focus on the user experience and on your business objectives, annual goals, editorial calendar, etc. This will help you determine what the team should focus on in the upcoming sprint, and you want to go to the next sprint planning meeting with these priorities already in hand, because work will begin immediately. Also remember that when reviewing the backlog, changing priorities might mean tasks should be removed from the backlog and replaced with new ones.
• Volunteer to test whenever possible, including on launch night. Unexpected things can happen during testing, and you want to be there to help advocate for the best solution.
• Master the bug tracking system. Many content and marketing people will avoid bug-tracking; it’s not the most exciting activity, and some see it as the QA team’s job. But as an editor, you’re already trained to look out for inconsistencies and imperfections. Ask for access to your QA team’s bug tracker if you don’t already have it, and record any bugs you find. That way you can ensure that any editorial problems are tracked and assigned to the right team members for resolution.

Agile can be daunting when you’re accustomed to traditional software development. But be open to its positive attributes, and you’ll find opportunities to educate your team on why editorial review and high-quality content is important for the products you all care about.