Agile Software Development

During software development projects we decide together with the client which approach is tailored for the project and the involved members. These approaches can be traditional methods enriched with agile strategies, e.g. the waterfall process, RUP (Rational Unified Process), as well as agile methods (Scrum, XP, Kanban). Our aim is to combine the development methodologies with modern and high quality, state of the art technologies while operating in accordance with the clients’ needs and the project’s purpose. By using these instruments we are able to achieve an increased performance and higher quality in the software development process and the software in use.

Our organisational goals are:

  • Keep the costs down
  • Reduce time to market
  • Improve Return of Investment

Our technical goals are:

  • Compliance with general standards (Test Driven Development, Behavior Driven Development)
  • Development and performance of tests for every part of code
  • Correct analysis and the resulting design of the software
  • Correct management of transactions and persistence
  • Creation of an infrastructure, which:
    • Offers good software build management
    • Provides high level of automation (Build Automation, Continuous Delivery & Deployment )
    • Supports continuous documentation
    • Offers collaboration services for the facilitation of communication

We look back on a long and successful experience of many years with agile methods and more specifically Scrum combined with XP (Extreme Programming). We employ Scrum Masters who have received their certification from Scrum Alliance. By using agile approaches we have observed high increases in performance of the software development processes of our projects, which is reflected in their productivity. When applying Scrum in the software development process, the process is iterative and incremental, which means that the product is augmented with new functions in every iteration.

Modern technologies

We endeavor to use the latest technologies available. Depending on the field of application we choose the most suitable tools for the prevailing conditions.


The agile methodologies aim to react fast on changes and therefore the software design must be flexible. Emergent design is mainly built on the idea to implement features step-by-step and refactor continuously the existing software base by proofing the functionality with automated tests.

Task Based Implementation

All implementation tasks are linked to the requirements and all links between artefacts must be transparent throughout the entire development process. The task-based approach means to trace all changes certain tasks have on the software. At any time the developers are aware what they are doing and when the task is completed. In the agile world this can be achieved by well formulated DoD (definition of done) and comprehensive user acceptance tests. One major requirement of the development process is that all involved tools are working seamlessly together.


Software development is a hard and often very complex process. There are many parameters that have to be observed in order to achieve the correct operating mode of the planned product. In order to avoid unwanted side effects and minimize their existence, tests must be performed. They not only help to find out whether the developed module functions in the way it is supposed to, but ensure that the operating mode isn’t altered afterwards. Qualified tests show any such change in the product’s operating mode. We use tools such as TestNG, JUnitSelenium, Cucumber, Robot Framework and many more and test our products during the whole development process, starting from simple unit tests, examining the entire business logic as reflected in the software and finally prove the observation of the specified acceptance criteria. Test driven or behavior driven development as major disciplines can be embedded in the agile development process.

Continuous Integration 

In software development and especially when agile methods are involved, usually there is a so-called Collective Code Ownership. This means that more than just one software developer are working on the software in creation. The resulting source code belongs to every member of the development team. One problem that results from the fact that many developers implement functions in one software product, (apart from the correct physical connection of the source code) is the right connection of newly developed technical and operational functions.

Every developer involved develops a part of the software locally on his computer. Afterwards the newly developed or enhanced components must be integrated in the software. During this integration the risk to produce unwanted side effects is high, because an existing functionality which worked correctly up to now may be altered or affected by a newly developed feature and therefore not function correctly anymore or even not function at all. By utilizing Continuous Integration, a process in which the source code is integrated by many developers at the same time, this problem can be easily dealt with. The goal is to avoid inconsistencies and incompatibilities between the state of the software on the local computer of the developer involved and the state of the software on the central repository. With Continuous Integration the integration of the source code can be operated continuously and automatically. Problems and conflicts arising can be easily identified and dealt with immediately. At this stage of the development, the correction of the software can be made with the lowest costs in time and money with the developer knowing immediately after every Continuous Integration process whether his integration was successful or not.

There are different tools which control the continuous build process, some are commercial, others are free products. The best-known are Cruise Control, Continuum, Jenkins and Bamboo.

Continuous Delivery

The automated deployment of software in different stages with different configurations is essential. It means that the team can focus on the implementation of technical functions without interruption and ensure that the software works correctly by deploying every change to the test environment. The functional correctness is ensured through automated testing within a production-like environment.

The next level of continuous delivery is continuous deployment which covers the automated deployment of every change passing the automated tests to the production environment.

Collaboration services

In enterprises and projects in operation communication and the exchange of information between the involved persons is essential for the success of the project. It is very important to make project-relevant information available without alteration for everyone at anytime. In order to document the knowledge in a project and to make it available for all authorized persons we make use of several tools, which make this possible:

  • Issue tracker like JIRA depict the operation organization of an enterprise.
  • Version management systems like GIT make it easy to track changes in the course of the project.
  • Confluence as some kind of open knowledge base
  • Instant Messaging Systems, such as Jabber support instant communication and information flow between the members of the team.

Continuous documentation and knowledge spread

Every project is characterized by its uniqueness. The generated knowledge and the description of the project should be documented along with the experience gained. This allows a fast and accurate access to information when needed and helps avoid a lengthy learning process. Documentation is a very important and significant part of our work in our projects, not only concerning the source code but also the entire development process. We differentiate between project-relevant documentation and team-related documentation.

Project-relevant Documentation

During the progress of the project artefacts like a daily updated Taskboard and the related Burndown-Chart that offer transparency in the development of the project. They too form a documentation which allows conclusions to be drawn concerning the project. Review Meetings where the implemented specifications are presented and Retrospectives in which reflections on the method of operation and the procedures used are made, offer platforms for information exchange and iniciate improvement.

Team-related Documentation

Within the project team it is the long-term decisions concerning analysis and design, which have to be documented. It is an important advantage for long-term team members as well as new developers to be able to reconstruct the reasons which lead to a certain solution and which strategy was followed. The documentation is not a sub-project of the actual project but should be seen as a part of the developing process itself.

The documentation of the following aspects is essential:

  • How-To: Contains technical instructions concerning the arrangement of the programming environment, the tools used, the installation of the application, the arrangement of the database, tips concerning the infrastructure of the project
  • Coding Guidelines: This comprises of the standards of the development of the code the team has agreed upon. It ensures a common quality level all members try to achieve. Reviews make sure the standards are respected
  • Technical documentation: Refers to the architecture, parts of the software or any resulting tasks
  • User documentation: Aims at the future users of the software. It functions as a kind of manual for the software product which ensures the correct use of the product.

In our projects, we only consider a task as finalized, if the respective documentation is delivered. By conducting code reviews, where the reviewer must have the documentation at hand, in order to understand the task, we make sure that a documentation is always made by the implementer during the performance. Tools, which are used in the development process, also supply data, which can be comprised in the documentation.

  • Issue tracker: These tasks contain descriptions of the specifications along with acceptance criteria, which must be observed in order to allow a correct acceptance.
  • Build Servers: Are able to produce automatically generated documents. These can be Javadoc files as HTML-pages, which describe the new API, but also code metrics, dependencies or test reports.
  • Version Control Systems: These make it easy to verify who implemented which part of the application. But also the development and the evolution of the project can be reproduced with a Version Administration System.

Last but not least the source code itself and the corresponding tests are documentation as well.