Agile Development


Agility in development gives you the decisive advantage when it comes to the implementation of your solutions. In recent years, process models such as SCRUM have matured from an idea into a very successful framework for mapping IT projects, which in turn can help to neutralize typical factors that can threaten the success of complex IT projects.

Test-driven and behavior-based development, along with short release cycles / sprints and retrospectives, allow all project participants to check progress at any time, react to changed requirements, and validate decisions made within a project context. They can also help to generate new knowledge and allow it to flow directly into the next cycle. With every development run (sprint), the customer receives a fully functional software system that is progressively closer to the end product with every additional iteration. The biggest advantage of the SCRUM method, however, is that changes in the requirements are part of the model and can thus be incorporated after each iteration.

Flexibility is our strength

Flexibility in customer requirements is part of our method and ensures that our customers get what they really need in the end. If we assume that the demand for changeability increases with the increase in complexity in a system, then agile development methods such as SCRUM are particularly suitable for projects with a high level of complexity.


Depending on the framework conditions, SCRUM can be extended to include traditional process models. At COVIS, we focus on requirements engineering in this regard. This means that after each sprint, the customer can access a functional product. In this way, practical and logical correlations and findings, which could not be taken into account in a specification at the beginning, become transparent. In the traditional waterfall model, these findings only come to light at the end of the project and then generate enormous costs. SCRUM is based at its core on an incremental approach, the organization of development phases, and frequent feedback as well as the realization that a functioning product should take priority over a rigid catalog of requirements. To put it in more practical terms, in the end the customer does not necessarily receive what was specified, but what they actually need.