I remember that idyllic summer day when I saw my very agile dog Maggie jumping through the sprinkler. I laughed until I cried. And then I thought:  This reminds me of what I do for a living.

Jumping into the Agile fray: a technical writer's perspective

I’m a technical writer and technical writing in an Agile environment is somewhat like chasing those water drops.

You can run after those features, but early in the game there’s not really anything to hold onto.

So, how does one document a feature that will probably change from one iteration (or day) to another without chasing one’s tail?

Workflow can be your rock in that ever-changing environment. While the feature is likely far from finalized, someone’s gotta have an idea of how people are going to interact with it.

The developers can get you started, but the workflow people (at least in my experience) are the product managers.

So, while my agile dog chases water drops, this technical writer chases product managers—and if I still don’t have enough of a big picture outline for the feature or a collection of features, then the Chief Technical Officer is in my sights.

For major features “in flux”, the best way to get “good enough” content to meet your iterative deadlines is to channel the Australian shepherd within and herd the developer, product managers and testers into a room with a whiteboard and a marker.

In half an hour, you’ll get something workable. And maybe a chance to put your two-cents’ worth into the design.

What if there’s no workflow available?

If it’s a sunny day, go find a sprinkler to jump through. These days, that’s a chilly prospect indeed.

Going beyond "getting started"

“Now what?” is that uncharted territory between “Getting Started” product guides and the challenge of incorporating a new tool into day-to-day activities.

In fact, I’m convinced that “Now what?” is one of many creatures inferred by the “Here be monsters” legend inscribed on uncharted regions of old nautical maps.

I think of it like this: You buy an exciting adventure package to Costa Rica. You put your money down. The tour operator hands you a map. And then you end up…in Holland.

Time to call your emergency number:

You: “Can you help me out? I was supposed to go to Costa Rica and I followed the directions, but I’m in Holland.

Customer support: “Let’s go over what happened and take a look at the directions.”

Customer support reviews your actions and examines the map. (They are incredibly patient, discerning and resilient people, these customer support types.)

Customer support: “It appears that you took a wrong turn at Albuquerque (except it’s pronounced Albekoiky).”

Then you’re put on the right road. A problem report gets logged against the map-makers to clear up whatever ambiguity there was. Now you and future travelers can end up at the intended destination.

Excellent.

“Okay. I’m in Costa Rica. Now what?”

Exactly.

This is an issue sales engineers frequently encounter in the field. It is also something that Geoff Babb touched on in his response to Helen’s post, “Exposing our soft underbellies“,  about moving documentation to a wiki.

Useful examples are great, but finding the right scenario can be difficult, particularly when customers can range from a couple of guys in their basements to companies with thousands of developers.

With a large documentation set, it’s difficult to keep up with new features and include scenarios that are relevant to everyone—a major rewriting effort indeed.

During a meeting where we presented our documentation plan for moving to a wiki, “Now what?” showed up again.

I don’t remember putting “Now what?” on the list of invitees. But it appears that there’s no stopping that beast.

Our move to a wiki means rewriting a helluva lot of material anyway. Might as well take on the beast.