An alternative to Scrum for contract projects

Development on demand with Scrum

Today, we are further away than ever from a real agreement on how to proceed when developing customer-specific software solutions. This has to do with the fact that agile software development according to Scrum is actually not always and not everywhere the right way. One should always remember the background against which Scrum was invented in the 90s: as the optimal organisational form for an individual, limited development team for an owned product or online offer. If “time to market” is the most important concern, then it makes sense to bring a first version to the market or go live as soon as possible, in order to then add new, improved versions with the existing staff in comparatively short cycles. And this always continues – software maintenance for all eternity.

Unfortunately, all this does not really fit in the case of a typical contract development, or if at all, then only in the later maintenance phase. Why? In a contract development you want to get a finished software as fast as possible and as cheap as possible, which contains everything that was ordered. Intermediate deliveries are just a waste of time and money.

It is true that most clients want to see intermediate results in order to be able to bring new knowledge into the development and to be sure that you are on the right track. But having to take a fully tested but useless version every month is certainly not in the interest of the client. In a contract development, you usually have to get by on a fixed budget. Therefore, clients often prefer classic fixed-price projects. But a Scrum development is more or less a blank check for the contractor. Even if every single sprint is agreed upon as a separate fixed price: For the client, this often becomes an endless sequence of new versions with a constant flow of new versions to the budget manager.

There is almost always a lack of a competent product owner who can keep an eye on everything, who understands the entire project, who can take all the user requirements and translate them into the IT language, and who can also sensibly prioritise the infinite number of wishes. For the founder of a start-up company, this may still work for his project, but in a large organisation you will hardly find anyone who can really meet this requirement. But if there is someone between user and developer who understands the least of all involved, this approach is doomed to failure right from the start.

Many IT bosses report that Scrum projects, if they were ever finished at all, cost at least twice to three times as much and took twice to three times as long as if they had been awarded at a fixed price. For those who can afford this overhead, Scrum might be a good idea to let the product mature well in reality.

There is another reason, a technical one, which suggests that Scrum should at least be viewed critically for contract developments, because most of the business applications that are put out to tender are database applications at the core. It is in the nature of things that database applications have to be built in such a way that the underlying data model is the foundation for further development. Just as you can hardly develop a house according to Scrum by planning one room after the other and then extending the foundation by a few meters at a time, you cannot build in one feature after the other without affecting the data model and thus the entire project to such an extent. A constant rebuilding of the data model, which is typical for Scrum developments, leads to absurd additional costs and/or to a bad architecture of the application.

The phase-agile process model as an alternative

In order to solve this problem and still enable maximum agility, the Phase-Agile Process Model was developed. Here, the house is not built from left to right or from inside to outside, but in the way it is actually built: from bottom to top.

This results in an optimal process model for low-code developments, in orderly project phases of well-defined scope and content, and at the same time as agile as possible in the individual phases. How these phases look exactly may depend on the concrete parameters, the business field of the provider, and perhaps also on the concrete characteristics of the low-code platform used in each case. For database applications in a cost-conscious and time-bound project environment, a 5-phase model proves to be optimal:

1. Initialisation
2. Database
3. Programme Scope
4. Technical Modules
5. Finalisation

The time required for each of the five phases is approximately the same. Phase 1 looks at the entire project, including everything that is only in the backlog for the time being and that might be commissioned one day. Only in this way is it possible to put the basic architecture and the data model of the system on a sufficiently solid basis.

Subsequently, the foundation is planned and cast in phase 2. This means that all entities of the future overall system are already taken into account and put into the right relationships with each other, but also all interfaces to the outside world and other basic technical aspects are included. This does not mean, however, that all database tables must be given final attributes. It is rather a question of the big picture. And it’s about the question of how the future users are already involved in data modeling, when they can supposedly only think in processes but not in data structures. But far from it: You just have to know how to do it. Certainly not by discussing ER models on the blackboard with users. You have to use suitable technical means to make the data structures “alive” and understandable – ideally using real customer or realistic test data.

After that, you move on, from floor to floor, from phase to phase, and it becomes more and more agile. With all the freedom to develop the respective details further and further, this is always only possible in exactly the respective phase. Afterwards the door is closed, so to speak, and later changes are only permitted in exceptional cases.

The main work happens in phase 4, in which several Design Thinking Teams may be active at the same time. In the initial phases, computer scientists are in somewhat greater demand, while later on in the project the Citizen Developers become increasingly active, i.e. project participants who are at least as deeply involved in technical matters as in IT. How many phases a project should have depends on the software technologies used, the character of the project and many other constraints.

​The “Always-Tuesday Principle”

For low-code projects, a weekly rotation for the design-thinking workshops has proven to be optimal for the entire project duration, from the first to the last week. This is exactly the period of time after which, when working with low-code platforms, one can always provide sufficient new material for discussion, so that the meeting and doing efforts are in a reasonable relationship and the travel load of the employees of external service providers is kept within reasonable limits. Although, depending on the project phase, other people sometimes take part in the meetings, it is nevertheless useful to agree on a fixed day of the week between the contractor and the client immediately at the start of the project, such as every Tuesday, for example. This reduces the organisational effort and all those involved can plan better.

Low-code developments with the appropriate approach

It always depends on the concrete parameters which process model is most suitable for a project. While the classic waterfall model is good and correct, but actually too slow for low-code developments, the somewhat outdated Scrum concept and the phase-agile process model are two sensible alternatives.

Although the Phase-Agile Process Model is not bound to certain development methods, it is very well suited for working with rapid development tools and low-code development environments. Low-code platforms allow software development without or almost without programming, simply by interactive configuration in a kind of “Cockpit for Business Developer”. This not only gives the developers an undreamt-of development speed, it is also excellently suited to involve future users directly in the development process.

This does not mean, of course, that you necessarily have to develop on site, or that the users would permanently look over the developers’ shoulders. One possibility would be weekly workshops with discussions and immediate optimisation of current work statuses directly on the screen, and this would be done quite deliberately in direct dialogue directly between developers and users.

The principles of “Design Thinking” are recommended for conducting the work workshops of the interdisciplinary teams, and this applies to all project phases. It is very important that the project managers on both sides (contractor and client, or business and IT department) are more moderators than owners of the products and projects to be developed.

If this is successfully implemented, it opens up a lot more possibilities for the users to exert influence than would ever be possible with a Scrum-agile development. The user is much closer to the actual design processes and new ideas can be tested much faster, sometimes immediately, for their feasibility and suitability. If the budget allows, gladly with gables and turrets, otherwise rather functionally sober.

However, whether with or without specifications, whether fixed price or according to expenditure, whether with or without gables and turrets: A good and cooperative project management is always the decisive factor.

Notes:

Further information on the topic of low code can be found at https://www.scopeland.com.

Karsten Noack has published more articles in the t2informatik Blog, including

What does t2informatik actually do? One click and you'll know.