The agile technical writer

One of the four basic principles of the Agile Manifesto is to value ‘Working software over comprehensive documentation‘. Oooo-er! Documentation devalued — that cuts technical writers out of the loop. Or does it?

Hallo, I don’t think so 🙂 The technical writer’s role has become even more interesting, exciting and above all, valuable — that’s what I find, anyway, now that I’m working in an agile development shop. And we’re extremely agile. We have seven core software products plus two hosted platforms, making nine products in total. Each product has a release cycle ranging from a couple of weeks to three months, give or take an iteration. That keeps us all on the hop.

The main thing is that you have to be, well, agile. This blog post is all about the Agile Technical Writer, even the Extreme Tech Writer — let’s call her the XTW.

Here is the preamble from the Manifesto for Agile Software Development:

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

I’ve found that the aim of having less comprehensive documentation applies primarily to the beginning of the traditional SDLC (Systems Development Life Cycle). In an agile development team, there tends to be a less comprehensive process around the feasibility study, business requirements investigation and functional specifications. That’s typically the domain of a business analyst rather than a tech writer, though the roles are very similar and often intertwine in very interesting ways.

A technical writer’s strengths really start to shine at a later stage, after the developers have had a first stab at writing the code. For the XTW (agile/extreme tech writer, for those who’ve just tuned in) this means that our role is even more interleaved with the business analyst and quality assurance roles. But it’s a matter of emphasis rather than a change.

The emphasis is on responding to our readers’ needs and producing high-quality products.

It’s just good fun as well as good sense.

A day in the life of an agile technical writer

• Get in early and hook up to my feeds — see what’s happened to the documentation wikis while I’m asleep and the other side of the world is at play.
• Trickle around the standups (short meetings held standing up), first with a development team or two and then with the tech writing team.
• Play with the products and write the documentation.
• Click on a flashing IM (instant message) from a developer who wants some advice on the text for an application screen.
• Attend a super-short presentation by the development team of a new feature that needs documenting for the next software release.
• Weather an IM blizzard from a support engineer half-way across the world, who has a customer with some interesting (synonym for irate) feedback on the documentation.
• Try out a new feature and report behavioural quirks to the developer. The tech writers are often the first ‘real’ people to try the new feature. (Everyone knows that developers reside primarily in virtual rather than meat space.)
• LOL in response to an IM from a fellow tech writer, who has spotted one of those things that only tech writers find funny.
• Take a look at comments rolling in from customers on my space watch. People often put very useful comments on the documentation pages, which we can incorporate into the page. Other comments, usually by some dude called ‘Anonymous’, are not so constructive and may even need radical elimination.
• Have a quick chat with a developer in meat space, to find out what bits of new functionality I might have missed.
• Respond to a software emergency: Add a note to the wiki about a just-discovered bug in the latest release, give the stressed developer a chocolate and start the release notes for the patch.
• Add myself as a ‘watcher’ of a just-reported bug that will require a documentation update when the issue is resolved.
• Go and play with the WII in the lunch room.

‘Today I bought a bikini’, or ‘What about procedures?’

Myself, I’ve never been keen on procedures. If you’re going to do XTW, it’s more rewarding to go all the way. It’s a bit like buying a bikini (as I’ve just done today): the skimpier the better, otherwise it just doesn’t work and what’s the point anyway.

We’re a team of four writers. We have a wiki, where we put our guidelines and other interesting titbits. Did you know that Americans spell the last word in my previous sentence as ‘tidbits’? After writing the word, I realised that it might have an unfortunate association with the topic of the previous paragraph and picture, and I even contemplated changing the spelling. Is that why the Americans did? 😳

Rather than stating ‘This is how things are done,’ our guidelines are more along the lines of:

This is what’s working for us right now.

Or:

Hey, this is awesome, you might want to use it too.

A while ago 😉 a dude named Ovid said that everything changes and the only constant thing is change itself. He wrote a book about it, called The Metamorphoses. In his world, the situation was a bit out of hand. People changed into trees if they stood in one place for too long, gods transformed themselves into swans to fool a passing virgin, and the meringue of civilisation constantly threatened to crumble into wisps of sugar-coated nothingness.

Things haven’t changed much since then. (Paradox alert!)

I’d say that’s the main reason why the Agile Manifesto works. 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.

As a team of XTWs, we talk about the team and our interactions with the rest of the company. We adapt as quickly as our environment does.

And we keep the documentation moving too. 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.

Past, present and future

Here’s my take on life, the universe and technical writing:

• Ovid is 2000 years old but still rocks.
• Long meetings and unwieldy email discussions are outdated.
• Standups, RSS feeds and wiki watches are working right now — but they’ve been around a while already.
• Tomorrow is an unknown, but it’s gotta be different.
• Documentation will survive 🙂

Saving the best bit for last

I really like this bit of the Agile Manifesto:

Simplicity–the art of maximizing the amount of work not done–is essential

It’s a paradox. (Another one, and what would we do without them.) As a technical writer, my aim is to reduce other people’s work, by making the documentation as simple and useful as possible. It takes a lot of work to achieve that simplicity. But it’s awesome because it’s what I love doing.

I guess that’s what’s behind the Agile Manifesto too.

Our team has picked up some great techniques over the last few months. This blog post is getting very long, so I’ll save them for my next post. Happy extreme tech writing!

Update: I’ve added some hints about techniques our team has learned in another post: The agile technical writer II

Update August 2009: Atlassian has just published a new section of its web site, called “agile@Atlassian”. There’s a section on how the technical writers do agile. There are videos too, including one of me (spooky). Go tech-writers@agile@Atlassian.