5 Pitfalls for Docs in Agile (And How to Avoid Them)

5 Pitfalls for Docs in Agile (And How to Avoid Them)

Agile teams are becoming more and more common in software development, and it makes sense: the methodology lets you get your customer's feedback fast and iterate quickly on that feedback. But as teams embrace these principles, one important deliverable is often overlooked: documentation. Some Agile practitioners don't consider the technical writer part of the Agile team at all, but this approach is short-sighted. The software needs to ship with docs, and it's frankly unprofessional to do otherwise. You could hold off releasing the product until you can hire a writer to appropriately document it (delaying your release by weeks or months) or allow the writer to join the team, develop their work as part of it, and release alongside the product.

Documentation isn't impossible in an Agile environment; indeed, it’s a lot easier! Avoid these 5 common pitfalls to get the most out of the writer on your Agile team.

4 Ways a Tech Writer Makes Your Development Team Stronger

4 Ways a Tech Writer Makes Your Development Team Stronger

Your team is strong – you guys eat software development for breakfast. You get things done for the client, and the client loves you. Hell, your software is so good, it doesn't even need documentation! Right? Despite your confidence, I'd argue you need a writer anyway (or at least a point person on documentation). That said, I think some of your belief that you don't need a writer stems from your misunderstanding of what a tech writer does and how they function within the team. Here are four ways a technical writer can make a strong team even stronger.

How and Why to UAT the Docs

How and Why to UAT the Docs

I'm passionate about getting high-quality feedback on my documentation. This is my profession, after all – I don't want to turn in shoddy work and I don't want customers to suffer with sub-par help. I'm happy to get whatever feedback I can; I'll even take spelling and grammar feedback and eat it like the delicious cookie it is. But as I've worked more and more on software development projects, I've set my sight on a new type of documentation feedback: user acceptance testing (UAT).

I don't think I've ever heard of a software team that performs docs UAT. But the more I think about it, the more it seems absurd. After all, we do software UAT to ensure customers have a chance to tell us whether our code meets their needs, has any bugs we missed, and how it can be further improved. This would also be valuable information for the documentation! And yet I've never heard of a place that does this. But why? Or better yet: why not?