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.

Set of colorful gears that interlock with each other.

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.

Colorful concentric circles centered on lowest edge. Each circle is labeled, with strategy at the center. Orange stripe at the base for Business Goals and Product Portfolio Vision.

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.

Spiral stairwell, viewed from the top. Colors are brown, grey, and orange.

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.

Workflow diagram with two streams moving from left to right from a large oblong labeled "Backlog." Blue arrow on left points to the strategy loops for Phases 1, 2, and 3. Below that, the yellow arrow on the left points to the tactical loops for Phase 1 and 2.

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:

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

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s