How can a Technical Author find more time to write user documentation in an Agile environment?

We’ve been working on a white paper that looks at how User Assistance can be more effective and developed more effectively when you’re working in an Agile environment. The white paper should be published in the next few weeks, but here’s a sneak peek at one of the issues we discuss: the lack of time available for creating User Assistance.

Agile’s iterative release of products, and sometimes frequent changes to the functionality and the User Interface, can make it difficult to create the user documentation. The Technical Author can end up having to rework content they’ve written, delete sections on functionality that’s no longer part of the product, and add information on features that have been introduced towards the end of the project. If the Technical Author waits until the product has been completed, they can find they have very little time available for writing the user documentation.

So what can you do about this?

One of the key ways you can “even out” the technical writing workload is simply to start the project earlier. Although you might need to go back and amend some of the content written at the start of the project, you may find you can save time by avoiding the peaks and troughs of work (and errors) that you might otherwise experience. Often, it’s more efficient to have a steady, continuous, flow of work than doing batches of work, stopping and starting. There’s certainly lots of evidence from manufacturing to support the idea of a continuous flow of work.

Another approach is to adjust the manning levels to match the requirements. For example, using an external technical writing partner, such as Cherryleaf, means you can bring extra people into the project when you’re overloaded with work. Alternatively, you could get your project teams members – developers, for example – to help put with some of the writing if there’s a point when there’s simply too much work for you to manage.

There’s other approaches to working in an Agile environment, which we cover in the white paper, but we’d be interested in the approaches others have taken when addressing this issue.

(Flickr Creative Commons image: VFS Digital Design)