I’ve been a technical writer for almost six years, and I’ve spent most of that time as the only technical writer in sight. For being the only one, I think I’ve done a pretty good job: I’ve set up docs development cycles, sprinted with Agile development teams, released alongside software deployments, created the documentation architecture for three major products, and generally got a lot of docs out in a short time.

All that said, my docs effort hasn’t been flawless. I’ve typically operated like a developer with no QA – reviewing my docs myself, but with little or no outside testing. Without a comprehensive QA step, errors have crept in and compounded. Recently, when I finally regression tested my own docs, I found an error on nearly every page. The most egregious errors provided information that was outdated or wrong.

I had expected to find errors, but I was shocked by the number and frequency. As I fixed them, I realized that docs regression isn’t something that’s commonly added to documentation effort estimates, but it’s a vital step.

What do we mean by "working documentation"? It's difficult to apply a parallel to software. After all, working software is software that works: it functions and doesn't have bugs. Does that mean "working documentation" doesn’t have any "bugs" like grammatical or description errors?

That doesn't feel right. Nor should it. After all, it's hard to say documentation is "working" if it's simply error-free. For documentation, the definition of "working" is "serving the needs of the user." To serve the user, the docs need to be accessible – technologically, physically, and verbally. This goes for every member of the audience at which it’s directed.

I've been thinking about documentation in Agile for a long time, but only recently have I thought about what Agile documentation development itself might look like. Organizations have adopted Agile for its ability to empower teams to create high-quality products faster. From that angle, I wondered whether a documentation team might see some gains by adopting "docs Agile."

To clarify, I'm not talking about including technical writers on Agile teams (although I’ve written about it in the past). Instead, I'm doing a thought experiment to see what the Agile Manifesto would look like if, instead of being applied to development teams, it applied to documentation teams. I’ve tried to keep the docs team incorporated with development and testing during my thought experiment. Overall, I think these ideas are instructive in terms of what writing teams can do within an Agile framework.

Hello from the other side of Write the Docs North America 2017! Despite a nasty cold that cropped up after the conference, I'm buzzing with new ideas and strategies I learned from the conference.

I plan to write about what I learned in more depth later, but for now I just want to share my notes. I've created a Google Doc with all my notes--please check it out! I wasn't able to capture notes for every talk, but if you have notes you'd like to contribute, please feel free to share them within the doc.

Write the Docs North America is coming in less than a month! I'm stoked to hang out with my fellow tech writers, documentarians, and others who care about the docs.

Those of you coming from out of town will probably want to take the opportunity to explore Portland, but might not have a lot of time. Luckily, downtown Portland is very walkable. And although downtown doesn't get a lot of attention on travel sites, there are still plenty of cool things to check out near the Write the Docs venue, the Crystal Ballroom. 

If you want to skip the rental car and explore Portland in the few hours or days available to you before or after the conference, here's a list of over 15 cool things you can see or do within 15 blocks of the Crystal Ballroom. Feel free to check them out on my custom Google Map as well!