Aligning Content Work with Agile Processes

As a content strategist, I work on teams with agile developers, user experience designers, user acceptance testers, product managers, and data scientists. A mere decade ago, I would have been called a journalist or an editor. I would have worked with copyeditors, proofreaders, graphic designers, and printers—but times, job titles, and platforms have changed. Content strategists have had to adjust to the rise of development-centric projects focused on products. Big changes challenge traditional content culture and processes.

Agile has the potential to set content strategists free from dated ways of working. And developers and designers can help. How can they better understand content and align their objectives and outputs with content producers?

I’ve identified four areas—iteration, product, people, and communication—where developers and designers can find common ground with their content colleagues and help them adapt to the agile world, while themselves gaining a greater understanding of content culture.

Iteration#section2

Most content producers might think that the concept of iteration doesn’t apply to them—traditionally, at least, things aren’t usually published iteratively. Readers expect the finished article to be just that: finished.

But if content teams take a step back and analyze their work in the context of agile, they will recognize that they are already regularly adapting and adjusting to changing circumstances. The content landscape already has many of the characteristics of an agile environment. Consider these scenarios:

• A story is breaking on social media and you need to get your brand involved as soon as possible.
• A new source emerges with vital information just as you’re about to publish.
• A massive national breaking-news story consigns your lovingly crafted PR campaign to the scrap heap.
• A deadline one month away is pulled forward by two weeks, throwing workflows into chaos.

Requirements and constraints change just as readily in content as in agile development; deadlines can be viewed in the same terms as sprints.

The key to content teams understanding agile iteration is helping them view content like building blocks, where each communication makes up a larger message and that message becomes more honed, focused, and optimized over time. Content folks readily use data to get information on audience, platforms, and engagement so in a sense they are already in the business of iteration.

How can developers encourage this? Well, for example, during a new build, don’t accept lorem ipsum text—politely ask content people to knuckle down and produce a first iteration of the actual content that will appear in the finished product. If you’re using a content-first strategy, this is self-explanatory; even if you’re not, though, early content iteration creates focus and sends a positive signal to stakeholders. It helps them better visualize the end product and, most importantly, gives your team a first draft to build on to challenge those stakeholders—marketing, sales, data scientists—who need to give feedback on the process. Their feedback may be as simple as a bunch of questions.

On a critical conversion page, for example, the stakeholders’ notes might read, “Is this where our super-important CTA is? Have you A/B tested this? Have we benchmarked it against our competitors?!” Or, “Hey data science! Just wondering if you could check the tagging on this page when you get a moment… I’ll need solid tagging to measure its popularity! Thanks.”

View each unit in the content-production process as a single step on the path to your final goal rather than an end in itself. This fosters early and continuous development, frequent delivery, iterative pieces of output, and sustainability, all of which are cornerstones of the agile approach.

Additionally, by using team collaboration or project management software to create, plan, review, edit, and publish content, key stakeholders are given both oversight and readily accessible insight into the fluid, iterative process of content production.

This puts content at the heart of development and UX. Even when other strategies are in play (such as when developers are working to a waterfall model), make sure that content milestones are agreed upon early and allow stakeholders to see exactly what’s going on. This open, documented approach also works great when content isn’t directly feeding into a new build, but is part of an ongoing, business-as-usual workflow. It sets a powerful precedent and showcases how iteration can be easily tracked on both dev and content sides, providing an early focus on regular milestones.

Product#section3

Content strategists should easily be able to recognize how agile principles apply to their output: frequent delivery, sustainable development, attention to detail, good design. More difficult is determining how content should fit into Kristofer Layon’s product-development framework.

My favorite strategy is a content-first approach because it’s bottom-up. The smallest unit of currency in any development or design project is a word, an image, a punctuation mark. Everything grows out of this. While other strategies can be convincing, readers generally don’t visit a website to swoon over a sublime user journey, admire the poetic code, or gaze in awe at the artistry of the design.

They come for content.

Even in waterfall-driven projects, though, a content-first “lite” approach can work very effectively when content output is addressed early and prominently in the requirements-gathering process.

Whether agile, waterfall, or some hybrid thereof, the key is to synchronize UX and content early in the discovery phase and lock that collaboration in so it becomes a cornerstone of the project.

Additionally, a content-first approach doesn’t have to apply solely to new stuff. Existing products can benefit from an overhaul where the content-production cycle is broken down to its smallest components, and then optimized and rebuilt to better effect with, perhaps, optimized calls to action, punchier copy, or more dynamic imagery.

A content-first strategy also creates boundaries, ownership, and a sense of control. It places content at the heart of the agile process from the beginning rather than tacking it on as an afterthought once design and dev work is underway. This gives content managers a more insightful and impactful window into the agile world from which they can adapt their own processes and workflows. I’ve seen projects flounder spectacularly when various business departments go to battle with their own vested interests.

