Sharing responsibilities in agile technical writing

Saturday, 20 February 2010 05:18

Guest Blogs - Techwriter News

Recently we shuffled responsibilities in our technical writing team. Andrew Lui and I now share responsibility for a number of products and documentation sets, instead of each person “owning” separate products.  I’m totally enjoying it, for a number of reasons. One of them is that Andrew is awesome! Another is that sharing responsibilities works really well in an agile environment, especially when it comes to crunch time.

One challenge a technical writer faces in an agile environment is that the development team splits into a number of sub-teams, each working on a different feature or bundle of features. The sub-teams work in parallel. As a result, all the features simultaneously reach the stage where we can start documenting them, and that’s usually quite close to release date. This can cause major stress for the technical writer and can require overtime work to get everything done in time.

If you’re lucky enough to have two or more technical writers around, it works well to share the responsibilities. This is not as obvious or easy as it sounds, but it’s well worth the effort.

Why isn’t it obvious or easy? There are a couple of reasons. Our instinct is to have each technical writer know a product and its documentation intimately. That’s especially true for technically complex products or documentation environments. It’s time consuming and demanding for each technical writer to know many products that well. Also, it’s seldom that a technical writer is assigned only one product. We usually “own” many. So if we have to share products, that increases the number of products for each technical writer and complicates our set of responsibilities even more.

Our particular case

Until a few weeks ago, I was responsible for a mixed bag of documentation sets:

• Integration (the bits that hold our products together and allow them to talk to each other).
• Crowd (a single sign-on and user management product).
• Gadgets.
• The “Dragons Lair” documents.
• Various development frameworks such as the plugin framework and REST APIs (developer-focused documentation)
• The three Atlassian IDE connectors (IDEA, Eclipse and Visual Studio)

Now Confluence wiki is on my list too, but Andrew is sharing the responsibilities for Confluence and the other bits. Confluence is one of our two biggest products, so it gets a big slice of the technical writing pie. I spend 50% of my time on the Confluence documentation and 50% on other stuff. Andrew also spends 50% of his time on Confluence and 50% on other stuff.

Sarah:

• Confluence.
• Crowd (a single sign-on and user management product).
• Gadgets.
• Various development frameworks such as the plugin framework and REST APIs (developer-focused documentation).

Andrew:

• Confluence.
• Integration (the bits that hold our products together and allow them to talk to each other).
• The “Dragons Lair” documents.
• The three Atlassian IDE connectors (IDEA, Eclipse and Visual Studio).

Why is it good?

Andrew and I both make sure we allocate the required percentage of time to each product, based on company and team priorities. But, and here’s the bit that works really well, each of us has the flexibility to shuffle the time allocations over an extended period.

For example: 50% of my time is allocated to the Confluence documentation, but that doesn’t mean I have to spend 50% of each and every day on Confluence. Nor even of each and every week.

As the agile schedule for a particular product approaches release date, both technical writers can spend 100% of their time on the features that are now ready to document. In effect, for that period of time, you have two writers on a single product instead of just the allocated one technical writer. Yaayyy, less stress and more achievable deadlines.

There’s even a reduced chance of having to cancel your leave if the product’s release date slips.

As every technical writer knows, it’s awesome to have someone else to bounce ideas off. And to commiserate with when deadlines seem impossible.

Why include a photo of a waterfall in a post about agile methodology? Heh. Anyway, this is a 16-foot high waterfall that appeared in our garden on the night of the record-breaking Sydney downpour last week. The entire family traipsed out at 11pm to have a look. By the time we took the photo, the force of the water had abated slightly. It was beautiful but a bit scary, especially as it was right next to the house. Quite a bit of the garden ended up at the bottom of the hill. Luckily the house didn’t!

Read more: ffeathers -- a technical writer's blog