Ellis Pratt – “Towards an Agile Authoring Methodology: Learning from the Lean Methodology”

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:

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.

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:

Waste Equivalent in technical publications


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.


Editing/multiple drafts.

Too much work.

Not enough time.


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:


How it can affect the user

Non-value adding

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


Content is too difficult or detailed


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


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.

Maxwell Hoffmann

I am the Adobe Global Product Evangelist for Tech Comm Suite. I am passionate about powerful, single-source publishing that can deliver content anytime, anywhere, any way.

5 thoughts to “Towards an Agile Authoring Methodology: Learning from the Lean Methodology”

  1. The ISO has actually published ISO/IEC/IEEE 26515–Systems and software engineering — Developing user documentation in an agile environment, available at http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=43074.


    ISO/IEC 26515:2011 specifies the way in which user documentation can be developed in agile development projects. It is intended for use in all organizations that are using agile development, or are considering implementing their projects using these techniques. It applies to people or organizations producing suites of documentation, to those undertaking a single documentation project, and to documentation produced internally, as well as to documentation contracted to outside service organizations. ISO/IEC 26515:2011 addresses the relationship between the user documentation process and the life cycle documentation process in agile development. It describes how the information developer or project manager may plan and manage the user documentation development in an agile environment.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.