You can now download our white paper “Towards an Agile authoring methodology”

Towards an Agile authoring methodologyYou can now download our Adobe-commissioned white paper “Towards an Agile authoring methodology” via Adobe’s website.

Agile development is a way of managing IT development teams and projects that creates new challenges for those involved in providing User Assistance for those products.

See: Towards an Agile authoring methodology

Content Strategy Lightning Talks: Applying Lean principles to content strategy

On Tuesday 26 February, Ellis Pratt from Cherryleaf will be speaking at the popular London Content Strategy lightning talk.

Ellis will explain how the principles of Lean manufacturing can be applied to developing and managing content. It’s a way of writing that focuses on maximising the value to the user and minimising waste. Since the Agile development methodology is based on Lean principles, it will help you to position content management within an Agile environment.

Each speaker gets 5 minutes and 20 slides (15 seconds per slide) to share their unique perspectives on content strategy in a blur of energy, passion and intensity.

See Content Strategy Lightning Talks, 26th February

The Lean writing evolution

There seems to be a great deal of interest in applying Lean methods to technical communication. Our free mini ebook on Lean writing has proven to be much more popular than we imagined, and we’re starting to see other people within technical communication talk about Lean. We’ve come across articles and presentations by others looking at its potential, for example: Graham Wignall’s slidedeck on Lean docs and Sissi Closs’s article on Lean Management.  There is also a new project by some members of the Institute for Scientific and Technical Communicators to come up with some best practices guidelines for including technical communications in Agile development processes (Agile is based on Lean).

Any moves towards applying Lean are likely to be evolutionary than revolutionary – small incremental steps rather than a radical immediate change in the way user assistance is created. It’s good to see some common ideas emerge based on the Lean principles of maximising value and minimising waste.

See also: Applying Lean methods to technical communication

The Lean user guide

It was suggested I read The Lean Startup, by Eric Riess. This book outlines how the principles of Lean manufacturing can be applied to startup businesses, and software businesses in particular. For startups, it’s about how to figure out the right thing to build – that people will pay for – as quickly as possible. I’m still reading it, and so far, it is very good.

It begs the question:

Where does user documentation fit in a Lean startup, and can the principles of Lean be applied to User Assistance?

Let’s start by looking at the slide deck below, which outlines the principles of The Lean Startup:

Lean is an adaptation of the Toyota Production System. Toyota’s view is that you should focus on reducing waste to expose any systemic problems. The main three types of waste are muda (“non-value-adding work”), muri (“overburden”), and mura (“unevenness”, such as waiting).

There is also a Lean software development movement, emerging from within the Agile community. According to Wikipedia, its philosophy is everything not adding value to the customer is considered to be waste (muda). This includes:

  • unnecessary code and functionality
  • delay in the software development process
  • unclear requirements
  • insufficient testing, leading to avoidable process repetition
  • bureaucracy
  • slow internal communication

Does Lean = eliminate user documentation?

So let’s address a key question: is user documentation wasteful (to be eliminated), or does user documentation add value?

Under Lean, you should only document what customers tell you is absolutely necessary. This might mean, in a Lean startup, you only document 80% of the system. That leads to a new challenge for Technical Authors – knowing which 80% to document.

Ultimately, the purpose of User Assistance is also to reduce waiting (the waste called mura), because it’s there to help you when you get stuck.

The process of writing User Assistance should contribute by helping organisations identify the difference between value and waste. Technical Authors are able to provide developers with valuable feedback on the product. User documentation can also help by filling in “gaps”, avoiding the need to waste time fixing problems.

However, paper documentation and online Help arguably leads to waiting (mura), because the user has to stop in order to go to the Help. Instead a flow-based approach might be better – offering Help and assistance at the “point-of-need”.

I asked a client who uses the Lean Startup principles to develop their software, how user documentation fits into the model. They recommended:

  • Don’t try writing a paper/PDF manual, as it will go out of date too quickly
  • Don’t tie yourself to documenting before release in the traditional way, or you’ll become a roadblock. If you’re releasing quickly and regularly, missing something out of one version isn’t going to be the end of the world.

The need for validated learning

A key principle of the Lean Startup is “validated learning”, knowing where to learn and adapt quickly from your mistakes. It is, according to Riess:

a rigorous method for demonstrating progress that a team has discovered valuable truths.

Validated learning is lacking in technical communication, and the Lean Startup’s principles are another argument for measuring the outputs and value of what we create. This means using analytics, carrying out usability testing, and conducting A/B testing of the User Assistance itself. A/B testing of user guides is possible if your content is on the Web (and you’re using one of the authoring tools that supports A/B testing). Riess strongly recommends A/B testing as a useful method for learning . A/B testing can be used to improve the Help topics and information design. It can also be used to determine which content to prioritise – you could post blank pages for incomplete pages and see how many click throughs you get.

What do you think?

What do you think? Is a Lean Startup approach a good or bad thing for Technical Authors? Does the Lean perspective assist in positioning the role of User Assistance within an Agile environment?

(Thanks to Mark Eaton of Amnis for introducing me to the concept of Lean a few years ago.)