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. In Part two, we looked at how we can minimise waste in the document production process. Here in Part three, we look at practical impact on writing. Agile creates a number of challenges for technical communicators, and this means they need to adapt their working methods in order to work efficiently.
From the previous posts, we can get a understanding of the underlying principles of Agile and Lean. These include establishing a rhythm of working continously on activities that add value. Don’t stop and start; don’t batch; keep measuring and checking. The challenge for technical communicators is how to fit into this pattern of work.
Measuring the value and the wastes
Lean and Agile place great emphasis on measuring the value of the work created and the production process itself. Measuring, and identifying “the value stream”, highlights the steps in the process that do not add any value: waste by overburden and waiting, waste caused by rework, waste caused by excessive checking, and so on.
Agile makes the assumption that the waste of creating content describing features or processes that are dropped before release is so great that teams should take a “document late” approach. If you measure your time, this can be tested to see if it’s true. It might be that more time is wasted by trying to work with little available time, or having to wait for input. Many development teams are surprised by how much time and money is wasted once they’ve been made aware of it.
Measuring the value to the user is much harder for technical communicators to measure. For example, you can’t tell how often someone uses a PDF manual. Often, they don’t do any measurement at all. This is a mistake. Usability testing, even if it is on a limited scale, and using people dragged off the street or from the staff canteen, can provide very useful information on what’s not adding value.
Working with sprints and kanban
It’s not always possible for technical communicators to complete their work in a two week window, so some work “a sprint behind”, starting work once a product iteration has finished. Other teams run consolidation sprints, where a sprint just focuses on outstanding tasks such as user documentation.
It partly depends on the team’s definition of “done”. Lean and Agile bring issues to the surface and should force teams to address them. If documentation is part of the definition of what needs to be done (and it should be), the team needs to ensure the documentation work is completed.
Whatever approach is taken, it’s important the task of creating user documentation is on the kanban board, so that sufficient attention and resource is given to the task.
One piece flow can also relate to topic-based authoring. Many Technical Authors already create their content in small pieces, topics, that can be used across different documents and media. Conditional build tags enable them to create filtered content, and content created with a particular audience in mind.
Some also use just-in-time publishing to assemble and generate documents or Web pages each time a users requests information. They also use user-defined variables to store static global information that can be used repeatedly in projects, making information portable and simple to update.
However, reviews of drafts are often issued in batches, and there may be a need to look at how this task can be spread more evenly.
An iterative publication of content?
If you have different types of users, you could publish content iteratively. This might mean, in a startup company, you write information for early adopters only at initial release, and update the documentation for less able users when the product is adopted by a wider audience.
Rather than a single major release, information could be published incrementally. That leads to a new challenge for technical communicators: knowing which parts to document and which to leave out.
Tools everyone can use
With Lean and Agile, issues that are forced to the surface are usually addressed by people swarming around the problem. With technical documentation, this can be difficult as Technical Authors tend to use tools that only they understand.
Ideally, you would have an authoring system that enables other team members to lend a hand, if required. You may need a system than can support content created by developers in a tool they know, such as Word or Markdown, or have a multi-user authoring tool that’s easy enough for occasional users.
Adopting one-piece flow could mean creating a flow that fits into the developers’ workflow. For example, it might mean using their tools, such as Git, to synchronise the development of documentation with the development of the product itself.
Communication and Scrums
Another challenge for technical communicators is that changes to the product are often communicated verbally at daily scrums. If the technical communicator isn’t at the scrum, their could be wasting time describing the wrong feature.
It’s not always possible to attend every meeting. Digital recorders can help. If the meeting is recorded on a digital recorder, the technical communicator could listen back to it later in the day. If they replay the recording at twice the normal speed, it can be reviewed quickly.
Managing variations in demand
Having an efficient system makes you more sensitive to variations in demand.
At Toyota, they address variations in demand in a number of ways. They keep the component suppliers informed of any changes, and they have many of the component suppliers located on site. To deal with changes with workload in technical communication, you can do similar things. You can establish protocols with technical authoring companies, such as Cherryleaf, to provide additional resource when it’s needed.
The development teams also needs to understand the impact of variations in demand. Ideally, the Technical Authors have some time to plan, and/or the variation can be smoothed out.
We need to understand variations in demands from end users. We need to be able to respond quickly to changes in customers’ needs, and have the ability to quickly reconfigure content to respond rapidly to any late changes to the delivered product’s functionality. Again, topic-based authoring and measuring can help.
Technical Authors can adapt to working with Agile teams, and they can work in an Agile way themselves. User documentation isn’t something that was addressed in the original Agile manifesto, and technical communicators need to fill in that gap.
We need to set up a rhythm and a way of working collaboratively. This means being on the kanban boards, collaborative authoring, one piece flow, working with the developers’ own workflow, considering the definition of “Done”, and measuring more than we’ve done before.
Please share your thoughts and experiences
Please use the comments box below.