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.

Redesign: Staging and Mapping Your Way to Success

By Cathy Hodson

You have a huge company website, and you have a matter of weeks to move content from your current site to your new site. How do you get a handle on how to move your content and figure out all the logistics involved? If your website has more than a hundred or so pages, or even thousands of pages, with all the associated documents and images, how do you get organized enough to know where your content is currently and how to get it to where it will be going on the new site?

By staging and mapping your content.

Staging your content
Staging is really prioritizing. What do you absolutely have to have on your new site when it launches? This is your first stage of content to be moved, before the launch, and the highest priority.

The second stage is the next level of content that – yes, it would be nice to have it on the site when you launch, but if it’s not, it will be the first content to go up after the launch.

The third stage is the final stage of content to be moved. Usually this consists of back issues of publications or content that could be considered “filling in” – background information, links to other resources, more of what you already have up, the finer details that fill in and embellish on what is already there.

What is mission-critical content? Mission critical defined: your business will suffer and your staff will have to scramble (in a bad way) to help your customers or members if this content is not on your website when you launch.

The actual timeline for all three stages depends on how quickly you need to have everything out of your current/old website. Usually all three stages should take about nine months to one year. To have all your content moved within six months of launch is a good benchmark.

Mapping your content
Once you have your content prioritized, you need to map it. Where does it reside on your site now? Where will it be moving to – most redesigned sites have also reorganized. So the content that might be listed under “Professional Development” on your current site might be split up among 2 or 3 different sections on your new site – Education, Continuing Education, Meetings. Somehow you have to note this for  someone who might not have detailed knowledge of your site (such as a temporary worker or consultant)  – where they would find the original content and where they need to put it on the new site.

The first website redesign I was a part of, the consultant that was building the website gave me a spreadsheet to use to map this process. It had columns for the new site location, the current site location, the status of the content (“testing,” “intro done”), a place for information about the content (such as “content needed” or “6 files, public side”), comments (“under construction” “is this the same as federal section on public side?”), and any changes (“name of section changed from X to Y”), and even a showing of which page(s) on the site link to each page or document listed. You can and should adjust the structure of your mapping document to whatever makes sense to you and your team. Is it better to list your content by the structure of the new site, or the structure from your current site? Up to you. Ask the people who will be moving the content which would make more sense to them? Or make an executive decision and decide for yourself which makes more sense.

Something else that is helpful for content movers, especially if they are not part of your company’s staff, is to print out the pages on the current site, and mark up the page with notations for each of the links found on that page. Does this link go to a page on the same website (internal) or does it point to another company’s website (external site)? The internal site’s links may change, and that should  be noted – either on the page you printed or in the mapping document. If the page being linked to is from another department or division, and perhaps they have prioritized that page to be added at a different stage than when your page is going up, that should also be noted so the link can be added when the other department’s page goes up.

If it is an external site link – does it still work or does it need to be updated? If it no longer exists (or can’t be found), do you have instructions in place on what the content mover should do? Remove the link entirely, replace it with something else, or just leave it as is?

Once the plans for the staging and mapping have been completed, it gives you and your team parameters and guidelines for moving the content.

Content management systems
If you are keeping the same content management system, there may not be as much to do with mapping, prioritizing or moving content. It may be a matter of simply moving files across your system, adapting your content to a new page layout, or reclassifying the content. If you haven’t been using a content management system, but will be using one with the new website, you may pretty much have to reconstruct your pages – reformatting, linking to where new pages are, updating headline and other codes. You will have to do the same if you are changing content management systems.

Other considerations
Perhaps your URLs will change also. This is something that can be noted in the mapping document. A change of URL can be problematic – internally, for the sites that link to you, and for any links you publish on stationery or in publications – either those you print yourself or publications you submit materials to for articles or ads. Business cards may need to be updated, as well as signatures in email.

