Ritva Siltanen, Nokia Siemens Networks
The world of software development is becoming increasingly agile. While the traditional waterfall development approach called for planning and scheduling the work for the whole release cycle in advance, the agile development approach focuses on clear short-time goals. Instead of emphasizing compliance with the process, the agile environment embraces process adaptability. For technical writers, agile development is a great opportunity to step out of the current comfort zone and start moving towards a new target: extreme technical writing.
The Scrum method suits many development organizations who want to become agile because it is fairly straight-forward and requires little effort to implement. In Scrum, the development effort is time-boxed into a series of sprints that have a predefined duration. The self-organizing teams plan the amount of work they can accomplish during each sprint to create a working increment of the software. If new customer requirements emerge between sprints, they can be taken into account without major deviations from the original plans.
When the software development organization goes full speed ahead with agile, the technical writing team has to face a choice: maintain the traditional approach to creating documentation or join the agile train.
It probably feels tempting to continue doing what you have always been doing. It has worked well, or well enough. If something has gone wrong, it has been easy to blame software that is not ready, technical specifications that were inaccurate, or a process that called for this but delivered that. The company may also read the agile manifesto literally and claim to promote working software over extensive documentation. Do not feel intimidated–it is only a matter of agreement. Usually, their reading just means that the developers should not use their time on creating perfect specifications and feature descriptions before starting to implement the code.
What if we say that the goal of a sprint is to produce an increment of a working product and not only software? It immediately includes documentation in the picture and allows the technical writers to become part of the development organization. Joining the development team may be an ambitious goal, but it is worth pursuing—it promotes seamless collaboration with the software developers. In the best case, it gives the writers a chance to spot inconsistencies in the product (for example, the user interface) early on and suggest improvements before the product hits the market. It also requires more effort from the writers. They have to live and breathe the software under development instead of documenting the final product.
Agile technical writers participate in the daily standups (scrum meetings), include their tasks in the sprint logs, and estimate their effort in the sprint backlog together with the other dedicated members of the team. When the developers demonstrate the working software at the end of the sprint, the technical writers can proudly demonstrate the working online help or an increment of the user guide at the same time. The sum of these two is bigger than any one of the achievements alone.
You may wonder if there is space for a documentation (project) manager on the agile team. There is still need for someone to act as the buffer between the writers and the bureaucracy that is inevitable at least in a bigger organization. There will be steering meetings, decision-making boards, planning meetings with the Product Owner, and other sessions that require a holistic picture of the product lifecycle. Even process adaptability means conformance to a process that runs on a different level than the actual software development. The target of that process is to produce a saleable release of the product that complies with a set of predefined requirements. In an ideal situation, the agile development team, including the technical writers, can do their work with minimal interference from the other parties.
What about extreme technical writing? I have read about writing teams that produce a page of text and publish it immediately for the customers to see. They may use a wiki in the company’s extranet to get customers’ to review content. When they receive customer feedback, they incorporate the relevant changes right away and publish a new version. They are fast, focused, and truly customer-oriented. It may not be possible for all writing teams to achieve such a flow, but change is better than staying still. Sometimes having fun on the way to the next target is more important than getting there!
***Disclaimer: the viewpoints expressed in this article are personal opinions of the author and do not directly relate to the organization or company she works for.***
Ritva Siltanen is a technical communications professional in the telecommunications industry. Currently, she holds the position of documentation project manager at Nokia Siemens Networks. An active contributor to the Writing Mafia blog, she is interested in web user communities and social networking as a phenomenon. Check out her updates on Twitter, too.