Agile development techniques have become well established for the development of new and innovative software projects. It is in this context that the way in which technical documentation is developed has undergone a significant evolution. It may be interesting to understand the reasons and consequences of these new work scenarios.
Agile techniques for developing software
The more traditional models, based on the so-called “waterfall” paradigm, proved inadequate for the needs of the software industry, where constantly improving technology requires high flexibility and rapid changes of direction. In fact, the waterfall approach, highly successful in manufacturing processes, prescribes a perfect sequence of development steps: requirements, analysis, design, implementation, documentation, and testing. This technique is only effective if the steps remain stable and predictable throughout the process. Errors and changes would be the cause of unexpected and costly setbacks.
In software development, and perhaps in other technology-driven applications, new marketing ideas must be constantly evaluated within the latest technological framework. As a result, specifications and analyses cannot remain stable because they must be rediscussed to prove their value when applied to new technologies.
Non-agile, cascading processes tend to be slow, impose strict role separation, discourage cross-departmental collaboration, and can even foster conflict between teams, such as marketing and engineering, or development and testing (technical communicators are always trying to make peace, aren’t they? :).
This is why new agile methods have been proposed since the mid-1990s. These methods use more iterative and incremental processes to develop software.
As far back as 2001, the Agile Manifesto laid out the principles of the new approach:
- People and interactions rather than processes and tools
- Rapid prototyping – deliverable software instead of exhaustive development documentation
- Collaborate with customers instead of negotiating contracts
- Respond to change as it happens instead of following a rigid plan.
- Agile methodologies and Scrum
Several methodologies are proposed by the Agile approach. Among them, the Scrum model suggests that small, highly interactive, cross-functional teams can achieve excellent results by working as a unit, like a scrum formation in rugby (Scrum).
Since the late 1990s, Scrum has been used successfully in various projects and spread rapidly. The method is based on the following rules:
- A Scrum team typically consists of five to nine people, including a Scrum Master, several development and test engineers, and at least one technical writer.
- The Product Owner collects requirements in a backlog of features sorted by priority.
- Development is organized into short iterations, called Sprints, during which a selected set of the highest priority requirements are scheduled for completion.
- Sprints are planned in detail and last a few weeks, usually a month, to deliver a working (and documented!) product release on a regular basis.
- During the sprint, the Scrum team works closely together and meets frequently, even daily, (daily scrum) to discuss and quickly resolve any coordination issues.
- The documentation released at the end of each sprint, while preliminary, is usable by everyone in the development team.
New roles and opportunities for technical writers
At least one technical writer is part of every Scrum team and follows product development from the beginning. This is great news. In the traditional development approach, techwriters suffered from being involved very late in the product development process. They would scramble to understand what it was all about and then rush to document the final product without having a chance to contribute intelligently to the development activities.
With Scrum, the role of technical writers as part of the development teams can be significantly more important. In addition to the actual product documentation (the classic user manuals), techwriters can help developers and testers create better project documentation, i.e. software analysis and design documents.
In addition, technical writer can interact with developers and provide important comments on the usability and ease of use of the software. In fact, hard-to-document features often need to be redesigned before the documentation can be written!
Planning and monitoring activities during sprints is very detailed, and accurate estimates are required for all documentation tasks. Planning forces technical writers and all other team members to improve their estimation skills.
New technical skills may be required. These may go beyond the traditional abilities of a technical writer. Depending on the software project, knowledge of new project-related software standards and techniques may be useful. Techwriters must have or develop sufficient skills to actively participate in daily meetings with software specialists and interact effectively with them.
Cultural differences and the need for a new set of competencies
Working in a Scrum team can be a change of pace for most technical writers. If you like to work at home, in silence and perfect solitude, then Scrum is not for you, because it requires constant team interaction and daily meetings.
In new Scrum teams, there can be a culture clash at the very beginning, when you have to meet with developers and software testers on a daily basis. In some cases, these engineers may initially view documentation colleagues as aliens to the team and may overlook the importance of our documentation efforts.
In general, however, working together on a daily basis to achieve a common goal helps to develop harmony and sympathy among the members of the small team. An effort must be made to bring all experience and expertise to the team, despite possible initial difficulties.
As a primary task, techwriters must ensure that documentation tasks are properly defined at the beginning of each sprint, and then proceed to complete them. In addition, techwriters must be ready to help beyond their normal tasks: for example, correcting a software specification, drawing or reviewing a complex diagram, helping to write a project report, and so on. The scrum team can only win or lose as a whole.
Note that unlike previous techniques, product documentation is a bottom-up development process, with monthly sprint releases. Each sprint iteration must deliver a complete, though possibly minimal, product. This includes documentation. While focusing on the individual features to be released, the team should use its experience to keep the big picture in mind, i.e., the overall goals of the product and its documentation.
Conclusions
In a creative, vibrant and empathetic environment, the Scrum methodology can lead to outstanding performance. To make this happen, everyone must be committed to the team. They must learn with humility and teach with respect and understanding.
In other words, just like in rugby, everyone needs to push forward as much as possible while contributing to the team coordination that is essential for the scrum to run harmoniously and ultimately win the game.
If you are interested, please contact us, for a free in-depth discussion.
A few classic references
1) http://www.agilemanifesto.org.
2) The New Product Development Game by Hirotaka Takeuchi and Ikujiro Nonaka, in The Harvard Business Review.
3) Sviluppo software agile con SCRUM by Ken Schwaber e Mike Beedle, Prentice Hall. There is also an interesting short extract of this text in Italian here.
