Towards an Agile Authoring Methodology: Learning from the Lean Methodology

Agile development is a way of managing IT development teams and projects that was introduced around 2001. It is a set of principles that aims to result in more successful projects by breaking a project down into a series of incremental and iterative stages. As Agile has become increasingly popular, technical communicators have needed to learn how they can work effectively within these projects.

Noted thought leader, Ellis Pratt of Cherryleaf in the UK has authored a white paper you can download, entitled “Towards an Agile authoring methodology: learning from the Lean methodology.” AdobeTCS also held a webinar with Ellis on this topic, with the same title. You can view the webinar recording by clicking here. This blog covers highlights of points made in both the Pratt white paper and webinar.

The emergence of Agile

Agile development was introduced around 2001 as a means of managing IT development teams and projects. It is actually a set of principles with a goal of achieving project success by breaking projects down into a series of incremental and iterative stages. Obviously, this relatively recent method of managing projects has impacted technical communicators.

To quote the author:

Features of Agile

Pratt reminds us that traditionally, tech comm communicators have worked on projects where delivery specifications have been defined and documented at project start. The diagram below shows a typical, traditional project:

01 stages of tradi project

Agile projects are quite a contrast: the goal is to quickly develop robust projects and minimize an investment in upfront design. Project and deliverables are typically broken down into two-week development cycles. These projects adapt and change over time, based on feedback and lessons learned from these cycles. Key stages in an Agile project are show below:

02 key stages in agile project

Agile’s effect on writing

Technical communicators are challenged by working with a methodology that does not directly address how user documentation can be created in an efficient and effective way. The following list directly quotes the author on some challenges that technical communicators can face:

The iterative release of products can lead to changing documentation requirements and the need to modify or delete documentation that has been completed. If the technical communicator were to wait until the product was close to final and complete release, they could find they had less time than before to write the documentation.
The elimination or minimization of the written specifications for the product by the development team can mean that the technical communicator has little or no written information on how the product should work.
The lack of specification, prototype or stated business requirement also means it can be very hard for the technical communicator to provide accurate estimates for their documentation tasks.
Technical communicators often have to produce documentation based on word-of-mouth descriptions or evolving sketches, prototypes and business cases. This means, when the product has been finally completed, the documentation may not be completely accurate and might need to be revised on certain places.

Learning from Lean

Lean is a methodology for making things. Although it was originally developed for manufacturing, today the Lean methodology is used in programming, heathcare and other business areas. Lean is an adaption of the Toyota Production System which defines three types of waste as (a) “non-value adding work”, “overburden” and “uneveness”.

Lean has defined waste as eight common categories, which correspond to common documentation issues, as shown in the author’s diagram below:

Waiting

Waiting for information from Subject Matter Experts or test versions of the product.Delays in approving and publishing content.Lost time due to late receipt of source material.

Over processing

Repeated content.Creating content that’s not needed.Duplication of collecting source material.Collecting of non-essential source material.Too frequent reporting of performance than necessary.Not meeting customer’s requirements.

Defects rework and correcting

Changes arising from uncaught errors.Having to make post-publishing amendments to the output generated from an authoring tool.

Moving things

Finding information.Hand-offs for reviewing and translating.Reviewing data more often than necessary.

Overproduction

Editing/multiple drafts.Too much work.Not enough time.

Inventory

List of requirements and topics.New plans are produced while stakeholders are still processing previous plans.

Talent misused

Underutilization of people.

Motion (by people)

Moving from one authoring application to another.Meeting Subject Matter Experts.Attending development meetings.Meeting with inadequate attendees.Checking with new business units/product groups for their initial plans.

Removing waste from documentation

Lean’s focus on stripping waste is that if something does not add value to the customer, it is eliminated. Using the three original types of waste described above, Lean can help us identify areas of waste in documentation from the user’s perspective:

Non-value adding

Content that’s not needed or doesn’t meet their needs

Overburden

Content is too difficult or detailed

Unevenness

There are delays in finding information

Writing in an Agile environment

In this section of the white paper, Pratt identifies areas where you can apply Lean principles to tech doc in an Agile environment, and illustrates how Adobe Tech Comm Suite 4 and RoboHelp Server 9 can assist you in doing this.

You will need to read the white paper and view the recorded webinar to fully appreciate these principles, but the following list provides a summary of areas covered in Pratt’s white paper and presentation:

Synchronize to customer demands
An iterative publication of content
Understanding variations in customer demand
Understanding variations in project plans
Load leveling
Continuous (one piece) flow
Standardized processes and work
Alerting and fixing problems early
Minimize the need for rework
Making the “value stream” visible

Summary

Here, we again quote the author directly, in italics:

In this document, we have suggested some ideas and approaches towards an Agile authoring methodology for you to consider. Reframing technical documentation in the context of the Lean methodology, could help technical communicators demonstrate its value, and identify all the areas where time and effort is wasted, to teams using Agile methodologies.

Technical communicators need to be able to respond to the requirements of users and to any changes to the project. In addition to having efficient working practices, this also means you need authoring tools that are sufficiently flexible and capable.

Adobe Technical Communication Suite 4 provides:

Efficient technical communication workflows that span: print, PDF, and online delivery on multiple devices, in 17 output formats.
Support for standards-based and structured authoring workflows.
Linked document source files across applications to automatically propagate changes.
Workgroup efficiency by sharing publishing configuration settings among multiple authors.
A streamlined review and approval process, with the ability to import PDF comments into FrameMaker or RoboHelp.
The power of Adobe AIR for enhanced information delivery and customer feedback.

About the Author

Ellis is Director and Help Strategist at Cherryleaf Technical Authors, a technical writing services and training company based near London, in the United Kingdom. He has over fifteen years’ experience working in the field of documentation, has a BA in Business Studies, and is an Associate of the Institution of Engineering and Technology. Ellis is also an author and editor of two books: ‘How to Write Instructions’ and ‘Trends in Technical Communication’. Ranked the most the influential blogger on technical communication in Europe, Ellis is a specialist in the field of creating clear and simple information users will love.