How agile are the agile implementations

A² - everything agile

more on the subject

Agile software development is mainly divided into three sub-areas: the agile principle, the agile methods and the agile processes. Agile principles are summarized in the agile manifesto, which consists of twelve sub-items. So are z. For example, the self-organization and self-reflection of the teams are essential for agile software development.

For me the most important point in the agile manifesto is the satisfaction of the customer or the stakeholder, which is achieved by providing good software quickly and reliably. These twelve principles are achieved, among other things, by applying agile methods, which I would like to outline below.

Many of these methods also show their strengths because they promote or accelerate communication between the parties involved. From my own experience I can increasingly ascertain that bad software is also created because there is too little or too unstructured communication at the crucial human interfaces.

It often happens that requirements are interpreted where a specific request would be necessary - but there is no request for the reason that the person concerned does not want to be seen as "difficult to understand". There are also no inquiries because the necessity was not recognized, it is supposedly clear. The communication problem can be improved by two methods: pair programming and code reviews. With both methods, two developers always work on a specific implementation and reflect on each other.

Agile methods: pair programming

In pair programming, two developers work simultaneously on the implementation of defined software features. Two developers sit physically in front of a computer, with one developer writing the code and the second developer reflecting on the problem and directly checking the written code. If the second developer notices errors in the code or misunderstandings in the feature / requirement, they can be addressed and discussed immediately.

Pair programming increases communication between developers.

This characteristic of pair programming immediately increases communication between developers. Especially in the case that a misunderstanding of the requirement would lead to it being implemented incorrectly or even the wrong thing. This measure makes it easier for developers to uncover misunderstandings and to be able to ask specific questions without hesitation in order to understand the requirement correctly and, consequently, to implement it correctly.

The concept should not be understood in such a way that the same developer always writes and the second one controls. Both developers have equal rights in the execution of both tasks and have to take turns on a regular basis. It is also recommended that the teams of two be exchanged as often as possible. This principle also increases the communication and thus the perspective of the software quality.

In addition to many of the side effects mentioned, the main goal of pair programming is to increase software quality. In addition to the increased software quality, pair programming also reduces code islands that only one or a few developers know; the code base is maintained and known by many developers.

Code reviews

Similar to pair programming, the four-eyes or the multiple-eyes principle is used for code parts. With the difference that two developers are not working on a requirement at the same time, but in parallel. The code parts are then checked by various developers using various criteria. These criteria can be the requirements that served as the basis for the developed part of the code. There can also be certain rules that must be observed during implementation; Code style or clean code rules should be mentioned here.

Code reviews ensure an increase in software quality.

A code review can proceed as follows: If a developer has implemented a requirement in the team, he asks another developer to look at this part of the code. This is done by the first developer explaining how he understood the requirement and which parts of the code he implemented for it and why. The reviewing developer reflects on this process from his point of view and shows - analogous to pair programming - improvements or points out misunderstandings. The increase in software quality can be observed in a similar way to pair programming.

Manual code reviews, in which two or more developers take part, are particularly suitable for checking implemented requirements to ensure that they have been implemented correctly and that they cover the required requirements. For coding style and clean code rules, it is also advisable to include automated reviews in the process.

Since these can be repetitive and monotonous, there is a risk that the developers involved will overlook deviations or that the reviews will be left out due to time pressure. Automated reviews can be mapped by transferring them to a continuous integration process and using a corresponding CI server, e.g. B. Jenkins. This ensures that no code style or clean code reviews are forgotten or ignored, which in turn significantly increases the software and code quality.

Test-driven development

In addition to the just automated code reviews, also often referred to as static software tests - static because the code for this test is not executed, but only analyzed and compared against rules - another agile method is test-driven development. The resulting tests and test cases are dynamic software tests, which should also be carried out automatically; a CI server such as Jenkins is also suitable for this.

In the case of dynamic software tests, in contrast to static software tests, the code is executed. Test-driven development is characterized by the fact that, as is generally the case with waterfalls or V-models, the tests are developed after implementation. In test-driven development, the tests are first written and then the requirement is implemented until the (unit) test for this requirement no longer fails.

The procedure for developing unit tests and units can be described as follows: Iterations, as they are generally known from Scrum, are also used in test-driven development. Unit test and the units to be tested are developed in parallel in small, repetitive micro-iterations. The iterations should only last a few minutes.

Three steps are usually repeated in the iterations: In the first step, the test is written for the desired error-free behavior. This test will initially fail. In the second step, the program code of the unit is adapted with as little effort as possible until the test no longer fails. In the third step, the just implemented part of the code is immediately refactored, for example to remove repetitions or to abstract parts where appropriate. This refactoring can be carried out safely, as a test run can be carried out at any time to ensure that the unit is still working correctly.

These steps are repeated until the required functionality of the unit is achieved. With this type of software development, software can be designed in an evolutionary and incremental manner and continuously improved. After each incremental improvement step, the unit tests ensure that the unit continues to map the required requirement (s) and operate them correctly.


Pair programming, but more so manual and automatic code reviews, will mean that existing code parts have to be refactored. The goals of refactoring measures are to structurally improve the source code - manually or automatically - without changing the mapping of the requirements it contains. These structural improvements increase the readability, comprehensibility, and maintainability and / or expandability of the program parts with the aim of reducing the effort required for a later error analysis or functional expansions.

In particular, those parts of the code that were noticed during automated static software tests are suitable for automatically correcting these rule violations. A distinction can be made between rule violations that result from disregarding styling rules and those that violate structural rules. The former can be easily remedied automatically; Manual refactoring is usually required to resolve structural rule violations.