Technical Writing in an Agile World

By Sudheer Brahmarouthu

With the constantly evolving dynamics of the IT space in the last few years, organizations have come to rely more on the agile engineering practices to steer them ahead in the application and product development, and pace them to the demands of the market.

Organizations have taken the initial steps toward aligning the engineering shift with process automation and technology landscaping. The peripheral function of technical or business writing is, therefore, required to take a departure from the traditional way of waiting till the end of the line for a finished product and must adapt efficiently and effectively early on to the engineering sprints to gather a better understanding of the product. While the agile process enables faster delivery, the leaner release model does not allow the technical writers a firm set of requirements to work with. The changing, iterative, and dynamic sprint model further poses a significant challenge in terms of gathering knowledge of the product and making them dependent on the sprint teams and people rather than the documented requirements.

Alignment with Scrum Teams

Technical writers are, therefore, required to be part of the scrum teams and closely aligned with the meetings and deliverables contained within each sprint; hence, ensuring that the key features delivered in the sprint are documented. This association at a sprint level helps technical writers not only document the product knowledge and information in an incremental fashion but also gather and incorporate the feedback early. Daily standups are the crux of the scrum process and with the product owners and development team making most of their functionality decisions within these meetings. The technical writing team must be there to document these decisions. These decisions at the scrum level are essentially new requirements in the agile world. In addition, most of the customer documentation would need to be presented in the standup and sprint review/demo meetings and incorporated accordingly into the product knowledge documentation.

Right Time to Align

As an integral part of the development process, technical writers need to be involved upfront in the process right at the design phase to enable themselves clearly documenting the functionality. A potential opportunity for learning and staying abreast of the technology developments, it necessitates that technical writers are well versed with the product functionality from a user perspective. A technical writer who has in-depth knowledge of the product along with needed technical and domain skills will certainly excel in the current agile world. Getting involved early in the process makes technical writers become one of the first users to experience and provide feedback on the new functionality. This not only helps the team with documentation but also with any feedback related to that functionality.

The sprint review meeting generally takes place at the end of every sprint. It provides all stakeholders including the customer service, product management, and development teams with the opportunity to see what has been delivered during the sprint and what will most likely be delivered to the customer in the immediate future and down the roadmap. These review meetings provide opportunities for the technical writing teams to not only document what has changed through the demos, but to also process and incorporate the stakeholder feedback early in the process, contributing to the creation of a more exhaustive and comprehensive product knowledge documentation.

A trend on the rise in the last few years in the space of technical documentation that takes the agile process into consideration is the advent of context-sensitive help that provides small chunks of information that is related to the immediate needs of the user. This type of help content is usually interwoven within the user-interface code of the application and available on-demand or within a help tour. Again, because context-sensitive help is part of the development process, it is crucial for the technical writer to be part of the development process.

Aspects and Benefits

While technical or business writing is often considered being limited to product feature help documentation, it essentially encompasses a larger spectrum of documentation pertaining to products. The benefits of these different aspects of documentation are multifold, including generating awareness regarding the company, product, service or the benefit it offers for the company’s potential audience; helping establish trust with customers through clear, exhaustive product information that allows customers derive the best out of the product investment.

Pulling Prospects

An oft overlooked marketing asset, product technical documentation forms the basis for the organization to help connect with prospects and customers throughout the buying cycle. Hubspot estimates that 60 percent of businesses employ content marketing—the creation, publishing, and sharing of content to acquire and retain customers—as part of their overall marketing strategy. Effective content marketers know that they need to develop different types of content at each stage of the customer journey, supplying the right information at the right time to help customers make proper choices. As a proactive measure, technical writers need to keep a tab on the product backlog to update themselves on product functionality and technical changes. This enables them to collaborate with the product management and understand the product roadmap. Cross-functions like marketing, pre-sales etc., usually reach out to product management for product solution briefs and other knowledge documents, an area where technical writers can cross-collaborate and help push the deal.

Cutting Down Support Cost

A significant part of the customer issues fall into the information requests category and most of them can be addressed with clear product documentation, saving technical support desk costs for the organization and the team. Organizations are now focusing on investing in the right tools and processes in place to gather, consolidate, and process constant feedback from customers and support teams so that technical writers can switch into the mold of continuous improvement process. Technical documentation teams are focusing on innovation in technical writing, coming up in the market to constantly upgrade themselves and provide better means of delivering documentation to customers.

With agile methodology applied, organizations expect to lower their expenses by producing cost-effective documentation. With the incremental way of delivering help files, the whole help rarely required to be fully rearranged. With documentation produced in an agile way, feedback is sought early from users, right after each iteration, on improvements/updates to the documentation. An early feedback provides a rapid, collaborative approach to the creation of help files through
intranets or wiki, and helps consolidate feedback in an effective and efficient manner, involving a larger group of users and stakeholders.

As with any engineering model, collaboration within the development team and the peripheral functions is paramount. The responsibility to engage and elicit feedback in every part of the development life-cycle, various stakeholder groups and functions falls significantly, now more than ever, on the technical documentation team. The rise of the disruptive engineering models requires technical writers to fit in, as much as the development teams and asks of them one key aspect to survive the shifting dynamics – adapt.

About the Author

Sudheer Brahmarouthu

Currently working as a Software Engineering
Manager in CA Technologies, Sudheer carries over 17 years of experience in leading software engineering teams with diverse skillsets and is consistently rated high by the teams. He has been delivering valued innovation to customers through projects involving multiple technologies and platforms related to client-server, web, research, service delivery, infrastructure upgrades, and migration. Sudheer has a strong hold on agile practices and is a certified scrum product owner and a SAFe Agilist. Sudheer strongly believes in people being the key to the success of any organization and is passionate about new research and automation.