Two years ago, we wrote a number of posts, and an Adobe-sponsored whitepaper, on Agile and its effects on technical communication. This topic was picked by others, including Sarah O’Keefe and Mattias Sander, who made further suggestions. We thought it was time to revisit this topic, and expand on some of the issues raised.

This is part one of a series of posts on this topic. 

Being Agile in technical documentation – Part one

Agile creates a number of challenges for technical communicators, which can mean they need to adapt their working methods in order to work efficiently.

What is Agile?

Agile development is a way of managing IT development teams and projects that has been around since 2001. It’s an alternative to traditional project methods, which, it was felt, often lead to unsuccessful projects.

One of the main criticisms of traditional project management methods was they often led to teams working to a plan that became less relevant to user needs, current technology, and market trends over the lifetime of a project. This could result in software that were already out of date by the time it was released. The approach was also criticised because some faults might not be identified until towards the end of the project, which could make fixing them time-consuming and expensive.

In 2001, a group of developers published the Agile Manifesto, which outlined their vision of how they felt software projects should be run.

In Agile projects, the goal is to develop robust products quickly. The project and its deliverables are typically broken down into short development cycles, which are usually two weeks, and, based on the feedback and lessons learnt from these cycles, the project adapts and changes over time. The team delivers early, frequent and continuous releases of products.

One goal is for teams to find problems quickly, and either correct a problem immediately or eliminate the affected feature altogether. This should mean there is less waste, something we’ll look at in more detail later.

Agile’s effect on writing

In traditional project environments, technical communicators often use functional specification documents, which describe what will be delivered, and any available prototypes, as their information source. At the start of the project, they have detailed information on what the product is meant to do.

The Agile manifesto proposes working software over comprehensive specification documentation, which often means there is far less written information for technical communicators to use. They often have to produce content based on word-of-mouth descriptions, fluid sketches, use cases, and business cases.

Managing Agile projects relies far more on face-to-face communication and self-directing teams than any formal documentation mapping out the whole project for years in advance.

The release of products in short, iterative, cycles can mean there is little time to write the user documentation before the product is released. Also, if the product is changing with every release, there may be a need to rework the content that’s already been written.

An Agile approach to technical writing

Technical communicators who work in an Agile environment often need to adapt the way they work to meet these new challenges. In other words, they need an Agile approach to technical writing.

Agile is based on a manufacturing method called Lean, and we suggest this Agile approach to technical writing should be based on Lean principles as well.

Learning from Lean

The Lean methodology is a method for making things. Originally developed for manufacturing, today it is used in healthcare, programming and other business areas. Lean is an adaptation of the Toyota Production System, a set of principles and methods developed in Japan in the 1950s for creating high quality, reliable cars at a reasonable price.

In a nutshell, Lean’s approach is to:

Maximise the value to the customer

and

minimise waste.

Lean is a never ending process. You constantly seek out waste, strive for perfection, look for maximising the value. Agile shares this philosophy of continuously striving for perfection, looking to maximise the value to the customer and avoid time wasted on activities that don’t add value.

About value

In Lean, you start by understanding what the customer values in the product. Once you’re able to define value, you can then pinpoint where and how value is added during the development process.

You focus your efforts on ensuring that resources are targeted to deliver that value as effectively and efficiently as possible.

If a feature or a step in the development process doesn’t add value, it is seen as a “waste”. In Lean, you challenge whether those “wastes” in the development process are needed or if they should be eliminated.

The result is an emphasis on providing the value customers are willing to pay for, whilst simultaneously identifying where you can reduce costs.

About waste

Waste is categorised into eight types in Lean. However, we can simplify things by looking at the three original wastes that were defined in the Toyota Production System.

The three types of waste are: “non-value adding work”, “overburden” and “unevenness”. Non-value adding work can mean the waste of time and effort on activities or features that don’t give the user any value. Overburden can mean someone having more work to do than they can handle, which often leads to mistakes, defects and poor quality. Unevenness can mean the times when you have to stop or slow down, while you wait for someone else to give you a item needed in order to do the work. Instead, our goal is to have a consistent, productive rhythm to our work.

Why look at Lean instead of Agile?

Agile has developed processes and methods for reducing wastes for developers. However, these processes and methods can result in waste appearing at other points in the overall process, such when we create the end-user documentation.

For example, we might find that leaving documenting to a late stage in the development process in order to avoid the wastes caused by creating content that’s not needed or requires reworking is a false economy. This approach could be more wasteful than starting the project earlier. Using Lean can help us identify how to eliminate or minimise those wastes.

We can look at value and waste from two aspects – during production and during the use of the product by the user. This we’ll begin to do in Part two of this series.