Columns

Providing Value in an Agile Environment as a Technical Writer

By Cindy Currie | STC Fellow and Kit Brown-Hoekstra | STC Fellow

Ask a Tech Comm Manager is an advice column geared toward answering all those questions you have, but might be uncomfortable asking. We glean the questions from social media, forums, and most importantly, from you, dear reader. If we don’t know an answer, we will interview experts and get information for you. Send us your questions to kitbh.stc@gmail.com or tweet them to @kitcomgenesis or the hashtag #askTCmgr.

How do I provide value in an Agile environment?

With more and more companies using Agile methods for their software development, many technical writers are asking how they fit in to the team and program structures. Here’s how it worked in one global IT company. The technical writer supported a cloud-based offering by writing the online help (for end-users) and the internal release notes (for delivery teams). The development teams worked two-week sprints in a 12-week program increment. Deployment to production occurred the last day of each sprint.

The technical writer worked alongside the architect and product owner to produce the online help, keeping pace with the sprint plans and documenting only what was produced in each sprint. Thus, she was providing an updated copy of the online help every two weeks. She updated the internal release notes, as well, but they were not deployed to production, as they were intended as a follow-up reference document to a training session on the offering delivery teams at the end of each program increment, right before release to market.

The technical writer was not considered to be on a “team,” because she was located in China and working at the team level wasn’t workable and really didn’t make sense given what each team was focused on. It was the sum total of each team’s output, once integrated, that created the vertical slice of value (in this case, a feature) that was her focus.

To do her work, the technical writer had access to the internal lab environment, the staging environment and a demo environment. As she developed expertise with the offering, she was called upon by the product manager to run customer demos, thereby showcasing her knowledge of the system, as well as the system itself. Customers were impressed by her ability to answer questions that the product manager had trouble answering. Several sales were progressed and/or closed. She increased her value to the entire program in this way.

In other cases, technical communicators are embedded into multiple scrum teams and produce content on a sprint+1 schedule. When localization is involved, the localized content is produced on a sprint+2 schedule. This structure works if you have structured content and a robust content management system, because these two things allow you to track chunks of content through the workflow and process them through localization in batches. Be sure to include your localization vendor in your planning and workflow, so that they know what to expect.

Our advice: Get in there and see where you fit in the overall team or program structure of your environment. Develop expertise with the product (as we technical communicators typically do), find a way to showcase it, and garner the admiration and respect of those around you due to the value that you add (what they perceive as value) to the program. Know your worth.