The last  couple of posts seem to state the obvious. They are , basically, variations of know your reader/customer. So, how hard could it be?

In my experience, there’s never time to do all of what is suggested. As a professional writer, the “topics-to-write” list has always been longer than the time available to write them—often by an order of magnitude.

Exactly the situation Agile was designed for.

I would think that writers would flock to Agile, if it’ll solve the problem of “so many docs, yet so little time.” And, they might, if given the chance.

Yet, in an unscientific study of documentation planning methodologies, they all look like they are based on a plan-driven (a.k.a. waterfall) project management model:

Plan, Write, Revise, Edit, Publish

…as though publish was something final. In Agile documentation, that might describe the process to publish a single topic, but it doesn’t scale up. If we call this sequence write-a-topic, in the larger scale, the documentation process looks more like:

Plan, Write-a-topic, Review, Repeat

Stopping every so often to step back and look at the view (i.e. take care of more strategic planning).

What works for me

I try to organize my documentation as much like the software development process as possible, but it took some de-programming to break the waterfall method into which I’d been indoctrinated.

It works best when I can define my documentation projects as epics, sprints, stories.

An epic is a large-scale project or functionality that spans multiple sprints and consists of many stories. For example, produce the documentation for a new feature. While the developers design the feature, I’m working with them to design the documentation—keeping the Agile methodology in mind. I  won’t be able to write it all at once, so I work with the product owner and the development team to figure out what functionality will be available when (in sequence, if not by date), what topics the customer will need and in what order (they can’t read it all at once anymore than I can write it all at once).

With that information, I define the stories and prioritize them with the product owner such that if I have to stop at any point along the way (e.g. to start on the next project), I’ll know that the most valuable topics have been written and the rest can wait (or they really weren’t as valuable or important as I thought they were).

The sprint planning and reviews keep the priorities in focus, but that often means that the epics are not done linearly. One documentation epic was about 2 months of work, but took 4-5 months to complete because of intervening priorities. Fortunately, I designed the content such that it was always publishable (shippable, in Agile terms) and the overall content set just kept getting better as I wrote it. Eventually, it was finished—as was all the intervening, higher-value content.

As Hannibal of the A-Team would say, “I love it when a plan comes together.”

I continue the reflection I started in my last post, reviewing Scott Ambler’s article from 2002, Can Documentation Be Agile?

To no surprise, the customer emerged as being a critical element in Agile documentation. The points in Scott’s article refer to the Customer as though the customer is singular. Users, the user, etc. are also used similarly. In most cases, however, (i.e. with any luck) there is rarely only one customer. So, how can we understand all those people?

Find the center of mass

In physics, large bodies are modeled around a center of gravity or center of mass. This notion facilitates the study of very large objects, planet- or galaxy-sized objects in astrophysics, by modeling them as a single point with the mass of the entire object.

As with planets and galaxies, customers can also be modeled in a similar fashion. Many customers can be (and are frequently) modeled as a few personas or market segments. This is common in fields that deal with large numbers of people, such as marketing and advertising. In these cases populations are described by what they have in common and treated as a single persona. Does that mean every person in a segment’s population is the same? Of course not. But a well designed persona or segment describes the common attributes of the group sufficiently for its intended use. Just like knowing the location of an object’s center of mass will let you understand its properties and behaviors when acted upon by external forces.

One drawback to this method, is that when you miscalculate an object’s center of mass, it won’t behave as you expect it should. Its behavior will be consistent with its actual center of mass (whether you know where that is, or not). Where I’ve seen personas and segments go awry in technical writing is, inevitably, when they were not applied or not defined well.

Base personas on research

Just as an object’s center of mass is found through measurement, a population’s or segment’s properties are also determined through measurements and analysis (a.k.a. research).

If you want to treat a population as a single entity, you must measure it precisely.

But measuring customers is not easy. So what’s a writer to do?

Iterate

Successive approximation is a method for improving and refining a measurement and is an important part of Agile. Measure, test, observe, refine, repeat (or pick your favorite method for this). With this approach, you can continuously improve your customer model such that you can treat the customer as a single entity. There are several ways to accomplish successive approximation methods, but the key factor is that you assume that you must evaluate and iterate and that these aspects are baked into every process.

So, one of the first steps toward having agile documentation is having the ability to iterate (cheaply and quickly) and the ability to measure and understand your customers.

But, we all know that. Now, to figure out how to make that part of the process.

Scott Ambler started an interesting conversation about agile documentation on LinkedIn  a short while ago. I visited Scott’s site, to see what else he had to say on the subject and I came across his article from 2002, Can Documentation Be Agile?

In his article, he lists 12 points that can help documentation be agile.   Scott’s article outlines a view of writing that I have not seen in practice in the 14 years since he wrote it. In my careers as a developer and a writer, I’ve seen bits and pieces of his list in practice to see how they might work together. I’ve also seen many obstacles that keep them from becoming more widespread. So in that context, I reflected on his points to imagine what such a world might look like.

I think it starts with us, the Writers, who need to look at the job from a new perspective.

Writers are more than “the scribes”

First, writers are not just “wordsmiths.”  While we take pride in our ability to craft great content, that’s not where we add value. Our value comes from what we craft, not simply that we craft. Likewise, software developers don’t add value just because they code, they add value because of what they code.

So, how do we know what to craft?

Focus on the customer

His first point is where writing really starts and ends—the writer’s audience and customer. Writers need to know their audience first hand. They need to walk in their shoes. More importantly, they need to make (or be granted) the time and resources to do this. Every writer? Yes, I think so, at least to some degree. Why? The longer a writer goes without walking in the customer’s shoes, the more assumptions creep in and take hold. It starts off slowly, but eventually, the writer’s view of the customer gets out of sync with the real customer. Markets change. Customers change, Products change. It’s a full time job keeping them all in sync, but it’s a necessary one.

Keep it simple, but not too simple

Of course, where that fine line falls is the source of constant debate. But, why is that such a debatable topic? I refer back to the previous point. If you know your customers, you know what they want. If you don’t, you make assumptions, and so the discussion becomes one of assumptions and not data. Hence, the contention.

Another aspect of this which provides a challenge to a writer is when one topic needs a lot of content to be “simple enough,” while another requires very little. The former looks lavish and the latter seems incomplete—until you use the, of course. But I’ve seen this unevenness be the topic of contentious discussions. Why? Because, audience data to the contrary was lacking.

All the more reason for writers to get out and meet their customers.