Recently, I was asked to ship a new online product by the print arm of a department I had never worked with before. I was hesitant, but saying no wouldn’t have been a wise move politically. I foresaw problems because of the tight timeline combined with the fact that the company was new to the product-management framework but hey, this was a newspaper with a thriving digital business. What could possibly go wrong with a content-first approach?

The problems quickly escalated as I tried to corral over 40 people (five percent of the entire workforce!) in a half dozen departments, all of whom wanted their say in the transition of the product from print to digital.

In retrospect, this transition would have benefitted from a dedicated project manager who could have streamlined communications and better managed stakeholder expectations. If you’re struggling to pull all the strands together in a project involving complex content and development work, it’s never too late to pull back and take a bird’s-eye view with the product or project manager, head of content, or head of development to try to regain perspective and address any challenges.

Whether your project employs an aggressive content-first strategy or a “lite” version, understanding and embracing content in the context of product instills a sense of ownership and investment on both the development and content side. Both teams will see early dividends from this mutually beneficial approach.

People#section4

Years ago, I developed an admiration for dev teams. They seemed calm under pressure, thoroughly professional, deliberate, focused, and, above all, respectful—pretty much the antithesis of many newsrooms or communications teams I’d been part of. As my career developed, I was fortunate enough to be able to build my own teams. I looked to these qualities (outlined by Jonathan Kahn), as key characteristics I wanted in the people around me.

Whether building a team from scratch or inheriting it, we apportion ownership—and that empowers. That’s the key to building strong, vibrant, successful teams. My preferred strategy for doing this is to confer end-to-end ownership on each piece of content so that its creator also oversees the review, optimization, and publishing process (including working with the developer or designer). Exposing content creators to agile practices through stand-up meetings, discovery and planning meetings, retrospectives and group communications will give them a more holistic, invested view of operations.

Lifecycle ownership motivates and trusts individuals in an agile way. It also has the advantage of giving devs and designers more influence while broadening the skills of content producers through increased exposure. This will ultimately assist the move toward agile self-organization within the team. Self-organization allows teams to create their own opportunities, which builds individual and collective confidence and challenges people to regularly test their limits.

Motivation and trust will blossom in this environment and help ensure the focus will always be on your people. If you get one thing right, make it your people; the rest will fall into place.

Communication#section5

Given that communication is at the core of content, you’d be forgiven for thinking that it would be an obvious area for content producers to put their best foot forward. But unfamiliar language such as dev- or design-speak can be intimidating.

Patience will be its own reward here. Encouraging daily communication between devs and content is an ideal way to immerse each in the challenges the other faces and a great opportunity to highlight how agile can be a positive force within content.

And—even though content folks might not (yet) be accustomed to this—I’ve also found it beneficial to introduce morning stand-ups into my content routine. The opportunity to collectively address challenges for a few minutes each day amplifies both individual ownership and team responsibility.

Even more beneficial is when developers invite relevant members of their content teams along to stand-ups. I’ve always been pleasantly surprised how receptive each side is to the challenges of the other. Encouraging content to attend for the duration of a sprint both allows them to see the beginning, middle, and end of the release cycle and helps align goals.

As a developer, if you commune, share, and consume with your content team, the “us and them” divide soon crumbles. Before you know it, you’re fully exposing content folks to the agile environment.

Good communication is vital, says Inayaili de Leon. The agile principles of daily cooperation and face-to-face communication create regular opportunities to surface and address problems.

Prevention is always better than cure, of course, but in organizations with a multitude of moving parts, communication can break down, particularly in the heat of battle. What to do then?

If things begin to go awry and face-to-face is not enough, you may need to make a more compelling case for communication change. The best route is through rigorously collecting specific examples of the problems your team is having with content. Solutions can lie in the precise documentation of blockers, resource challenges, and impact assessment, particularly if related to return on investment.

Agile communications should always favor the personal over the process, and collaboration over confrontation. And while sometimes we have to revert to the latter when the former proves insufficient, we should always try to remain positive and strive to build on our failures as well as our successes.

A Rallying Cry#section6

Adaptability is hard-coded into our genes. Not only is it essential for survival, but it helps us flourish. As business environments change and roles adjust to new technologies, platforms, tastes, and consumption habits, so we (developers, designers, content strategists) must look for ways to remain at the cutting edge of our disciplines.

Traditionally, content was the message; developers provided the method of delivery. The two coexisted side-by-side, if occasionally a little uneasily. But our mutual dependencies have forced us closer together. I believe that the open, collaborative, people-focused, and change-embracing approach of modern agile development is a framework within which content work can refine itself, test, and learn.

By taking this step on the path to helping content align itself with agile, you may find both your development and content teams energized—maybe even revolutionized.