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.
In Part one, we looked at Agile and the Lean method’s principles of maximising value and minimising waste. Here in Part two, we look at how we can minimise waste in the document production process.
Removing waste from user’s interaction with the product
Let’s briefly touch on value and waste during the use of the product by the user.
User Assistance can contribute to the user being less “wasteful” when they’re using the product: minimising the time having to stop when they get stuck, or having to rework things to fix mistakes. This means you need to provide the right information at the right time, in the right place, and in the right format.
It needs to provide the required information to the reader as fast as possible. In practice, this can mean having the Help embedded in the application itself. It might also mean creating different documents to suit different audiences, or even personalised content. It also implies User Assistance needs to be as short as possible, but not shorter.
This also means you’ll need to carry out some usability testing of the content and perhaps even A/B testing. You have to test to check what you’re producing is what gives value to users.
Removing waste from user documentation process
Let’s look at how we could apply Lean principles to writing technical documentation in an Agile environment.
Is it needed?
The Lean approach can help us identify which parts to document, and which to leave out. Under Lean, you should only document what customers tell you is absolutely necessary. Only information that adds value to the user, or increases their productivity, should be included. If the information isn’t needed by anyone, we shouldn’t write it (unless we have to do it for legal or other reasons).
By going through a design process of empathy, defining needs, generating ideas, prototyping and testing, we can identify the best way to solve a specific problem. In practice, User Assistance (in other words, the online Help and user documentation) should be considered part of the product design, and included in the initial design planning, rather than being left to the end. This requires a change in product planning thinking, as documentation is often treated as an afterthought, pushed to the end of the development process.
In an Agile development process, designers will create Use Cases for each feature, and technical communicators can do something similar. Use Cases can be used in the planning of User Assistance to identify who will use it (the audience), what value it will provide (or what problem it will solve), and when they will use it.
In addition to the waste of “non-value adding work”, in our simplified description of Lean there are also wastes of “overburden” and “unevenness”. These relate to having too much work to do in the timescales allowed, and having to stop and wait for something you need in order to carry on working. Instead, our goal is to have a consistent, productive rhythm to our work.
For technical communicators, this “overburden” and “unevenness” could be waiting for reviews, waiting for edits, waiting for work, or waiting for approvals. It can also mean wasting time having to switch tools or stop and start different tasks. If we can measure these wastes, we can justify the need to change working practices.
Levelling allows a consistent workflow, which makes it possible to set standards and identify abnormalities. The Lean methodology contains a number of techniques for smoothing out a work schedule, such as a triage approach to prioritising new work requests. One of the key ways we can level the technical writing workload is simply to start the project earlier. The benefits from avoiding having to stop and start, or rush things at the end, may outweigh any waste from having to go back and amend some of the content written at the start of the project.
Related to load levelling is continuous, or one-piece, flow. W. Edwards Deming proved in the 1950s that implementing a continuous flow system, instead of working in batches, can have a significant impact on improving quality and reducing throughput time.
A continuous flow system works like serving people food from a counter. Customers move forward, picking up their stater, main course and pudding as they go down the line. When a serving station runs out of food, there should be a new tray of supplies ready to replenish it just in time to serve the next customer. People only work on one piece at a time and only one piece of work moves from one stage to the next.
Deming proved one-piece flow results in fewer bottlenecks, less waiting and faster throughput. You pull work from the previous step when you have available resources. It also means that mistakes appear earlier. As items are pulled one piece at a time, you should have one only faulty item to deal with, rather than a large batch of defects. If you fix the problem, identifying what caused it, it goes away before it can escalate.
One example of technical communicators working in batches is when they send out drafts of whole manuals to reviewers. One piece flow could mean passing on content for review in smaller pieces – perhaps even issuing content for review on a daily basis, making it an integral part of the product development process.
One of the tools used in both Lean and Agile projects is a Kanban board. This is a visual representation of the pieces flowing through the process. It can help the team identify any problems, and control and regulate the amount of new tasks given to the team. It can be the case that no new work is added to the board until a current work piece is defined as “done”.
One approach is to include the technical writing task in the project Kanban board. This could mean if there are problems with creating documentation, these are brought to the surface for fixing there and then.
Alerting and fixing any problems early
The philosophy of both Lean and Agile is to bring problems and defects to the front, and force people to confront them and fix the immediate and underlying problems.
Within Lean, and often in Agile, when a problem or issue is identified, everyone is empowered to stop the process, and swarm around the problem to solve it immediately. So could a technical communicator have the right to flag to stop the process? Would a development team be willing to face up to the sheer amount of documentation and work with the technical communicator to tackle the problem? The answer should be yes, but it would depend on how closely the team adheres to Agile principles. For this to happen, the team needs to have an authoring system that enables non-professional technical communicators (such as developers) to be able to contribute content.
Dealing with variations in project plans
Technical communicators need to avoid having to pull the emergency cord, and this means they need to be able to deal with some of the variations that can arise as projects change over time.
In Part three
In Part three of this series, we’ll look at how we can modify our writing process and tools so we can implement these approaches into how we work.