Sprint But Iterate: How Product Content Pros Can Adopt/Adapt Agility (Part 3)

Agility isn’t difficult. What is difficult is sustaining a rapid work pace without knowing why, without having context. Context is especially important for product content developers. That is why my proposed ideal for an agile content development system continuously provides context for the work at hand.

I’ll explain in detail here. But first let me provide context for this blog post.

In the first blog post in this series, I outline the inherent tensions in the Agile methodology, especially for content creators. Then I described 5 ways in which Agile projects should accommodate contemporary content development needs.

In the second blog post in this series, I examine the pros and cons of 3 “agile” scenarios that engage content developers with workflow tickets in some way. The third scenario actually placed content strategy at the center and demonstrated how 3 types of content development tickets can flow out of that centralized strategy.

For our ideal, I’ll start there – with strategy at the center.

The Meaning of Centralized

If strategy is to be the center of our ideal, then product content strategy, user experience (UX) strategy, and product strategy should all flow from a centralized strategy effort. I mean “centralized” in two ways:

• Centered in the enterprise
• Shared effort in a single vision

To be centered in the enterprise, the strategy effort must support the organization’s goals, engage the larger product portfolio vision, and be grounded in the organizational infrastructure, including governance.

This kind of strategy centralization opens some cracks in the concept of autonomous Agile teams. But as Tom Johnson points out in a 2019 Intercom article, creating anything in “enterprise isolation” can lead to inconsistency and poor integration, among other problems, and ultimately erode the user experience.

Some contemporary Agile platforms ease the isolation factor by carving out enterprise-focused efforts that run in parallel to product development projects. For example, a Scaled Agile platform, carves out separate management efforts for the product pipeline, the product portfolio, large solutions, and a release pipeline. Each can be thought of as a gear that turns with some synchronicity with the others.

But while this concept helps reduce the chaos possible with dozens of autonomous teams, it doesn’t quite align with my second definition of “centralized”: shared vision work. In a highly “teamed” environment, work doesn’t move forward smoothly unless everyone shares the same vision. In fact, that is one of the unspoken assumptions of the Agile methodology. And the most difficult one to achieve.

A place to start, is with a single cross-discipline strategy for the production engine: what are we delivering to whom to meet what need under what circumstances and with what expectations? Among these “w” words are the disciplines of:

• Product strategy (what, circumstances, expectations)
• User experience (whom, need, expectations)
• Content strategy (whom, need, circumstances)

And yes, they share all of those “w” words because you can’t, I believe, have one discipline without the other. None of the three can stand on its own in isolation in a successful product development environment. (Let the scathing rebuttals begin! :] )

A Spiral of Systems

With a cross-discipline strategy at the center, the ideal environment flows outward in a spiral of systems: strategy, development, measurement, and governance/architecture. As with Scaled Agile, my spiral carves out separate systems for more encompassing “enterprise-level” efforts. And as with Scaled Agile, this ideal captures the inter-dependency of the system set.

But why a spiral?

At first, I conceived of this ideal as a set of concentric circles, each larger than the first – the strategy – and each flowing outward from that strategy.

I shaded the “membranes” between each circle darker to show that work passed between each circle. But that solution didn’t quite capture the interrelationship between measurement and strategy, for instance.  (Remember, I am a content measurement enthusiast.)

So I settled on calling the concentric circles a spiral. You can see it if you squint and imagine that the largest circle is the piece of the spiral that is closest to where you are standing, and the smallest circle is farthest away. In appearance, it’s like this spiral staircase.

The spiral is important for two reasons:  

1. Spirals are efficient. Like the spiral florets of a sunflower before it blooms, spirals compact a lot of energy into a tight space
2. Spirals connect the outer and the inner. The structure of a spiral swirls both toward and away from the energized center.

If the center of our ideal is our cross-discipline strategy, then it is the energy toward and from all other efforts flow in the most efficient manner possible. It rests on the “foundation” of business goals and product portfolio vision.

Flowing with Work Tickets

Because I outlined how I worked with JIRA tickets within the “agile” scenarios I described in my previous blog post, let me bring the idea of workflow ticketing to the ideal.

