Practical Agile Tips for Technical Writers

Being part of the Agile process gives technical writers a lot of visibility compared to the older days. In the waterfall days the engineer didn’t know who the technical writer was and vice versa. When the technical writer began planning their document, they were pretty clueless on where to start for multiple reasons.

• The design documents and wireframe were outdated and the final product was quite different.
• The user story and what the user was trying to accomplish was unclear and lost in translation.
• There was no accurate working prototype to go from.
• There was no environment where the whole feature worked correctly. You never knew what was the correct behavior between the variations in various environments.

The result was a document that was far from the reality of the final product’s behavior. It also reduced the ability to keep the document up-to-date continuously.

Being part of the product team’s discussions makes the technical writer not only be visible, but also have a say in the early design stages. It enables the technical writer to collaborate with the various roles and gather their perspective to drive prioritization.

However, the ratio of technical writers to engineers can make it unsustainable to actually be present in person and participate actively in all the product scrum meetings.

Here’s are some tips I gathered from my own experience.

• Review design docs early: Review the feature scope and design documents early in the release. This would help you be done with 2 tasks, learning about the feature and scope, and reviewing the language for Release Notes in one step.
• Minimize meetings: At a minimum, attend the sprint planning/design reviews and retrospectives. Spend time understanding the user stories and acceptance criteria to help you scope your sprint work.
• Catch up offline on missed meetings: Review the design offline and provide feedback early, ask questions and clarifications.
• Communicate your updates: Provide your stand up updates to the team using email, Slack channels, or scrum boards when you can’t attend meetings. It’s important your team knows why you can’t make it and also have the status of your work.
• Attend sprint demos: Sprint demos help you see a working version of the feature and flow. If you can’t attend them, ask the team to record the demos and watch them offline.
• Share quick drafts: Sharing an early, but quick draft of your document live in a meeting can help your team focus a few mins on the updates needed and give you immediate feedback and direction for the formal document you will create later. This way you get early input and avoid the risk of unreviewed documentation making it through the door in a rush.
• Communicate meeting conflicts: Inform your scrum team about conflicting meetings from other scrum teams. Choose one meeting to attend and catch up offline on the others.
• Communicate conflicting deadlines and ask for prioritization: While providing your standup up updates, ensure you let your scrum teams know the multiple teams you’re on and your conflicting deadlines. Ask them to help you prioritize the most important task so they won’t be blocked by your deliverable, while being made aware of the other deliverables impacting your schedule.
• Provide feedback in the retrospective: List challenges you faced in the sprint. Ensure you also appreciate something the team did right to reinforce the positive aspects. I have seen too often documentation-related challenges missing from retrospective updates. Speak up! Don’t be shy because the scrum team is your team too and they also have challenges just like you!