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.

I’ve said it before: the docs need to be on the team’s Definition of Done (DoD). But in practical terms, what does this mean? Where do they fit? How does the team decide?

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.

So you've been reading my blog and have taken to heart my message that you need docs. Aww! Thank you! I'm flattered. But now, brass tacks, how do you do it? How does this person fit in your team? How do you make them feel welcome?

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?