Agile Process Models

The motivation of the agile approach is already clear from the choice of name: Agile means to be swift or versatile and refers to rapid reaction to changes in framework conditions. The original description was “lightweight”. This was however discarded due to possible negative associations with this term in the course of development.

Agile process models in software development break away from the classic Waterfall Model and its variations. Instead of the fixed sequence of “specification, design and implementation”, the project is carried out in very close and direct collaboration with the customer. The specification gradually occurs during implementation.

One important advantage of agile process models is the collaboration with the customer. The customer receives what he needs and not what he has specified. This is an important benefit for projects whose requirements are still unclear at the beginning or are subject to major changes caused by external influences.

Another advantage is the breakdown of bureaucratic structures, e.g. fewer documents need to be created and maintained. A typical criticism of classic process models is the distance from the client or user. While the specification still occurs in close cooperation, the client often has virtually no influence on the definition of the product during implementation. Agile software development on the other hand generally attempts to manage with less bureaucracy and fewer explicit rules.

The goal of agile software development is to make the development process flexible and slimline. In the development, the focus should rest more on the objectives to be achieved and be able to respond to technical and social problems in the software development.

Agile software development is a counter-movement to heavyweight, bureaucratic and, considered from the outside, traditional software development processes: It considers it important that rules first arise through the team work of the developer group. In this way the rules are more relevant and in turn produce more favorable results.

This viewpoint is specifically represented in the “Agile Manifesto”. In 2001, leading representatives of the agile software development movement met and adopted the agile manifesto. Among the signatories, in addition to Scrum co-founders Mike Beedle, Ken Schwaber and Jeff Sutherland, were luminaries of the scene such as Kent Beck (XP), Alistair Cockburn (Crystal), Ward Cunningham, Martin Fowler, Ron Jeffries, Andrew Hunt (Pragmatic Programmer), Robert C. Martin and Dave Thomas (Ruby on Rails).

The text of the Agile Manifesto reads:

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools; working software over comprehensive documentation; customer collaboration over contract negotiation; responding to change over following a plan. That is, while there is value in the items on the right, we value the items on the left more.

These key messages are deliberately brief and kept somewhat “bold and striking”. To explain this, it can be said of the philosophy behind the single points:

• While well-defined development processes and advanced development tools are by all means important, more important however is the competence of the employees and the efficient communication between them since any development sinks or swims with the ability of the team. The team members should determine the agile process and adapt it to the specific needs.

• Well-written documentation can be helpful but the ultimate goal of the development is nevertheless the finished software. All activities serve just one goal: to develop executable and acceptable software. The transfer of knowledge from person to person should have priority and documentation should not be an end in itself. Likewise, the individual development phases should not be strictly separated because this is virtually impossible in reality: Design, documentation – where necessary – and testing should form an entity. Working software is the most important measure of progress, not extensive documentation.

• Customer satisfaction is the most important benchmark for development success. For that to happen, collaboration with the customer must remain the focus. Only when the customer has actually seen and used the system are they really in a position to explicitly formulate how their system should look and where there is a specific requirement for amendment.

• In the course of a development project, requirements and boundary conditions change as well as an understanding of the problematic issues on the side of the customer and developer. The team must be able to react quickly – and above all, also want to do so. Change requests or the customer’s inability to formulate the complete requirements in detail at the beginning of development should not be seen as a lack of expertise or as “stupidity” on the part of the customer.

Generally, with all of these principles, the following has to be considered: “more important than” does not mean that the “classic” project characteristics are unimportant. There must, for example, always be plans, contracts and documentation. These should not stand in the way of the agile values or the progress of the project and should only be used where they are actually beneficial.