Agile documentation development: process as goal

The process

It’s not just for code talkers (CC-SA)

There is no foolproof process map for the act of writing and directing communications that make a technical subject clear to users. The people formerly known as technical writers are now more like writer-directors of a movie—what’s called on the marketing side “creative.” They must be at home with all forms of digital communications, though they need not be expert at producing each type. The essential attributes of the new technical writer-director are creativity and adaptability.

Yes, most writer-directors will follow some sort of process outline that describes general objectives. One like this:

  1. Assess the current knowledge and skills of the user or the process participant (audience definition)
  2. Understand the application, product or process
  3. Define the objective of the communication: to facilitate product use or process completion at X success rate, which also should nail down baselines for what constitutes task completion and the time to completion (i.e., get from to Z in Y time) 
  4. Define the content, expectations for a user-baselines and the development process for the communication, including
    • the team members whose input will be necessary: creative, SME’s and management
    • a map of the knowledge base that will need to be communicated before the user or process participant can be expected to take on the actual use of the product or undertake the process
    • the workflow that most users or process participants will execute
    • the project schedule—broken down by stages of development and their deadlines
  5. Build in continuous iterations that adapt to both the development process of the application or process and the changing expectations of the users or people performing the process. This is the sine qua non of agile document development.

In most cases, resources will compete with goals. That is, most organizations will not allocate the people and time necessary for meeting all defined objectives. Something has to give. More often than not, it’s time and people—the first being compressed and the second stretched. But managment need to understand that documentation is not an add-on but instead integral to business goals.

Is adaptive

Given the imperative to maximize output per expenditure, most technology companies have found that an “agile” rather than a “waterfall” development process works best in the current information-intensive environment.

The requirement > design/development > implementation > integration model leaves a company with a product or process that is outdated at completion. Instead, organizations have adopted an “agile” model undergirded by the premise that product or process development must adapt to the light-speed evolution of both technology and market (see image above) . Flavors of this model—Scrum and Dynamic Systems Development, for instance—emphasize the creation of teams that engineer products and processes in successive iterations. The job is never finished but is always in process—like life, which is why agile companies think in terms of product life cycle.

The document development process must follow suit. This demands that the document development team, including SME’s and management, meet regularly to adapt the process to the now. This certainly beats having an opaque product or process plopped down on or into your desktop and the boss saying, “Now document it. We release in a week.”

But with content-management issues

In an agile environment, content management systems can stymie documentation development. Writer-directors—and their masters—must understand that their job is more like keeping a journal than writing a book. Mixing and matching existing “content blocks” is no way to run an adaptive agile documentation process. The goal is not to establish a set of approved content, which (as human beings) writers crave. The goal is a dynamic process that keeps pace with evolving products, processes and markets.

If your writer-directors are always dogging you to approve copy so they can dump it in a CMS, they are a drag on your push to produce products and processes that work now and tomorrow. All of the delightful surprises and value of your new stuff must be portrayed for what they are—tools that bring new and astonishing solutions to what was an unsolved or ineffectively addressed problem.




Tagged with: , , , , , ,
Posted in Technical Documentation

Leave a Reply

Your email address will not be published. Required fields are marked *


* Copy This Password *

* Type Or Paste Password Here *

%d bloggers like this: