Project Management with Scrum

Scrum was developed by Ken Schwaber, Jeff Sutherland and Mike Beedle as a procedural model to enable the practical implementation of the principles of “Lean Thinking” or “Lean Production”. The aim is to achieve constant improvement in the production processes through agile software development, and to achieve the highest quality.

One of the forerunners in introducing lean production is the automobile company Toyota: the basic principles of Lean Thinking originated from the results of analyzing the problems in automobile manufacturing. These principles were transferred to software development. Here it was found that, despite the differences from the automobile manufacturing industry, similar obstacles have to be overcome, such as deviations from customer expectations in terms of the product scope and quality.

In the meantime, Scrum is being used by both large software companies such as Google and Microsoft, as well as by many small and medium scale establishments. All of them work with the core elements of the method, which we will present below.

Backlog

All the new properties and functions of the product that is to be developed are contained in the so-called backlog. This is not static, meaning, backlog-elements can be modified until the Development begins with their implementation. Elements of the backlog and the tasks that are necessary for it are often placed on index cards in the project room and updated during the regular meetings. Besides this, backlogs are often available digitally and online as well. In this way, they become part of the project memory of the team, and can be accessed even outside the project room.

Planning in Sprints

A Scrum planning unit, which lasts about four weeks, is called a Sprint. Several phases of a conventional software development cycle are covered in each such Sprint, such as the specification, implementation and testing. Before a planning unit is started, the product requirements of the customer are collected in the product backlog. The requirements with the highest priority here are again moved to the Sprint Backlog. These selected functions are then developed during the Sprint, so that executable, tested software is obtained in the end.

Distribution of roles in a Scrum-Team

For running the Scrum method successfully, the following roles of the team members are defined:

• Product Owner: This person collects the requirements in the Product-Backlog and creates the Sprint-Backlog from it, together with the team. This contains the new features that need to be developed in Sprint. Besides this, the Product Owner also defines the priority of the individual backlog-elements.
• Development team: The development team, which is multifunctional in composition, defines the tasks for implementing the backlog-elements with the highest priority and estimates the time required. Different areas of knowledge and roles are represented in the team, such as development, architecture, user-interface design and technical writing. In theory, every member of the team, however, should be flexible enough to be able to take on the role of another.
• Scrum Master: Together with the team, this person clears obstacles and ensures that the team can work together efficiently, and that all the team members are satisfied.

Important: Instead of following a prescribed set of rules, in Scrum, the teams autonomously define the rules for their cooperation and organize themselves to a large extent. A team, together with the concerned Product Owner, assumes responsibility for the completion of the work packages, which are defined by the team itself. In this way, it is possible to react in a flexible manner to changing requirements.

Regular Meetings

One thing that strikes one immediately in the calendar of a Scrum team member is the large number of meetings that are held during the course of the project.

• Sprint planning: In the Sprint planning meetings, the concerned Product Owner explains the contents of the backlog and agrees on a Sprint goal together with the team. After this, everyone together defines the tasks for implementing the backlog elements having the highest priority, which are then included in the Sprint Backlog. The Scrum-Team distributes the tasks and estimates the expected time needed for completion.
• Daily Scrum: A meeting of about 15-minutes is held daily. In these meetings, each member answers the following questions: What are the tasks that I have worked on since the last Daily Scrum? What are the tasks I would like to work on until the next Daily Scrum? Is there anything that is hindering me in my work? The Daily Scrum is meant for exchanging information within the team.
• Sprint Review: At the end of a Sprint, the result is presented on the system and the concerned Product Owner checks if the requirements have been fulfilled, or if any specific point needs to be included in the next Sprint.
• Retrospectives: In the retrospectives, the team looks back on the Sprint and every team member expresses his opinion on what was good and what could be improved. In this way, all the insights gained in any given planning unit will be incorporated in the next Sprint.

Scrum in technical documentation

Since the Scrum method is embedded in the project management level, it could be applied within the field of technical documentation too. To do so, a technical writing team should see itself as a Scrum-Team, managing its tasks in a backlog and implementing them in Sprints. Pre-requisites for doing so would be an authoring team of adequate size and authors who can take on various tasks. And of course, the autonomy of being able to plan its schedules independently, to a certain extent.

So far, technical writers have only been part of Scrum-Teams of software development. Here, too, several opportunities exist for technical documentation.

Documentation tasks in meetings and backlogs

Technical writers can participate in all the meetings and carry out their research there. In the beginning and at the end of a Sprint, they get to know important information about the new software functions, while the Daily Scrums help in keeping them abreast of developments. In this way, they come to know of decisions quickly and in binding manner. The meetings are often the most important sources of input and also ensure direct contact with the software developers.