Note that I have not worked within an organization that embraces the ideal – the systems spiral I just described – so the diagram I share here shows my vision of how a workflow ticketing system could work within the ideal to direct the strategy and development for a product, its user interface, and its content. Also, note that my vision owes thanks to the writings of Jeff Gothelf – for the idea of strategy feeding tactics – and Gretyl Kinsey – for the idea of incremental content strategy.

The diagram is a bit of an eye-chart, so let’s break it down, starting on the far left.

• Tickets flow from a common backlog:  All of the strategy work tickets and tactical work tickets stem from a common work backlog for the product effort. In JIRA terms, this backlog might be prompted by an initiative-level ticket.
  
• Design informs everything:  All of the work that flows from the backlog is informed by design – product design, UX design, and content design. As Gothelf emphasizes, every team must include at least one designer.
  
• Strategy work is incremental, too:  The strategy for development (product, content, and UI) is released in phases. Each phase focuses on a particular user experience.
  
• Iterative overlapping loops for strategy and tactics:  Work on each phase starts with an iterative strategy loop. The iterative tactical loop for the current phase overlaps the strategy loop for the next phase.
  
• Each strategy loop includes three main steps:  The work begins by breaking down the UX focus into a strategy or strategy goals. That strategy is then validated through conceptual documents such as wireframes or prototypes, or other mechanisms. That validation can engage users or customers. The validated strategy is then formulated into a plan, which might also include specifications, templates, guides, or other job aids.
  
•  Each tactical loop includes the typical and the not-so typical “agile” development steps: 
  • The tactical loop resembles the typical iterative agile development loop. The phase’s plan is implemented; the implementation is tested and measured, and then the implementation is iterated for improvement.
  • In a not-so-typical flow, the measurement effort can flow back to the strategy loop for further validation and to justify adjustments to the next phase.
  • Additionally, the iterative/improvement step can feed into a greater continuous improvement effort or into the release pipeline included in Scaled Agile.
    
• The strategy work supports the business goals and product portfolio vision:  Any strategy that drives any implementation work must be closely connected to the organization’s goals and a shared vision for the product portfolio. As I mentioned earlier, that connection can be captured in JIRA epics that flow from a JIRA initiative. Additionally, a strategy’s success should be measured against how well it interprets the goals and vision.
  
• The tactical work is supported by two important infrastructure systems:
  • The governance models, which include coding and content standards and the processes that enforce them.
  • The architecture models, which include the design architecture model and the information architecture model.

Despite being an eyechart, this workflow ticketing model would require more detail before it could be implemented. I’d be happy to discuss my ideas for that with you if you contact me. But suffice to say that it enables both strategy and implementation to have some agility and some autonomy, without breaking the enterprise.

Finding Agility

And speaking of the enterprise, even within an ideal one, content development teams still need to find ways to be agile. “Agility” in the workspace is likely to be trend for the foreseeable future. So how can we be more nimble?

I have touched on a few ways in previous blog posts and in my 2020 presentations. Here is a summary:

• Centralize user profiles:  Everyone should be working from the same set of realistic user profiles.
  • Blog post:  https://dkconsultingcolorado.com/2020/09/20/tips-for-developing-a-real-user-profile-for-a-content-strategy/.
• Combine a content audit and plan:  Attach a review of existing content for the current strategy phase to the strategy (epic) ticket itself.
  • Blog post: https://dkconsultingcolorado.com/2020/09/08/how-to-develop-a-combined-content-audit-and-plan/.
• Automate content output:  Leverage spreadsheets and scripting to output “shell” (rough draft) topics in your structured authoring environment.
• Create and test quick prototypes:  Use a staging site to quickly create a prototype of a new content type for iterative reviews and improvement.
  • ConVEx2020 presentation: https://convex.infomanagementcenter.com/chat-presentations/#tab-fffa7cad0ebc2bdc49d.
• Include non-traditional writers:  Stretch your toolset and processes to be more inclusive of expert writers.
• Run content reviews in parallel:  Don’t skimp on a SME review or a standards review of a content set; run the reviews in parallel.
  • Tech Writers Tribe presentation (YouTube):  https://www.youtube.com/watch?v=XfDPLtjwdxY&t=36s.
• Reuse and repackage existing content:  Reduce workloads in a busy environment by including the reuse of existing content in your strategy or plan.

My ConVEx 2021 presentation focuses on the content from this blog post and the two previous blog posts.