---
title: "A Glimpse into the World of Agile Technical Writing, a.k.a. Extreme Technical Writing (XTW)"
date: 2008-02-19
description: "$( document ).ready(function() { // Handler for .ready() called. $("
canonical_url: https://idratherbewriting.com/2008/02/19/a-glimpse-into-the-world-of-agile-technical-writing-aka-extreme-technical-writing-xtw/
---
# A Glimpse into the World of Agile Technical Writing, a.k.a. Extreme Technical Writing (XTW)
Sarah Maddox gives us a interesting glimpse into the life of an agile technical writer, or more descript, *extreme technical writing*, *XTW.* If you work in an agile environment, definitely check out these two posts:

- [The Agile Technical Writer (I)](http://ffeathers.wordpress.com/2008/01/20/the-agile-technical-writer/)

- [The Agile Technical Writer II](http://ffeathers.wordpress.com/2008/01/26/the-agile-technical-writer-ii/)

(Although [ffeathers](http://ffeathers.wordpress.com/) is already in my feedreader, I missed these posts in the firehose of information and didn't discover them until I read Anne Gentle's latest post, [How to be an Agile Technical Writer with a cool acronym like XTW](http://justwriteclick.com/2008/02/19/how-to-be-an-agile-technical-writer-with-a-cool-acronym-like-xtw/).)

Here are a few excerpts from Maddox that hit home with me:

> Things change, and we need to change with them. If we spend too much time setting requirements in stone, they're out of date by the time we write the software. And then there's no hope that the documentation will be up to date.

Totally agree with this one. I went from a traditional all-requirements-up-front environment to an agile environment, and the difference in software quality is pretty astounding. I'm convinced that people don't know what they want until you deliver them an actual product.

> The documentation, like the software, is not written once and then left to decay quietly. Instead, writing the perfect document is an iterative process:

- Write the page, get it reviewed, and publish it as quickly as possible. There are people out there who need it now!

- If you find a programming quirk while documenting the software, let the developer know.

- When the developer changes the code, make sure the documentation is updated too.

- Respond to comments from customers, developers, support staff and anyone else. Update the document immediately.

- Monitor changes made by other people.