Photo: Aleksandr Pobedimskiy – shutterstock.com
Before starting an IT project, you should ask yourself a few basic questions: Is the Scrum process model developed in the 90s still the right one and agile enough for the upcoming new generation of software development methods? Should you rethink agility, and if so, how? Perhaps against the background of a detoxified and revived waterfall model? Or should future projects go in a completely different direction?
The advantages of Scrum are well known. The period from the definition of technical specifications to their going live is shortened from several years to one or a few months. That alone is a big win, which enables much more degrees of freedom in IT support for the specialist departments of a company. If you look closely, the agile software development according to Scrum is only one of the Product Owner Controlled succession of small waterfall model projects, in which you move from level to level of software. Actually it is more agile project management than agile development in the narrow sense.
The model is optimally tailored to the independent development of its own core software, for example an online platform. It is ideal to go live as quickly as possible with an initially manageable minimal solution, and then to expand it step by step with the available staff on a monthly basis. Scrum is also very well suited for the ongoing development of finished software within the framework of a constant software maintenance budget. The customization requests are collected in the backlog and then, prioritized according to priority and feasibility, clocked into ongoing development and incorporated into one of the next versions of the software.
Combined with a modern DevOps organization, you can get your IT going. And it corresponds very well to the ongoing knowledge gained from the operation of the previous versions. At least if the costs are irrelevant, this can be the right way from a management perspective, and from the perspective of an IT service provider who sells person days. SCRUM projects that are paid according to expenditure are particularly advantageous for the contractor because they are risk-free and easy to plan.
However, when it comes to the new development of a complex software solution, possibly as a fixed price project in a client-contractor relationship, things are different. No one needs a functional but overly rudimentary program version every month that is not yet usable. The monthly cycle also stands in the way of processing more extensive work packages.
Since it cannot be clearly assigned whether the product owner should be a representative of the specialist department, the IT department, the client or the contractor, because neither fits perfectly into the real world, experience with externally assigned agile development projects is very mixed. If you know exactly what you want and want an optimal and timely implementation, then the waterfall model would actually be ideal – if it weren’t for the well-known problems of excessive formalism and insufficient topicality, and above all the silent post phenomenon, which affects user requirements partly grotesquely distorted on the long paper path, so that sometimes the development actually ignores the need.
The question is whether and how you can transfer the sensible basic approach “think first, then act” into the agile world of low-code software development. Iterative prototyping alone, as stipulated in the V-Modell-XT of the public administration, is definitely not enough for this. Rather, what is crucial for an improved waterfall model is to communicate the user requirements to the developers much more directly and quickly, ideally in direct dialogue. But this contradicts the basic structure of classic project development with upstream concept phases – long before the programmers come into play. This is always inefficient, since the effort to write down the requirements in sufficient detail is often far higher than to implement them with a highly developed low-code platform.
For normal projects, where the specific requirements only crystallize when you can already see something on the screen, the upstream effort is more of an obstacle than an advantage, and it also unnecessarily increases the project costs. So rather agile – but how exactly?