Sprint but Iterate: How Product Content Pros Can Adopt/Adapt Agility (Part 1)

As product teams have adopted Agile development methodologies, product content professionals often find themselves stuck between agility and review cycles.

How can quality product content be developed in two-week sprints? Where do content strategy, content operations, and content standards fit into the constant evolution of software products? Where do the various disciplines within the content continuum fit in? (For example, UI, Help, API, and Services content?)  How can everyone work together to deliver product content that is consistent, useful, accessible – and agile?

Many of the challenges for product content developers working within an Agile/Scrum framework have stemmed from the tensions inherent in applying an aging methodology to evolving work requirements.

4 Inherent Tensions

These tensions exist within the Agile methodology itself, now almost 20 years old, and in how the methodology has manifested in the product development world, particularly in software development.

The assumption that a one-to-one relationship exists between a software development sprint and the user’s need for new content is a false one.

Tension 1: As Jason Bloomberg noted in a provocative blog post in early 2020, a software development manifesto created by a bunch of white guys in 2001 has lost some of its luster of late. Agile/Scrum advantages “small, relatively uniform teams” working on small SW projects, he points out. But it can kill creativity and even impose rigidity where there was none before – and it doesn’t scale well.

None of that bodes well for developing broad-scale, high-quality product content, especially in a large enterprise.

Tension 2:  Reading the manifesto itself reveals another conflict. “Self-organizing teams” who “deliver working software frequently” (which is the “primary measure of progress”) are also supposed to come up with the “best architectures, requirements, and designs.” Huh?

Inherent here is the assumption that these “motivated individuals,” who are constantly performing, also have “the support they need.” In other words, they rely on some existing base, some infrastructure, to start with. Wouldn’t that support be the requirements-gathering efforts, the design standards, and an overarching architecture? Or are we talking about interns fetching coffee here?

Tension 3:  Josh Seiden, in a 2019 blog post, captures another of the miscues among Agile practitioners, especially those responsible for user experience (UX): the definition of “done.” Does that definition include user validation or not?  

That is the tip of the iceberg of the largest tension in the Agile methodology for product content developers: the need to refine through iteration. And they don’t often know what to refine until they see how the words, concepts, and assumptions are interpreted. (Truth be told, product developers themselves benefit from these exercises in interpretation, too.) Sometimes whole pieces of content need to be tossed out or significantly reorganized because of a wrong assumption. Not easy to accommodate in a 2-week sprint.

Tension 4:  Some would divorce the product content development effort from the Agile/Scrum sprints entirely. This enables the content team to maintain a clear dedication to the quality of the work and a unique closeness with the content’s audience. After all, our role as content developers is to help the product’s users perform their jobs, and, to do this, we cannot get caught up in the latest shiny, new feature.

It is true: the assumption that a one-to-one relationship exists between a software development sprint and the user’s need for new content is a false one. Sometimes that development effort focuses on making a certain backend process run faster. The improvement delivers user satisfaction but does not necessarily mandate that we add or update content.

But what of our needs as content writers to stay close to and even influence the development of the product itself?

5 Agility Needs for Content Development

These tensions help us recognize five needs for product content developers who work within an Agile/Scrum framework.

Our ability to be agile is directly related to having our foundational needs met.

Need 1 – Ability to accommodate both creativity and scale. Product content can be templated for consistency, which assists with scalability in the enterprise development environment. But where does that leave creativity?

Anyone, including a product engineer, can complete a template. Product content developers must be able to offer unique, creative talents to a team focused on delivering the next round of code. Concurrently, product development teams must recognize the diversity of talents that a content development team can bring to bear on a project.

Additionally, product content development organizations must be able to accommodate economies of scale without sacrificing standards or pulling all-nighters. We must be able to legitimately say, “We will accommodate the schedule needs by leveraging our processes and artifacts.” Or explain why not.

Need 2 – A base of standards and infrastructure on which to build. Product content development isn’t done in a vacuum. (And I would argue neither is software development.) High-quality product content is built on a foundation of user knowledge, product knowledge, evidence-based processes, well-understood standards, and useful, up-to-date tools. No one should expect a content development team to cobble together output based on guesses and assumptions and using out-of-date tools simply to meet a deadline. Our ability to be agile is directly related to having our foundational needs met. (No apologies for sounding a bit “Maslow-ish” here.)

Need 3 – Two simultaneous cycles: development and refinement. We need to put the concept of iterative improvement back to front and center in our Agile processes. (See bonus content below on the reasons for content iteration.) In the product content development world, that means both development and refinement have to occur at the same time, though perhaps on different sets of content, managed by different developers.

While we’re at it, let’s put the concept of feedback-driven improvement (judiciously applied) back into our Agile processes. Content developers must be able to revise content based on new knowledge and carefully analyzed audience feedback. In a perfect world, content evolution is not divorced from product evolution; and in fact, content developers, with their well-researched insights, can drive product evolution.

Agile teams must recognize both the dependent and independent nature of product content development.

Need 4 – Autonomy AND engagement. Not everyone can or should produce high-quality product content. There is a reason that product content development has evolved as an expertise alongside software development expertise. Practitioners, in both cases, offer unique skill sets. Yes, sometimes those skill sets overlap, but that doesn’t mean one skill set can be substituted for the other – or should be made subservient to the other.

Agile teams must recognize both the dependent and independent nature of product content development. Content developers need a deep and broad knowledge of the product, its uses, and its users to be successful. We depend on our SMEs to help make us successful, supplying us inputs, giving us access, and engaging us in conversations, meetings, and product demonstrations. But when we sit down to create content, we must be able to work thoughtfully, step through our own processes, gather our own insights, and measure our own successes. Only then can we bring our full expertise, as equals, to the team effort.

Need 5 – Agility always.  To thrive in an Agile environment, we, as product content developers, must embrace the concept of agility, which contains the ideas of nimbleness with fluidity. We must be nimble enough to quickly assess what is doable for and useful to our audiences within the context of an Agile project. We must also be fluid in the execution of our processes (repeating them when necessary) and open to evolving them when needed.

Here I am embracing the broader definition of business agility, described by my colleague Gary Rupp. For Agile product content development to be successful, we must be able to “rapidly evaluate alternatives and competitively respond to changes…and do so from a customer-centric and value-added perspective.”

In my next blog post, I offer some direct observations of product content development in an Agile environment, with a close look at the role that a ticketing system like JIRA plays. In my final blog post in the series, I examine an “ideal” workflow for product content development and how it can be supported in a ticketing system.

BONUS POST: Reasons to Iterate Content

I recently posted on LinkedIn the following list of reasons to iterate (revise) a piece of content. What did I miss?

1. Iterate for content correction:  If the content contains a factual error or misleading claim, update for accuracy (and avoid legal issues).
2. Iterate for coding correction:  If the content fails to publish/display correctly, update to correct the markup.
3. Iterate to adjust the level of detail:  If the amount of detail in the content does not match the audience’s needs, revise to expand or streamline.
4. Iterate for lack of clarity:  If the content confuses its intended audience, revise for improved readability and usability.
5. Iterate for mismatched tone or intent:  If the content misses the mark with its audiences entirely, rework the concept or conduct more research before producing more or replacement content.
6. Iteration for missed standards:  If the content fails to meet content standards or follow an approved template, revise for consistency.

Often more than one reason drives content revision. The challenge for us in product content development lies in explaining why a revision is necessary. Our project partners can fall into the trap of thinking we are merely “tweaking,” when in fact, we are meeting needs, goals, and requirements.