Don’t just try to fit into development’s agile process. Create your own lean content development process.
Technical writers are increasingly finding themselves involved in the agile process of the development organization. The most common way this happens is that a writer gets assigned to the team for a sprint and is expected to produce documentation in the same sprint as the developers produce the feature.
This has one huge plus for writers: development cannot declare the sprint complete until the documentation is done. This means that it is in the interest of every developer to help ensure that the tech writer has what they need to get their work done. Given that getting information when needed is a major issue for many tech writers, this can be a very big win.
But there are plenty of downsides to this arrangement as well. Some of the more common complaints include:
- There are often not enough writers available to assign one writer to each sprint team full time, so the writer ends up being assigned to several teams. Attending multiple scrum meetings can then take up a big chunk of the day, and juggling the priorities of multiple teams becomes a significant headache. Also, having to switch gears between different features can inhibit the writer’s flow, greatly increasing the time it takes to write the content.
- It does not always take the same amount of writing time to document a feature as coding time to implement it. Some features that have major architectural impact but little user-visible behavior can take weeks to code while requiring little or no documentation. Small changes to user-visible parts of the system, on the other hand, may require major documentation effort while being implemented with very little code. The writer trying to work in concert with the sprint team may be scrambling one week and twiddling their thumbs the next.
- Documentation is at the mercy of development’s process and schedule, which is not being optimized for the creation of documentation, but of software. And, of course, not every organization implements agile well. Being at the mercy of a good process designed for something else is not ideal. Being at the mercy of a bad process designed to produce something else is very difficult.
- Tying all docs development to software development sprints may encourage product oriented rather than task oriented or user oriented documentation. Petko Mikhailov makes this point in a post on LinkedIn where he notes:
My experience has been that Agile methodology naturally leads to product-centered documentation and it is quite a struggle to maintain the user perspective and the needed content structure.
This is ironic because Agile has been designed to better cater user needs; it however doesn’t seem to recognize that documentation has its own needs that are separate from the product development programming needs.
I’m certain there are writers who are integrated into an agile team and who do feel that their needs are being considered. But while this may be true, Mikhailov’s point is also true: documentation’s needs are separate from development’s needs. Successful integrations may owe more to the flexibility and thoughtfulness of the people involved than to the inherent virtue of integrating documentation into development’s agile process.
This is why I always advise tech comm groups not to simply integrate writers into development’s agile process, but to develop their own lean/agile process and optimize the interface between their process and development’s process.
I see this more in lean terms than agile terms, because agile is designed specifically for software development, whereas lean is more general. Agile, however, can be seen as the application of lean principles to software development, so the two approaches are broadly compatible.
What lean tells us is to focus on value and on the value stream. Documentation is a distinct product with a distinct value set to deliver. It’s units are not necessarily the same as development’s units. Inserting tech comm into development’s process involves inserting tech comm into development’s value stream. The value that development produces is features, so naturally there will be a tendency for tech comm to end up documenting features, and it will be hard to find time to develop docs that are not tied to a specific feature, as Mikhailov notes.
Creating your own lean documentation process lets you focus on your own value stream, to deliver your own value, which is providing task assistance to users. Set up that value stream first, then start to ask what is the right interface to the development process to get the information you need to create value in your process.
Also, lean is a set of principles rather than a set of practices. Agile practices were developed for software development, and may or may not be appropriate, separately or as a whole, for other processes. Following lean principles allows you to develop practices that are optimal for content creation rather than software development.
One of the most important benefits of taking this approach is that it forces you to think in terms of making your entire documentation process lean, as opposed to simply adapting what you do now to fit into the agile mold dictated by development. Indeed, I would urge all tech comm groups to undertake a lean transformation of what they do, regardless of whether their development organization is practicing agile or is still using a waterfall methodology.
How to do a lean transformation of your docs department is a larger topic than one blog post can handle, but here are the slides for a presentation on lean content development that I gave at Lavacon 2013: