Content Strategy, Agile Methodology, and Sartre’s View of Hell

Not so long ago, agile methodology practitioners were all developers. They would swear that there was no way UX design could fit into the mix. Agile was for development-centric projects. The methodology empowers developers to build and create, “fundamentally incorporat[ing] iteration and the continuous feedback that it provides to successively refine and deliver a software system.” (VersionOne) In a system like that, it was long thought, there was no room for UX design or content.

Today, “agile” is like a new sort of ice cream, with a wide variety of flavors. There are UX design teams working in “agile for UX,” and others branching out to Lean UX. Both put an emphasis on prototypes over wireframes, and collaboration over documentation. But agile is as prone to the game of telephone as anything else. So as the word of agile spreads, it morphs, or evolves. That’s what brought me to look at what happens when content strategy is integrated into agile.

Agile Methodology

I’ve learned to be wary of anyone who claims to have a “purely agile” project. For one thing, the moment I am hired as a content strategist, the agile methodology is not “pure.” If it were, I would have to be a developer, and I am not that. I’m a content strategist, and content strategists struggle to find their place in agile methodology. Let’s review a few of the more common tenants of agile methodology, to better understand why content strategy + design + agile is so complicated.

Makers and Managers

Most agile projects have a lead developer (manager) working with a team (makers). Paul Graham’s article on Makers and Managers clarifies the difference. And my role – half of each – has never been more clear than when I entered the agile world.

An agile project is intended to have a strong base of makers iterating quickly. The managers focus on strategy, and keep an eye for what’s ahead. A content strategist falls somewhere in the middle. We can be makers and focus on copywriting, but strategy work requires many meetings, like Graham’s Managers.

Some content strategists try to argue “I’m a maker, I can focus on content creation.” But the moment I was termed “just” a copywriter I was expected to provide words at random, without context. A developer may be able to build a button without context, but a copywriter/content strategist can’t name that button without understanding the bigger picture.

Sprints

Most agile projects are divided into “sprints” or “iterations.” Sprints last an average of two weeks, and are comprised of a set of tasks that together make up a user flow. When UX designers are in agile projects, they’re typically expected to present deliverables on the first day of a sprint. On that first day the developers:

• review business requirements,
• identify the level of effort for the sprint’s tasks,
• divvy up work, and
• look at the user flows (or “user stories” in agile lingo), generally created by the UX designer.

Developers rely on that eight hours at the start of each sprint to reconnect them to the bigger picture. The project lead documents the discussion, and breaks the work into tasks for the workers to edit or update as needed.

Sprints are where designers and developers tend to butt heads. Designers often struggle to keep up with the pace, since a design can’t be divided up in the way development tasks can. Should they work one sprint ahead? Well, no, not if they want to review user stories at the same time as the developers. Should they work in the same iteration only a few days ahead? Only if they can promise to never hit upon a problem or get delayed. (I’ve yet to meet anyone who can keep that promise.) Design and development teams try both of these options, with varying degrees of success.

Agile at its Core

“Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more.” –The Agile Manifesto

The manifesto is simple and straightforward,with a focus on communicating. This is perhaps the biggest reason that adding UX design and content strategy to an agile team is so tough. Adding anything means adding complexity. It takes away from the simplicity, and the more complicated things are the more tempting it is to revert to documentation and long meetings – things that *can* be valuable, but are often merely time consuming.

Are we in Hell?

Jean-Paul Sartre described Hell as “other people.” He was particularly cynical of relationships, which (he felt) required each person to see him or herself as a subject, but the partner as an object – though at least each person was objectifying the person objectifying them! Worst of all, to Sartre, was the concept of a love triangle – a situation where 3 people are each “objectified” by someone different from the person they objectify. In our agile triangle, the three people are the Developer, the UX Designer, and the Content Strategist. We each see the value of what we’re doing, and we know how to keep it simple and within the Agile Manifesto, but we have no idea how to work with the other two.

What Sartre doesn’t take into consideration is the possibility for flexibility and mutual understanding. Here are a few of the ways I’ve found to turn down the heat.

Pair Programming

As is apparent in the name, pair programming was created for developers. It’s straight out of the agile toolbox: two developers sit side-by-side to collaborate on complex tasks. I’ve found it just as valuable to partner a content strategist with a UX designer. While the designer builds out the front end of one area of the prototype, I work on copy for another area. The next day, we swap. I write copy for what the designer finished yesterday, as he/she begins building out the page that I wrote up. We are side-by-side, so we can easily ask questions or talk through challenges, which is exactly the goal of pair programming.

Content Strategy for Planning, Copywriters for Sprints

For projects without a ton of copy, or without a large enough budget, it’s not particularly useful or fiscally responsible to have a content strategist work side by side with developers or designers. Instead, a content strategist can help with pre-sprint preparation. The content strategy and UX designer should collaborate and build the user stories. The content strategist can also create guidelines, so that copywriters will have documented context for all those seemingly random copy requests.

Move Quickly and Prioritize

Liz Bennett and Rachel Lovinger had side-by-side experiences with agile, and wrote about it back in 2011. One of their biggest takeaways was the necessity to move fast. “In an ideal world,” they wrote, “Liz would have done a complete content inventory and gap analysis up front, but there was no time.”

When you know there won’t be time for everything, you prioritize: what research will be most effective? What content areas do we need to create first? Which content areas will impact other user flows? What governance tactics are the most valuable? Every content strategist has an ideal process he or she would like to follow. If we know the ideal, we have all the information we need to begin cutting it down. If we push against the flow, we’ll just fall behind.

Embracing the Chaos

I have a special place in my heart for agile methodology, because it resembles my own form of organization. It’s structured enough to allow for spontaneity. Many content strategists (myself included) like having schedules. Agile is an opportunity for us to embrace chaos – but a highly structured chaos.

We re-evaluate our projects every two weeks. Some people find this terrifying, but I look forward to sprint planning days. Those are the days that I can bring in new information I’ve just learned, with no fear of derailing the project. Instead, we wrap the information into the next sprint.

As Content Strategist Meri Williams wrote, “I didn’t expect user stories to be a great way to define needs and requirements for content too.” There are hidden surprises like this for all of us, if we’re willing to give it a try.

You Don’t Have to Be Agile

Finally, remember that agile isn’t right for every project. Sometimes teamwork brings up additional stresses, and some projects don’t succeed iteratively. For best results:

• work with more makers than managers,
• re-evaluate the plan every 2 weeks,
• and serve with ice cream.