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!

I love reviews of my work. (Yes, I'm a glutton for punishment). When it gets close to time for documentation reviews, it's like my Work Christmas: I get nervicited (nervous + excited) as I start to dream of all the comments I'll get back. Will people like the design? I wonder how many typos they'll catch... I hope they notice how careful I was to make the wording consistent! I really hope they catch a couple of errors, so I'll know everything else is definitely right....

Then the dread sneaks in: what if no one responds? When I don't have good feedback (or, almost worse, I get the single phrase "looks good"), it's hard to know if my work provided any value at all. I'm a perfectionist about my work, but I'm not delusional: there's definitely something wrong in there. Not even NASA gets it perfectly right the first time. But after weeks or months of staring at the docs, my eyes glide right over the problems. I know mistakes are there, and I need the team to help me find them.

For code, we have exhaustive testing of every function, every release. But in the sprint to catch the next person in the Agile relay (or to dive headlong across the tape in Waterfall), documentation reviews often fall to the wayside. But failing to test the docs is just as short-sighed as failing to test the code. The docs are our customers' companion as they traverse the world of the release. Good UX is a godsend, and flawless programming is great, but if you find yourself stuck on a desert island with a well-designed and thoughtfully constructed raft, you'll still want the instructions to know you're putting it together properly.

That we need buy-in for doc reviews is obvious. But how can we get it? Well...

Ever do a ton of work only to realize that you and your boss weren't on the same page? It's possibly the worst feeling you can have at work: that you put time and effort into something that isn't even what the boss wanted, or thought they'd asked for. Technical writing is fraught with opportunities for these little miscommunications that lead to wasted effort, wasted time, and drained motivation.
 

Part of the solution is setting your documentation scope clearly and early. But defining scope is't the whole answer. You understand what you need to do to write the docs, but do your team members understand what they need to do to support your work? Ask these 7 questions at the beginning of the project to get everyone on the same page.