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.
Are you thinking something like ISO/IEC 26515:2011 ? “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. It is intended neither to encourage nor to discourage the use of any particular agile development tools or methods.”
http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=43074
I just bought The Scrum Field Guide from the Google Play Store (£1). It has a good chapter about documenting in an Agile environment.
I must admit I’d forgotten about that ISO standard. I saw a presentation on this at TCUK, but it seems to have disappeared from view since then. Is a standard the way to go?
Hi, Ellis. I like this list a lot. However, I’d like to know more about what you mean by “iterative updates to the content.” While topic-based authoring and incremental publishing are indispensible for UA on an agile project, I find that it’s best to lock down the topics once they’ve been published.
There are two reasons for this: (1) Writers don’t have bandwidth to go back and make iterative updates, and (2) It’s too costly to publish, translate, update, and re-translate. While translation is spread out across the entire development cycle (rather than concentrated at the end), it’s important to ensure that each topic is translated only once.
Hallo Ellis
Nice post! A crucial point about agile methodology is that the agile team continuously examines and evolves its own processes. Technical writing teams should have this as part of our methodology too. We should keep an eye out for changes in the development team’s processes, and be ready to adjust ours at the drop of a hat.
Having an agile team is just like having a baby: Just when you think you’ve got everything going smoothly, the baby grows a minute older and changes the game plan. 🙂
Cheers, Sarah
Hi Larry
Tony Self talks about the manual that is in permanent beta, so that is one idea. I mean there may be a release for early adopters, which is then expanded for other users as the product gains more users. I also mean there should be a process where the difficulties in updating a manual are removed or minimised. Locking down topics is compatible with the the staged release concept.
If writers did have the bandwidth and the costs were reduced, should they do it? Part of the process is to remove bottlenecks and costs where possible, especially where it adds great value to the user. I agree overwork – doing things more than once – is probably an unnecessary waste.
Another thought – this is more an idea for a manifesto than a standard. I mean manifesto in the sense of how Agile began, the futurist manifesto of the early 1900s etc.
The key to agile is flexibility. The key to agile technical authoring is also flexibility. But you can’t be an island of flexibility of you are surrounded by rigid procedures. That’s why you can’t just “do agile development”, you have to “be an agile organisation”. Then agile technical authoring will fit right in. In an ideal world of course. (What do you mean, you don’t work in an ideal world?)
In that ideal world you’ll probably be writing small topics for some structured content system as well. I love ideal worlds.
Hello Ellis,,
I agree with your summary of what changes in agile authoring. I believe a Just-in-Time approach to authoring is most useful. Iterative update, though costly, could be necessary in certain situations as stories associated to one feature often span across sprints and writers would have to track back. Allowing the design to evolve until the end should also help, as discussed here: http://www.tcworld.info/tcworld/technical-communication/article/adjusting-to-scrum/
It will be really great if technical authors get to stop or define the development for a sprint . I guess authors documenting cloud-based applications with stories that go live at the end of each sprint have a better chance.