The backlog is used with varying degrees of intensity, as a mnemonic in the planning stages to comprehensive platform for the overall communication in the project and for prioritizing and visualizing tasks. Technical writers also get to know through the backlog which developers are working on which software functions, and how much information is available on the topic. Often, it is useful if the development department identifies in consensus with the technical writers the software functions for which documentation needs to be created. In addition to this, the writers should ensure that, besides the development tasks, even documentation tasks such as “capture terminology” or “produce PDF” are incorporated in the backlog.

Time management and information gathering

The rather large number of meetings in a Scrum project also places a considerable demand on time, of course. Since technical writers are often assigned to several projects, the total number of meetings also increases accordingly. This leaves them with less time for actually creating the technical documentation.

The writers gather information in the meetings itself, and experience the latest changes to the software; hence, the time invested here can be considered to be time spent on input research and information gathering in most cases.

Problems arise if the meetings of the various Scrum-teams overlap. In this case, it becomes more difficult for the technical writers to get the necessary information, for instance, if the task priorities change. This is partly also due to the fact that, in software development, the emphasis on maintaining written records is lesser. Since software is developed in mutually independent units in Scrum, the information is often more modular in nature and more heterogeneous, and it is also obtained later and has a shorter life span. Moreover, the information has to be gathered in the first place through meetings and direct contact.

These problems can definitely be mitigated since the Scrum method attaches a lot of importance to project documentation: protocols of results and classic project documentation are certainly not forbidden here, and could also be communicated online. Besides this, Scrum provides a large number of other, possible documents: product concepts or specifications, User Stories that are tailored to functions or snapshots of the project progress.

New possibilities through Scrum

Do the documents change in Scrum? Opinions differ here: Some people refute this firmly, whereas others view the transition to Scrum as an opportunity for restructuring their technical documentation departments. Important key words here are topics, task orientation and online media. Of course, one needs to make sure that the overview of the product as a whole is not lost in the whole process, and that the documentation still succeeds in conveying the contexts and mutual interrelationships between the sub-functions of the product.

In general, however, it may be noted that the Scrum method, if used efficiently, can throw up several new opportunities for technical documentation:

Stay with the tried and tested, and use what is new to advantage

Technical writing can fall back on known concepts for creating documentation in Scrum projects. Modularization and topic-orientation help in structuring and organizing the contents and creating coherent relations between them. Since the developers also use these principles, the software functions can be mirrored well in the information modules. The tried and tested authoring systems play a decisive role in data maintenance, version management and the production of technical documentation. To keep the effort involved as low as possible, Wikis are used more and more frequently. In this form of documentation, which is still very new, all users can contribute directly. And this is exactly in keeping with the goals pursued by Scrum ever since it came into existence.

Scrum projects often involve deliveries of technical documentation, since all the software functions that were developed in a Sprint will be ready for delivery at the end of a planning unit. For this reason alone, the technical documentation needs to adapt to Scrum: the production system must be flexible enough to be able to create fresh documentation at short intervals. Some writers consider these early delivery dates an advantage, because this also binds the development to pass on all the information quickly. Often, it is possible to negotiate whether the documentation has to be ready at the end of each Sprint, midway between every Sprint or even an entire Sprint later, or only at the end of the release. In this way, writers will be able to execute their concluding processes as usual.

Scrum makes documentation more secure

Scrum projects can change quickly, since the planning and development are always “within sight”. Armed with the correct information, the technical writer is more confident and documents only content that is really relevant. What is new besides this is the possibility of a feedback channel, which takes the form of reviews and retrospectives in the Scrum process, wherein the writers can express their concerns to the developers and incorporate them into the process. Since the work steps and the effort involved in technical writing are often captured in the backlog, the development process becomes more transparent to all concerned.

Summary

Technical documentation requires agile procedures and can benefit from the Scrum method, provided this is understood properly and used creatively. This means that the core principles of early feedback from multiple quarters, effective communication and simplicity should occupy center stage and the procedural model should be customized in a flexible manner to the concrete conditions.

Links and literature for further reading

• Pichler, R. (2008): Scrum: Agiles Projektmanagement erfolgreich einsetzen. dpunkt.verlag. Heidelberg
• Schwaber, K./ Sutherland, J. (2010): Scrum: Entwickelt und fortgeführt von Ken Schwaber and Jeff Sutherland; Version: February 2010.
• Sigman, C. M. (2007): Adapting to Scrum: Challenges and Strategies. In: intercom. July/August 2007.