Agile programming has grown in popularity and it has led to new challenges for those involved in providing user assistance for those applications. So is it time for technical authors to develop an equivalent method for developing content for these projects? Is it time to develop an “Agile authoring” methodology? Also, if we want to move away from a hand-crafted approach to developing content and towards a more engineering-like approach, what can we learn from the latest techniques being applied in manufacturing?
Such a method needs to complement Agile programming, but it may be a mistake to take Agile programming as the starting point for developing it. The developers of Agile drew upon the principles of Lean manufacturing, and perhaps technical authors should do the same.
In this webinar, we 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 maximizing the value to the user and minimizing waste. It involves measuring the processes and value of what has been delivered so that iterative improvements can be made over time.
This webinar will be hosted by the Society for Technical Communication.
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.
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.
Agile programming has grown in popularity, and it has lead to new challenges for those involved in providing User Assistance for those applications.
So is it time for Technical Authors to develop an equivalent method for developing content for these projects? Is it time to develop an “Agile authoring” methodology?
Such a method needs to complement Agile programming, but it may be a mistake to take Agile programming as the starting point for developing it. The developers of Agile drew upon the principles of Lean manufacturing, and perhaps Technical Authors should do the same.
What would we be likely to see in such a method? Here are some suggestions:
One piece flow. Information is moved through the process in the smallest batches possible. For example, translators and reviewers receive content topic by topic (or chapter by chapter).
Minimalist manuals. Only the information that adds value to the user, or increases their productivity, is included.
Incremental publishing of content (and frequent builds of drafts).
Documentation sprints through collaborative authoring.
Rigorous testing and measurement of the value of the documentation.
“Stop the line”. Authors have the right to stop the development of software if they spot a critical mistake or if they are overburdened with work.
Separation of “look and feel” from content, to enable adaptation to change.
Iterative updates to the content.
Close daily cooperation and communication with the development team.
Removal of “waste”, such as waiting for new information or overload of work.
Buy-in and commitment from all the stakeholders of the value and need for the User Assistance.
What would you envisage an Agile authoring methodology to contain?
Addendum: A further point for the list:
Creating information that reduces “waste” at the user’s end. In Japanese, there are the concepts of go no sen (reacting), sen no sen (a simultaneous response) and sensen no sen (preempting). Writers could aim for sen no sen or ultimately sensen no sen -providing information that preempts problems.
The “5 Whys” is a question-and-answer technique used to discover the root cause of a defect or problem. It is an approach used in the Lean manufacturing methodology, as well as the Six Sigma business management strategy. Here’s an example of the 5 Whys technique:
Problem: The vehicle will not start.
Why? – The battery is dead. (first why)
Why? – The alternator is not functioning. (second why)
Why? – The alternator belt has broken. (third why)
Why? – The alternator belt was well beyond its useful service life and not replaced. (fourth why)
Why? – The vehicle was not maintained according to the recommended service schedule. (fifth why, the root cause)
Solution: Start maintaining the vehicle according to the recommended service schedule.
Some consultants suggest that if you use the 5 Whys approach you’ll conclude you should fix a fault in a product rather than create reams of documentation explaining how to get around the problem. However, if the cause is of the problem is at the customer’s side (for example, their computer has an out-of-date driver), how do you fix the problem? You could control the issue by only selling to those who have the appropriate setup (or training), but, if you want to get the customer to resolve an issue at their end, then the user documentation may be the best way to do it.
Sometimes, the 5 Whys approach will identify the need for a proportionate intermediate fix. Again, User documentation is often the most effective solution, in those situations.
The Content Development team at Cherryleaf has created a a free eBook that provides help and advice on applying Lean principles to User Assistance. This short ebook explains how the principles of Lean manufacturing can be applied to developing software User Assistance and other forms of technical documentation. Lean is the parent/cousin of Agile Development, Extreme Programming and Six Sigma.
The eBook is free; it’s available as a PDF, and in EPUB and Kindle (MOBI) formats.