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.