I'd Rather Be Writing Podcast

I'd Rather Be Writing Podcast


How can technical writers thrive in agile environments? Event recording and details

September 20, 2016

Audio Recording Listen to the recording: You can download the MP3 file, subscribe in iTunes, or listen with Stitcher. Agile panel event description Here’s a description of the agile panel event: How can technical writers can thrive in agile environments? Most engineers in IT departments follow an agile scrum process: they track issues in sprints, assign and scope story points, meet daily to provide short updates on their work, and release updates every 2-3 weeks. Technical writers who work with engineers usually find that being productive requires them to become familiar with the engineer’s agile scrum workflow. Whether you want to keep abreast of engineering work, factor in time for doc reviews during the sprint, or have documentation be managed like other IT work, you need to know how to integrate or work with the agile scrum workflow. In this chapter meeting, we will have a panel discussion about how technical writers can thrive in agile environments. (See the STC SV event post for more details.) Tip: If you're new to agile and scrum, check out Jeff Sutherland’s book Scrum. Panelists The following 5 people were panelists: Bonnie Clark has almost 20 years of experience in the technical communication field. She is currently a Director of Technical Publications at FICO, a leading analytics software company. Rosemary Picado is the Documentation Team Lead at Sumo Logic, and works with agile and non-agile teams within the company to document their cloud-based log management platform. Formerly at Recommind, she transitioned from Tech Writer to Scrum Master while the platform was being re-architected, learning the value of Agile first hand, and how the skill sets intersect and complement each other. Daniel Doornbos has been a technical communicator since 1982. He most recently worked as a Senior Technical Writer at HEAT Software on its IT Service Management product. The company is in the process of transitioning to agile development. Jane Wilson leads the technical writing team for GE Digital’s Applications Engineering group. GE Digital develops in an Agile environment, and, as the team has grown, she has developed processes for fitting writers and the writing process into Agile methodologies. Along the way, she became a certified scrum master. Jane belongs to the East Bay and Atlanta chapters, and she currently serves on the STC Board as Treasurer. Gina Blednyh is a Staff Technical Writer at Salesforce. She’s worked in an Agile environment for almost six years. She’s also been a scrum master for both a writing team and an engineering team and is an Agile convert. I moderated the panel. Questions discussed Here are some of the questions about agile and tech comm that we discussed: Should documentation be managed as items in an engineering sprint? Should doc reviews be assigned story points? Do you still create a documentation plan at the project kickoff if you are following an agile scrum process? How can you keep pace in documenting features during the sprint if the features don’t get finished until the end of the sprint? How can you reduce the tedium of daily standups when engineers seem to rattle on endlessly about coding issues? How can you stay updated about JIRA items when engineers don’t take the time to articulate the issue but rather hastily add a quick title that only they and other engineers who are already familiar with the issue understand? How can you persuade engineers to dedicate time for doc reviews if there’s no points allocated for the work in the sprint? Logging bugs changes the role tech writers play on teams. Should tech writers log bugs when they find them, or simply send emails to the QA engineers to log the bugs? What processes should tech writers follow in order to publish rapidly during the two-week cycles, especially when tech writers have several projects at once, all of which have two-week release cadences? How can technical writers be valuable participants in the agile process wh