My favourite principle in the Agile Manifesto is that you get good people, put them in a good environment and then trust them to do a good job.
A “good environment” — that’s where chocolate comes into it.
At the office we have cupboards full of the stuff. Undeterred by such abundance, the Technical Writing team also goes on regular “doc hot choc” outings. We usually go to our local Lindt Café. Sometimes we even allow one or two hangers on, like a developer who has written a Confluence plugin just for us.
“We have come to value chocolate over extensive verbal compliments.” 😉
In my previous post, I promised a braindump of the things our team has learned over the last months as technical writers in an agile environment. So here goes.
First of all, the agile turtle has had a makeover:
Thanks to Ryan, who was totally mortified at my previous clipart mix-and-mashup.
So, what are the tips and techniques? They’re not rocket science, and they’re not so very different from what tech writers do every day even in non-agile environments. The main thing is an eagerness and enjoyment of going with the flow.
Stay on the hop and she’ll be right, mate.
Off on a tangent: I tried some chocolate beer last night. It was ~interesting. But that’s not the kind of hop I’m talking about here.
OK, let’s go:
- Attend the development team standups (short meetings held standing up). This way, you get advance notice of new features, patch releases and changing deadlines.
- Let the development teams know what you’re working on. Your work will dovetail with theirs quite neatly. I often find that I’m tackling a problem area in the documents (e.g. LDAP integration) at the same time as the developers are completing enhancement requests and the support team are weathering a storm of problems around the same topic.
- Keep your contributions short at the standups. It’s a bit of a balancing act: some developers think you’re wasting their time. That’s not unique to the agile environment though. Not everyone is in on the secret that documentation is actually at the centre of the universe 😉
- Make sure that the documentation is seen as part of the product, and that your development timeline is factored into the product release. Again, this is tricky — I’ve worked in places where this is seen as merely a nice-to-have.
- Get with the eat your own dogfood thing. It really works. If at all possible, make the products you’re documenting part of your daily life. That might be difficult if you’re doing the techdocs for NASA or MI6 or something. But hey, a flaming rocket or a poison pen might just come in handy at the next standup 😉
- Think like an engineer. When documenting a new feature, evaluate the end-user’s experience while writing the ‘how to’ stuff. Does it actually work for them? Remember that your feedback is valuable. Often, you are the first end-user-type to use the software, and you (or your documents) frequently have more of a big-picture and procedure-oriented view than the developer who wrote the code.
- Apply the principle of iterative development to the documentation as well as to the software. Contribute to the QA and testing process, and be ready to adapt the documents to reflect any resulting code changes.
- Subscribe to blogs, wiki watches and anything else that’s going. Some people may tell you that you’ll die of IO (information overload). But that’s not so. You’ll quickly learn how to scan the stuff coming in and pick up on the relevant bits. It’s the only way to stay ahead of the agile environment.
- Seek even more input! Attend impromptu and scheduled training sessions. Attend the planning session which usually happens at the first iteration in each major release cycle. Keep your eyes, ears and antennae tuned for any other sources of information.
- Respond to requests from customers. They may come at you via email, phone, comments on your documentation pages, etc. If the comment is about the documents, that’s your job. If not, pass it on to the support team.
- Monitor the bug-reports and enhancement requests coming in for the product. Take note of any that will affect the documentation.
And here are two brand new techniques which our team has just begun trying out:
- Swaparoo: In our team, each tech writer looks after three products. To get some cross-product knowledge going, we’ve started swapping tasks. One of us might announce in our daily standup that she is available for a swaparoo. The others will look for a suitable task that’s currently assigned to them. It might be a new feature for the next release or a meaty maintenance issue. And then the two writers will work together to get the job done. This is very like the ‘pairing’ that agile developers do. We just like the word ‘swaparoo’ better.
- Code reviews: Get yourself included in the code reviews for major updates. Our company uses Crucible, a tool which allows engineers to embed their code reviews into the code and share the review comments with any number of people. The developer can assign a group of people to take part in the review. The tech writer can pick up some useful tips here too, just by watching the review comments whizz by.
And then, find some time to do a bit of writing.
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.
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.