With more and more software development teams switching from traditional waterfall to agile methods of development, technical communicators need to be flexible about their processes to work cleanly and efficiently. Sometimes, though, it feels like we are fitting a square peg into a round hole. It doesn’t have to be that way! This presentation will address ways to smooth off that square peg and adapt traditional documentation processes and procedures to make them fit in an agile world.

About Our Speaker

Jane Wilson is a Senior Member of STC and belongs to the East Bay and Atlanta Chapters. As STC Treasurer, Jane chairs the Finance and Investment Committee, which is responsible for the annual budget, financial reserves, and financial processes of the Society. She currently works as Information Development Director at GE Digital in San Ramon, CA, where she leads the team providing documentation for GE’s Brilliant Manufacturing and Automation products.

Meeting Logistics

Date: Thursday, 2 February, 2017.

Meeting Recap

by Joe Humbert

In the February 2 dinner meeting, Jane Wilson presented, “Creating User Documentation in an Agile World.” She spoke as a communicator working in Agile methodology. Agile was created by 17 guys at a ski lodge in 2001 as an alternative to the traditional method of document development known as waterfall. Waterfall follows linear steps from Customer Needs to Software Design to Implementation to Verification to Maintenance, in which each step is handed off from one group of developers to the next.

Agile takes a different tack, using teams that perform work iteratively, by breaking down a project into short, easy to accomplish tasks. An Agile team consists of a Product Owner (who represents the customer’s needs), team members (who, in theory, can each accomplish any task), and a Scrum Master, (who manages the Team cycles and keeps development on track).

Agile teams work in short sessions, called sprints, usually two weeks, sometimes more, sometimes less. The team meets in daily stand up meetings where each team member reports on progress made and any blockers to progress. All the steps covered in the waterfall model are followed in each sprint, and at the end of the sprint, the team should have a shippable product. By having these short sprints, the team can discover developmental errors and correct for the next sprint. .

Through the Agile process of re-iteration, the time for a product to be actually shippable should be reduced, and development should progress efficiently. In traditional methods, an error may only be discovered at the end of the product development, and require going back to a previous step to correct it and repeat time consuming steps that have already been done.

In the original development of Agile methodology, no consideration was given to information development. As a result, technical communicators have had to develop their own ways of fitting in to Agile teams. This can vary greatly from company to company, and even from team to team. Unfortunately, because writers often cover multiple teams, they can end up as an “outsider” to the team. Some tips for improving this dynamic include making sure that technical writers participate in all Agile ceremonies — scrum stand-up meetings, planning, and retrospectives. Teams have to be mindful of the tech writer’s time and schedule so that the writer may fully participate in each scrum team. Writers also should take an active role in recording their work similarly to the rest of the team (in stories, on scrum boards, etc.). Finally, writers should strive to be active participants on their teams – learn about Agile, and speak up to improve the process.