Agile development relies heavily on frequent and clear communication. Consequently, it might seem like communication will not be an issue for us—after all, we are professional communicators. The fact is, essential communication on an agile team often is thwarted by preconceived ideas of what a technical writer does or can contribute to the team. And those preconceptions are held by both the technical writer and the other agile team members. While you may not be able to change others’ closely held notions, you have the ability to demolish your own preconceptions and open a path. Here are four communication must-do’s for any technical writer aspiring to be a key member of the agile team.
Speak Up
photo credit: Sean Dreilinger
Sounds almost too simple, doesn’t it? But many technical writers hesitate to speak up at critical moments, and lose opportunities that may not come again. You must be heard to get the access you need, so it is imperative that you speak up in meetings and in one-on-one interactions related to every aspect of the product development. Ask lots of questions, and use your increasing knowledge to contribute to design discussions. Speak up for the users of the product. User advocacy has long been a role that technical communicators cherish, and that means speaking up to uncover issues and recommend solutions. For example, if a GUI is difficult to use, suggest and run a usability test to show the developers firsthand the struggles that users will face with the current design. Or if you find out planning meetings are happening without your presence, talk with the meetings’ hosts or facilitators and get on the participant list.
Speak up, and in detail, at scrum meetings; they represent your chance to communicate with Development and Quality Engineering (QE) on a scheduled, regular basis. Remember that when you attend scrums, you must give—and get—detailed, specific information during these meetings. Be direct, not hesitant, if the information others provide doesn’t fully meet your needs. Follow up to solicit greater detail.
For example, if you announce, “I’m creating the help for Feature X,” you haven’t clued the rest of the team in. Do you need help or additional information to create the help? Have you uncovered issues or bugs that prevent completion of your task? Is it time for another team member to take action? A better meeting update could go something like this: “I am almost done creating the help structure for the wizard that Feature X uses. Developer Sally, I’ll need to get with you to show you what I did in the mapping file so we can hook up the help to the wizard page code. I’m also adding these topics to the .chm file’s table of contents.”
Get Involved in All Areas of Development
No matter how many times you’ve heard it, or said it, “I’m just the writer” does not excuse you from proactive involvement—you can’t be a key team member without full immersion. Alan Pringle talks more about this in a recent Scriptorium blog post. This level of involvement ensures you are tuned in from the beginning and know the requirements, design, and thought behind the design of the software. And this gains you an additional benefit: “street cred,” the respect you need to stay involved.
You can gain that street cred by taking a few critical actions:
- Show an interest in the requirements, design, and thought behind the design of the product.
- Attend any and all release and iteration planning meetings. If you aren’t being invited, invite yourself.
- Offer to help improve text in the GUI. If possible, hold the Info Dev team responsible for all text that appears in the product. Often it just takes some informational text or a better field name for the GUI to be much less confusing to a user.
- Be a usability advocate. Something may be completely clear to the developer, but that doesn’t guarantee it’s the best way to present it to the user. For example, a developer might code a window that asks the user if they want an automatic notification when a report has completed, and the choices are “True/False.” As the usability advocate, recommend the simpler and clearer “Yes/No.”
- Avoid information bottlenecks. Rather than funneling information through one person, have the writer working on the feature interact directly with the developer and/or QE person working on the feature.
Photo credit: SandiaLabs
Take Ownership of Technical Accuracy
All writers working as agile team members must be responsible for the technical accuracy of the documentation they write. To take ownership of the technical accuracy of your documentation, keep in mind that you’re leading the effort. Don’t settle for writing what the developers tell you to write or assume something works a certain way. Challenge and validate assumptions by asking questions, and testing builds.
To test builds, writers should have their own sets of virtual machines. Owning your installations of products provides greater flexibility and efficiency: floating writers can quickly and easily access the product and get up to speed without waiting on QE to install a build.
Remember, you must understand the product to know if it has technical or usability problems. And product knowledge builds trust among other team members.
Serve on a “Core” Team
A core team consists of a lead from each functional area (Product Management, Development, QE, Info Dev, and Technical Support). The core team drives the project and serves as a system of checks and balances to ensure there is equal representation from each area. The core team makes the decisions for the project together. It also helps each functional area get a “birds’ eye” view of how all the product components and support systems work together.
Conclusion
Applying some of the suggestions mentioned here will help you gain equal footing on your team, and demonstrate the many ways you can contribute. If you work on multiple projects, establishing a presence like this helps the team on one project remember what you need while you’re busy on the other project. Finally, your active presence as an agile team member increases your knowledge of the technical details, the team members, and the processes the team uses, making the whole team stronger to deliver a higher-quality product.