Any specialized domain names that point to deeper areas of your site may have to be repointed to the new location. For instance, our foundation has its own domain name, but it forwards to a deeper page within our association’s website. That location changed when we redesigned in 2011, and the DNS (domain name service) had to be updated to forward to the new location.

A successful redesign depends implicitly on how organized your team is, how much forethought and planning goes into the moving and launching processes, and nailing down the details. If you have never been part of a redesign before, choose your consultant carefully. You should hire a company that can walk you through the process and support you from both a development and an editorial standpoint. This is paramount to the success of the redesign. A redesign for a large website can take anywhere from one to three or four years, depending on how big your website is, what has to be done – a major overhaul of systems and the website, a simple reorganization and facelift, or anything in between.

Plan, prioritize and map. Iron out the details and make sure everyone understands what needs to be accomplished, when it needs to be accomplished by, and what the ramifications and consequences are if deadlines and project milestones are not met.

Process is not a dirty word

By Rebecca Del Giudice

Several years ago, I was doing contract editing work for a client and we were talking about an overhaul for his content-heavy website.

“Is your content calendar up-to-date?” I asked. I remember the look on my client’s face: suddenly he was like a child who did not want to eat the spinach on his plate.

“I don’t like to waste the team’s time with a lot of process,” he said.

Ever since that exchange, I’ve taken note of the tendency of some teams — across industries — to have a negative view of, and therefore a strong aversion to, any kind of process. Many people have had negative experiences with consultants coming into their companies and imposing bureaucratic, unrealistic processes on their work. Or they’ve worked with archaic project management or software development teams that seem to use processes as roadblocks.

But as most editors would attest that process — whether they’re talking about editorial, QA, or development — can provide a framework that tends to reduce firedrills and make a team more efficient.

But how do you convince a team of that?

Here are five ways to approach process creation with your team:

1. Meet the team where it is.
If your team has utilized process successfully in other places, e.g., they are deploying scrum methodology with great results, or their sales team is a well-oiled machine, use these as models. Find out from people in those departments what has worked and what hasn’t, and how they got to where they are now.

If your team, on the other hand, doesn’t even like to answer emails or document anything, understand that you need to start slow. Don’t overwhelm them with an outline of a lengthy, complicated start-to-end process. Start with one step — e.g., having a brainstorming meeting to lay out some ideas that could form an editorial calendar, or institute the practice of having someone own the final proofreading of every marketing piece that goes out the door.

2. Don’t use the word ‘process.’
Nobody wants a bureaucracy — including you. Don’t get hung up on terms and technicalities. Instead of focusing on the how, emphasize the why — the ways in which this new method of executing work will benefit everyone. For example, say you are establishing a faster, clearer process regarding the ownership of and response to feedback forms on your website. Emphasize how your customers will benefit, and by extension your company. Or if you plan on doing an annual content review of your web properties, don’t dwell too much on the effort involved; emphasize the fact that updating and correcting old posts will help improve search results and how your brand is perceived.

3. Make it a team effort.
Make it clear not only that you are willing to shoulder your fair share of the work, but that your suggestions are not perfect. Even if you are in a position to call the shots on every strategy, engage the team and encourage everyone to share their ideas. Give people ownership, and they will often exceed your expectations.

4. Look for tiny improvements.
So your coworkers just spent one week brainstorming and building a social media calendar. Don’t wait until the end of the year to see if the calendar helped the group’s bottom line and output. When the first article is posted, talk about how well it was received. Noticing small steps along the way helps reinforce the value of the process you’ve put in place.

5. Be humble, and admit when things aren’t working.
When I was working in a large corporation, I often saw executives who would swoop in, change everything that the person before them had worked to put in place, and then look away when the changes wiped out processes that were working. Leave your ego out of it. If a new process isn’t effective, regroup with the team and talk about how you’re going to address it. Maybe your new system just needs a few tweaks, or maybe people need more training. Or maybe it just wasn’t the right idea for your organization.

Be open to change — you, your colleagues, your customers, and your company will all benefit.