Skip to main content

Agile Web & Mobile App Development

Code the Cloud

Since 1998 we have been developing internet software as HERRLICH & RAMUSCHKAT GmbH. Since 2007 the former Team iRacer business unit operates as tecRacer GmbH & Co. KG. In numerous projects for medium-sized businesses and industry, we have contributed to the success of our customers with our services. A collaborative partnership as well as clean workmanship are our standard.

Agile software development process – How we develop software

Software development today

Modern solutions know no boundaries: The software must be able to be used flexibly on different devices – always where it is needed.

To increase accessibility and availability, data is processed and combined without delay. In many successful projects, these requirements have been taken into account and entail a complex relationship between technology and application process.

The challenges we love

  • Agile implementation processes make it possible to develop products together with the customer in an interactive, dynamic process. You benefit from regular, steady and concrete feedback, high user acceptance and a better cost-benefit ratio!
  • Serverless is an important part of projects when data has to be exchanged between locations, devices and requirements. The knowledge of infrastructure, programming and costs ignites many possibilities for fast and easy data exchange.
  • Software development today is a complex as well as diverse field. Our knowledge and experience in working with a wide range of technologies enables us to use a useful mix of technologies within the projects. Together with the client we support his users, independently of hardware and operating systems.
  • Today, custom development is no longer more expensive per se, since the functions for using the application are explicitly optimized and thus running costs can be significantly reduced. This not only creates added value for users, but also potential savings for IT.

Agile software development

One insight that is now well established in software development is that the sooner users can work with initial versions of software, the more accurately they can describe the requirements they have for it.

Manifesto for Agile Software Development

In order to develop the software with the best cost-benefit ratio for our customers, we work according to process models of agile software development. Behind this is a value system that is written down in the Manifesto for Agile Software Development:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

Software development as a craftsmanship

A further development of the agile manifesto is the Manifesto for Software Craftsmanship, which equates the development of software with a craft:

  • Not only working software, but also well-crafted software
  • Not only responding to change, but also steadily adding value
  • Not only individuals and interactions, but also a community of professionals
  • Not only customer collaboration, but also productive partnerships

We feel a responsibility to develop software that fully delivers the business value our client is seeking. We develop software that can be easily modified and extended. Software requirements are user requirements. Therefore, they are written from the user’s perspective. We use the construct of “user stories” for this purpose.

Working with cut off communication (“silo work”) promotes misunderstandings, incorrectly implemented features and wrong focus. Therefore, we attach great importance to frequent, intensive communication between developers, users and project managers.

Contract models for risk minimization

Fixed price per sprint

If the final scope of the project cannot yet be estimated and many requirements are not yet precisely described, this variant offers a way to start implementation anyway without incurring large liabilities. The requirements planned for a sprint are always estimated and agreed as a fixed price. An exit is possible after each Sprint. New features can be added before each Sprint. Features that are no longer needed can be omitted if they have not yet been implemented.

For the client, this model offers a good opportunity to become familiar with the agile approach and to assess the performance of the team. Since finished software is delivered after each sprint, dropping out does not mean being left without a result.

Agile fixed price

Agility does not necessarily mean that you cannot provide a realistic effort estimate in advance. However, the requirements must already be described more concretely and bindingly at the beginning of the project than in a purely agile approach.

New requirements can be added during the course of the project. In return, requirements of the same scope that have not yet been implemented can be omitted, so that the project budget remains untouched. If this is not possible, new requirements can be handled classically as change requests.

This model is suitable for small projects or if the requirements are already described in great detail and few changes are to be expected.

Reward model

This model is suitable for projects in which, for example, there is a high degree of uncertainty regarding the expected expenditure and technical difficulties due to the technologies used. The actual effort is reimbursed. However, the daily rate is so low that it is just enough to cover the costs. A success fee is paid for the features that the team delivers on time and error-free according to its commitment.

This approach provides an incentive for the product owner and the team to concentrate on delivering achievable features. However, excessive risk avoidance is countered by ensuring that the contractor does not incur losses due to the occurrence of technical risks.

Billing according to actual expense

Maximum flexibility is offered by billing according to the actual effort incurred. The product owner controls the course of the project based on his prioritization and bears the financial risk. Features can be added, omitted or changed as desired.

  • This model is ideal if the product owner and the team are well coordinated and the team has a good understanding of the user perspective.

Our Agile Web & Mobile App Development References