Not every Scrum team may define its own software development process. The reasons for this are often regulatory requirements of the respective industry, customer requirements or existing processes that have grown over many years in companies. V-model oriented development processes are particularly common in this environment. This presents Agile Coaches and Scrum Masters with the challenge of integrating the existing V-Model processes with the Scrum framework. This article shows how to combine Scrum and the V-Model of software development.
Motivation und Hintergrund
The Scrum theory does not define and describe a development process according to which the Scrum team should or must work. With the Scrum Events, it merely defines a framework for the process organization, as well as values, artifacts, pillars and roles within a Scrum team. Theoretically, each Scrum Team is free to choose and define its own development process.
Unfortunately, the practice looks a little different, and often much more complicated. A not inconsiderable number of Scrum teams, especially in established industries, are not completely free in the choice of their development processes. These restrictions often result from regulatory requirements of the industry or explicit requirements of the customers regarding the processes to be applied. Often the V-model of software development is used in these organizations. This is used especially when there are high requirements with regard to the traceability of the requirements through the code, the selected implementation and the relevant tests.
When companies carry out an agile transition from classic project models to agile methods, the new methods collide with the grown, established processes along the V-model. Since the requirements regarding traceability and documentation remain even when using agile methods, it makes sense to integrate the existing processes with Scrum. This article shows why this is not a contradiction and how existing processes in the V-model can be combined with Scrum.
Das V-Modell der Softwareentwicklung
Let us now take a look at the V-model of software development. The V-model is a process model that was originally designed for software development, but is now also used in many other disciplines. It represents a further development of the classical waterfall model. In a development according to the waterfall model, feedback on errors and problems found is only possible at the very end of the process chain. Much earlier feedback is provided when using the v-model.
The name V-model is derived from the classic representation in the form of a V. The left side of the V represents the process steps of requirements engineering and implementation, while the right side of the V contains the process steps of validation. In each case, implementation and validation steps of the identical abstraction level are opposite each other. From this it can also be derived in which level of detail of the implementation an occurred error can be found. The following illustration shows a possible representation of the V-model and the process steps it contains.
As we can see, the V-model spans two dimensions. On the one hand, the chronological sequence of the development from the first to the last development step is shown, and on the other hand, the depth of detail in relation to the individual process steps is also mapped. The feedback loops of the individual validation steps to their associated development steps can also be seen clearly.
Prozessschritte im V-Modell
The first process step of the V-model is the specification of requirements in collaboration with the customer. Then, functional requirements of the product are derived from these customer requirements. These two steps form the requirement engineering in the V-model of software development. The next two steps serve to create the software architecture and, derived from this, the software design of the individual software components.
In the center of the V-model, at the bottom of the V, is the actual implementation step. Here, the defined software components are developed according to the defined software design. This step has by far the highest level of detail of all process steps.
The implemented solution is validated in a test of the individual components, which is equivalent to validating the specification of the software design of the respective component. In the integration test the interaction of the different components is tested, and thus the software architecture as such. A system test follows, in which it is examined whether the functional requirements of the solution were correctly implemented. Finally, an acceptance test follows. This serves the validation whether the finished product solves the problem placed by the customer / the requirements placed by the customer satisfyingly and completely. If an error is found in one of the validation steps, the cause of this error is to be found in the equivalent process step of the left side of the V.
The V-model of software development thus defines the basic steps of the software development process. It describes the various steps of requirement engineering, implementation and validation. Along these process steps, a specific implementation of the V-model can take place in each organization in adaptation to the needs of the organization. However, the V-model does not define a time frame for the sequence of these processes, nor how and when the various development steps should take place.
Das V-Modell Der Softwareentwicklung
Das V-Modell ist ein Vorgehensmodell, welches ursprünglich für die Softwareentwicklung konzipiert wurde.
Produktentwicklung mit Scrum
In contrast to the V-model, Scrum is not a meta-description of a development process, but a framework which, among many other aspects, enables the temporal structuring of the processes of an organization. As the Scrum Guide 2020 tells us:
Scrum ist ein leichtgewichtiges Framework, das Menschen, Teams und Organisationen hilft, durch adaptive Lösungen für komplexe Probleme Werte zu schaffen.
Scrum spezifiziert hier Dinge wie die eigenen drei Säulen, die Rollen innerhalb eines Entwicklungsteams, die von einem Team durchzuführenden Events, die zu bearbeitenden und zu produzierenden Artefakte sowie die in einem Team zu etablierenden und zu lebenden Werte.
Requirement Engineering mit Scrum
The basic event in Scrum is the Sprint. This is a container for all other activities in Scrum. The duration of a sprint can be up to four weeks, should ideally be constant, and can be chosen by the team itself. Within a sprint, the team transforms the Sprint Backlog into a new iteration of the increment. Furthermore, the team is continuously involved in the development, coordination and clarification of new requirements. This process is called refinement and describes the requirement engineering in a Scrum team. This continuous process explicitly does not begin and end at the boundaries of a single sprint. It is operated across sprints and serves to clarify the content and technical aspects of future requirements/tasks.
Product Backlog Refinement ist der Akt des Herunterbrechens und der weiteren Definition von Product Backlog-Elementen in kleinere, präzisere Elemente. Dies ist eine fortlaufende Aktivität, um Details hinzuzufügen, wie z. B. eine Beschreibung, Reihenfolge und Größe. Die Attribute variieren oft mit der Domäne der Arbeit.
Zusammenfassend definiert Scrum das Sprint Backlog als eine Sammlung von Anforderungen/Aufgaben, die innerhalb des Sprints umgesetzt werden sollen. Das Inkrement beschreibt die daraus resultierende neue Version des Produkts. Da Sprints inkrementell aufeinander aufbauen, wächst auch das Produkt inkrementell. Das wesentliche Merkmal dieses Sprint Backlogs ist, dass jede Aufgabe, die fertiggestellt wird, an den Kunden ausgeliefert werden kann. Ein Sprint ist also ein geschlossener Zyklus, in dem Anforderungen in eine auslieferbare Version des Inkrements umgewandelt werden.
However, what Scrum explicitly does not specify is the way in which a team should transform the Sprint Backlog into the Increment. This „way“ is what we know as the development process. This process is explicitly not highlighted by the Scrum framework because it is normally industry, organization and often even team specific. In a Scrum team, this process contains the tasks of implementation and validation, while the requirement engineering is covered by the refinement. Here too, it is not described how the refinement is to be carried out, but only that it has to happen. In contrast to the V-model, Scrum maps the requirement engineering in a separate process that stands beside the development process.
Die Inputs und Outputs der Scrum Events
Die Kombination von Scrum und dem V-Model der Softwareentwicklung
Let’s now take a look at how the meta-process of the V-model can be combined with Scrum. As we have already seen, especially companies with established, classic processes that are starting an agile transition face this problem. On the one hand, we have the development process described in the V-model, and on the other hand, the rules defined by Scrum for structuring the project organization.
As described in the last section, in Scrum there is a separation between the actual development process (implementation and validation) and the requirement engineering process. This separation does not exist in the V-modell of software development. However, this point is exactly where we can split the V-modell to make it compatible with the requirements of Scrum.
Klassische Organisationen und Entwicklungsprojekte arbeiten mit Lastenheften und Pflichtenheften. Die Lastenhefte beschreiben die Anforderungen des Kunden, während das Pflichtenheft die beabsichtigte Umsetzung dieser Anforderungen einschließlich aller Abweichungen beschreibt. In den meisten Fällen findet die Diskussion und Klärung dieser Dokumente zu Beginn des Projekts statt. Spätere Änderungen werden dann durch Änderungsanträge in komplexen Änderungsprozessen beauftragt und verursachen nicht nur zusätzlichen Aufwand, sondern auch zusätzliche Kosten.
Aufspaltung des V-Models
The combination of Scrum and the V-model of software development is made possible by the fact that the requirement engineering is stretched over the entire duration of the project. The classical approach of the V-model is therefore transferred into the continuous refinement process of Scrum. Of course, this requires prioritization of the requirements by the customer, because only in this way can the most important requirements be discussed, refined and implemented first. This makes it possible to always refine requirements two to three sprints before their actual implementation, to adapt agile priorities, and thus to introduce Scrum in a classically influenced environment.
All requirements for a product developed with Scrum, including the refined and agreed requirements, are found in the Product Backlog. From this Product Backlog, the Scrum team selects the requirements to be implemented in the next sprint, during the Sprint Planning event. These then form the artifact of the Sprint Backlog. Now, here comes the crucial part. As already mentioned, Scrum does not describe a development process. How the Sprint Backlog is transferred into the increment is therefore solely in the hands of the development team or, if applicable, the development organization.
Die Umsetzung des Sprint Backlogs, d.h. die Erstellung des Inkrements, kann nun gemäß der im V-Modell beschriebenen Umsetzungs- und Validierungsschritten erfolgen. Eine Einschränkung ist dabei, dass alle Anforderungen, die den Abnahmetest erfolgreich bestanden haben, die Definition von Done erfüllen müssen. Das Inkrement muss sich also zu jedem Zeitpunkt in einem lieferbaren Zustand befinden. Die Trennung des V-Modells in eine Requirements-Engineering-Phase und eine Entwicklungs- und Validierungsphase macht es also möglich, Scrum und das V-Modell für die Softwareentwicklung zu kombinieren.
In this article we have looked at how it is possible to combine the classic V-model of software development with the agile framework Scrum. We have seen that this requires breaking up the development process according to the V-model. The transfer of the requirement engineering into the refinement process lived by Scrum teams enables the combination of established processes with agile methods. However, it is necessary to win over the client for cooperation according to this model. Only if the customer is willing to prioritize his requirements accordingly and to coordinate them in a continuous process, the combination of Scrum and classic development processes according to the V-model of software development can succeed.