We support you throughout all phases of software development, assist you with agile teams and,if desired, take over responsibility in fixed-price projects.
Agile software development according to SCRUM
Especially when implementing larger projects, our teams work according to agile frameworks, e.g. SCRUM. The underlying idea is based on the fact that the full scope is too large and complex to be fully worked out before the development starts.
Instead, at the beginning of the project, the so-called product backlog is filled in, which maps the requirements for the solution. The individual product backlog items are only described in very rough terms and are only detailed by the team before the actual implementation.
The implementation of the selected backlog items then takes place within the framework of individual sprints with a runtime of 2–4 weeks. At the beginning of a sprint, the team selects several product backlog items that they would like to implement during the sprint and estimates the associated input.
Each sprint should deliver an intermediate result that can be tested and taken over by the enduser and thus represents an executable, incremental extension of the overall solution. This regular and timely provision of a new version has the decisive advantage that the end user regularly receives an interim result and any feedback can already be incorporated in one of the next sprints.
Advantages and disadvantages of the approach at a glance
End users can evaluate an MVP (Minimum Viable Product) at the sprint end
Flexible adaptation of requirements possible after each sprint
Basic understanding of the requirements at the beginning of the project sufficient, detailing of the requirements as part of the project
Involvement of end users in the development leads to higher end-user satisfaction with the solution
No fixed framework for the overall project
Effective project management requirements
Project members must be able to evaluate intermediate results
Project members must be able to evaluate intermediate results
Traditional process according to waterfall approach
The “traditional process” according to the waterfall approach is often used in fixed-price projects or when a high degree of planning security is decisive for the client. Unlike in the agile approach, all requirements are fully elaborated as part of the requirements analysis before the appropriate architecture is selected in the next phase. While this approach is primarily associated with planning and cost certainty, it comes at the expense of flexibility. Another disadvantage is that the end user only receives an initial result at a very late stage and there is no longer any influence on the development.
Advantages and disadvantages of the approach at a glance
Classic project management
High planning reliability due to a firmly defined project scope
Responsibility for results lies with the service provider
No flexibility in the scope of delivery without contract adjustments
Actual result only fully discernible at a very late stage
All requirements must already be known in detail before the start of the project
The middle way: Agile fixed price
Agile fixed price as a middle way makes it possible to provide a fixed cost framework while maintaining the flexibility of the agile approach. Thus, at the beginning of the project, a rough effort estimate is prepared and a cost window for individual components is established. During the implementation, it is possible to decide which requirements are implemented for each component and requirements can be replaced by other requirements with the same input at any time. This method gives the client the certainty that the costs will be met, but at the same time offers the possibility to take into account new findings and to align the project closely with the needs of the end users.
Advantages and disadvantages of the approach at a glance
Agreement regarding the strengths of the waterfall and agile methodologies
Flexibility in the selection of requirements to be implemented
Budget compliance ensured through prioritisation of requirements
Responsibility for results lies with the service provider
Effective project management requirements
Project members must be able to evaluate intermediate results