Individual projects

Our team of professional and experienced software developers knows how to plan, implement, introduce and support agile software development projects. We can draw on over 20 years of experience in business-to-business (B2B) and end customer (B2C) areas. The focus for us is the satisfaction of our customers by relying on speed, high quality, reliability and transparency.

Due to our flat structures and small agile teams, we can provide initial results in the development of new software systems within a very short period of time. In accordance with agile procedures, we provide operationally usable results with each iteration cycle, with our iteration cycles being at least two and a maximum of four weeks.

For us as a software service provider, the provision of high product quality is crucial in many ways. Most important are certainly the satisfaction of your users, the stability and the expandability of the applications. We ensure this through test automation, technical documentation, automated deployment processes and the use of tried and tested design patterns.

For you as our client, we offer the highest level of reliability by providing a dedicated contact person for all matters. Due to the agile approach of our projects, regular meetings and a general exchange also take place on short official channels. We therefore do without excessive bureaucracy, so that we can make and implement decisions directly with you in the agile project teams.

With the help of our project management system (Easy Redmine) we can offer you the highest degree of project transparency, which can range from regular evaluations, recorded times and burndown charts to direct access to our project management system. We can provide you with all project progress, costs and expenses incurred at any time and in full.

Project flow

We carry out new, innovative and individual projects according to agile process models, specifically following the principles of Scrum. In very simple terms, this approach involves close cooperation between you as the client (called product owner) and the development team we provide, as well as short development cycles (iterations, “sprints”) at the end of which a piece of usable software is always created.

These iterations are run through until all user stories and the acceptance criteria defined therein are fully met. The decisive advantage is that the results can be accessed and evaluated by you at any time. Projects therefore no longer run the risk of serving an end in themselves at a certain point in time, but can be questioned at any time and their added value assessed.

In our projects, we have made the experience that a pure culture of agile methodologies such as Scrum, i.e. strict adherence to the methodology, is not perfectly suitable for all customers and all projects. For this reason, we go into the circumstances of your company and your experience with agile projects by making adjustments, but also expansions in the process.

For us, an ideal agile project based on Scrum has the following key points:

Project initiation “The Initial Sprint”

We are pleased that you have contacted us and are considering implementing your individual software project. In order to offer you assistance in making a decision and at the same time to be able to create the most precise project planning possible, we carry out an “initial sprint”. Central points of the “initial sprint” are:

  • Requirements analysis (viewing, formulation and expansion of user stories)
  • Goal definition
  • Creation of the initial product backlog
  • Outline of the overall system (technologies, APIs, idea of the data model)
  • Application workflow
  • Initial sprint and release planning
  • Risk assessment
  • Summary and price range for the entire project

For the “initial sprint” we usually plan 2 weeks of close cooperation with you (approx. 80-100 hours). We only charge the “initial sprint” if the project does not materialize. The background is that in the course of this sprint many project details are worked out, which already represent an enormous benefit for you and the project in terms of content. With the findings of this sprint, nothing stands in the way of a direct project start for us from a technical point of view.

Role of the client

As the client, you have the project idea and – to put it casually – know where the journey should go. In order to be able to convey this to the development team from a technical point of view, provide at least one person in charge who takes on the role of product owner. Two people are welcome to take on this role, which can be helpful in substitution situations but also when distributing responsibilities and the time commitment. In this case, it is important that both people have equal rights in exercising the role of product owner. It is also crucial that this person is largely, ideally completely, freed from day-to-day operations. Only in this way is it possible, from our experience, to dedicate oneself completely to the project and, above all, to be able to contribute technical expertise.

A successful project is largely dependent on the technical competence and availability of the product owner, as this is required in almost every aspect of the agile approach.

User stories

Another important task that you have to fulfill in the role of product owner is the definition of requirements on a functional level, called user stories. Such user stories define acceptance criteria that are crucial for acceptance. From the user stories, the development team will later define specific technical tasks that are necessary to realize a user story.

As the product owner, you are in close contact with the development team in the course of this process and, over time, you will get a feeling of being able to better assess your requirements and transfer them to the release planning. Furthermore, the creation of tasks from user stories is of particular importance, as you receive feedback on the scope and effort and can intervene directly to expand or limit requirements, always with regard to time and costs.

We are happy to support you, especially at the beginning, with the formulation of user stories and acceptance criteria.

Release planning

With an agile approach, the seemingly lacking ability to plan, i.e. to be able to make time and cost estimates, is often a deterrent at the beginning – also due to a lack of or little experience. However, with increasing experience from agile projects, you will find that the risks of time and cost overruns are significantly lower than with classic projects. Release planning is important for basic planning, which is not set in stone and can dynamically adapt to changed conditions and requirements (product backlog).

As a product owner, you plan fundamentally which user stories are to be implemented or completed in which iteration cycles. Thus, a plannable number of iteration cycles can be targeted, with which the costs can also be calculated. Such release planning becomes more and more precise with increasing project progress and experience in estimating expenses, ideally in close cooperation with the team.

Role of the development team

Depending on the project, we provide a development team that works closely with you and is in constant communication. In addition, we provide a Scrum Master to monitor the agile approach, who supports the team in its daily work with organizational and technical support and removes obstacles. The Scrum Master thus has the backs of everyone involved, so that an optimal focus on the actual tasks is given.

Iteration cycles (sprints)

We recommend iteration cycles, also called sprints, with a duration of two to a maximum of 4 weeks. After each sprint, the tasks contained therein must be completed and a piece of usable software must be created. Each sprint is coordinated with you in detail so that only topics are processed that are relevant and necessary for you. As a product owner, you can therefore intervene in the direction of development at any time, thereby avoiding “extra rounds” or unnecessary effort.

At the beginning of a sprint, you and the development team do the sprint planning together, i.e. which specific tasks are necessary to achieve specific requirements (user stories). At the end of a sprint, there is a review appointment, at which the acceptance is also carried out.

Billing

With each sprint review and the associated acceptance by you, the sprint is billed. The hours incurred are billed at the agreed project hourly rate. In order to ensure full transparency, you will be given a list of every hour incurred. Each hour can be assigned to the specific tasks and thus the underlying user stories.

Prices