TIME-ORIENTED SOFTWARE-DEVELOPMENT WHY, HOW, SO WHAT

I published this article in German on October 27. Since I have been asked to do so several times, here is the English version. If you would prefer to read this article in English, you can find it here.

This week, Time-Oriented Software Development (TOSD) is entering the world.

It is doing so in the form of an “impulsive multiple jump”. Time-oriented software development is a new social technology that makes the primacy of time orientation, which has already made revolutionary contributions in other contexts—such as industrial production—usable for digital production systems. TOSD was developed by Niels Pflaeging, Founder of Red42, and Sebastian Kubsch, CTO at Pradtke.

The problem with “agile methods”.

Software development has always suffered from the phenomenon of capacity orientation and its consequences. This is true even when using agile methods such as Scrum. The assumption that a certain capacity is available, the use or benefit of which must be maximized, leads to “floating” results for several reasons in terms of when certain increments are completed and what state they are then in.

To name just a few examples from my experience at Pradtke and from my knowledge of other software companies:

• Planning horizons of even a few weeks are too long to measure or estimate capacity accurately. Quite apart from the fact that it is probably more intelligent not to measure or estimate capacity, but rather to influence and develop it in terms of the ability to process tasks. This, then, does not necessarily have anything to do with the number of people in the team or the hours available. Concepts such as story points are also very demanding and often too abstract to reliably mediate between capacity and content-related work.
• Conception and realization of software features are typically not distinguished and uncoupled, so that each cycle, such as a sprint, starts with relevant causal circularities and feasibility risks. In addition, the units to be dealt with in the cycles are often not sufficiently independent of each other to be finally processed and delivered as a functional unit.
• The design and communication formats used in software development processes that rely on Scrum, for example, such as planning, refinement, or daily, produce a lot of overhead and comparatively little productive benefit. The wrong topics are discussed in the wrong way.
• The idea that agile methods such as Scrum per se would lead to real self-organization in teams is a real myth. For me, this is not even mainly due to the fact that they are often added to classic command-and-control systems as a management fad. The reason for this lies in the methods themselves, which favor forms of centralization around certain roles such as the product owner (even if this may not be the conceptually intended purpose). However, decentralization is a key requirement for self-organization to function. As a result, methods such as Scrum are often unable to unlock the potential for productivity, self-efficacy, and job satisfaction that lies in genuine self-organization.

As a result, the promise of salvation that has long been attributed to these methods often fails to materialize in concrete experience. They are not particularly agile on a small scale and do not have the same effect at the corporate level. They do not promote decentralization and self-organization, but rather establish other forms of centralization and control. They often fail to significantly increase productivity, quality, and reliability. Instead of self-efficacy and the joy of success, often a feeling of powerlessness and frustration arises.

Why and how does time-oriented software development make a productive difference? And what kind of difference?

Time-oriented software development reverses certain of these characteristics at a fundamental level – and thus also their consequences. Time is the most potent basic structure we know. That is why time, and not capacity, is fixed in time-oriented software development. Capacity fluctuates, for example, in the medium term along with demand development or in the short term with reference to team availability.

Nothing in time-oriented software development takes long. At Pradtke, for example, the implementation cycle for an item (as we call our work units) never exceeds three consecutive days. Often it is only one day. In conjunction with continuous deployment, this generates a constant flow of new features that are immediately put to use by our customers. This creates value, flow and responsiveness.

Those who implement items for us, in turn, have the feeling every day, or at least several times a week, that they have achieved something relevant for customers. This ongoing success creates job satisfaction and motivation.

In Time-Oriented Software Development, conception and implementation are disentangled by the so-called “OK point” – and are thus cleverly linked to each other: Once this point has been reached, an item can be implemented “without further consultation.” In concrete terms, this means that those who have formulated a concept for an item and those who implement it shake hands and agree on its implementation in one, two, or three days. Which items are ready for implementation can be seen transparently and publicly within the company in a simple list.

At Pradtke, there are people who are authorized to design. Others are able to implement. Some are allowed and able to do both. Design and implementation are carried out either alone or in pairs. But of course, you can and should talk to colleagues and customers about it and seek advice if necessary. Smart designers consciously select the implementers, and implementers make a conscious agreement with the designers at the OK point.

Implementation and execution therefore always run in parallel – but not for a single item. This would produce oscillating loops and interrupt the flow.

Time-Oriented Software Development is therefore decentralized and follows the principles of the BetaCodex, which we have also adopted as a company as a whole. This results in genuine self-organization and a real increase in performance.

Anyone who concludes from the separation of conception and implementation that there would be less communication is mistaken. The consequences are more focused and productive discussions that lead to joint success, greater social density, and more presence in the office.

If you would like to know more about the concept of time-oriented software development, please refer to the corresponding research paper. It is concise, entertaining, and specific.

What effect is Time-Oriented Software Development having on  Pradtke’s practice?

Thanks to our collaboration with Red42 and the conceptual co-authorship of our CTO Sebastian Kubsch, we at Pradtke have had the privilege of experiencing Time-Oriented Software Development in real life for several weeks now. Even after this short time, the results have been astonishing:

• A Our output has already grown by a factor of eight. With the same team size. Thanks to continuous deployment, this increase in speed also directly benefits our customers.
• Commitment and reliability. We know exactly what will happen in the next one, two, or three days.
• Every three days at the latest—but usually much sooner—we can decide what to do next and why.
• Future orientation. The parallelization of conception and realization, the speed of implementation, the immediacy of the effect, the feeling of transparency and controllability, and the time orientation itself create an unprecedented focus on innovation. Because we know that when we do something new for our customers, it will be out in the world within days.
• The Pradtke team finds time-oriented software development motivating and enriching. We feel that we are “really creating something” in a self-organized way – without being subjected to control pressures.
• Since the introduction of time-oriented software development, we have been communicating better with each other than we have for many years. Our customers and our software are once again at the center of our attention.
• Desirability: In recruiting, we notice that people are eager to work in a beta organization and in the context of time-oriented software development (and if you are interested, just contact me or take a look at Careers (in German) to see which profiles we are currently looking for).

At Pradtke GmbH, we can look back on more than 30 years of experience and growth in software development. During this time, we have become the market leader for personnel scheduling or rostering software in hospitals, fire departments, and other areas of public services with a strong product and excellent services.

But we are even more interested in looking ahead than looking back. That is why the introduction of time-oriented software development following our beta transformation, the introduction of cell structure design, and the modernization of our business model with TIMEOFFICE Complete is another step we are taking in collaboration with Red42. For new and „real“ agility that makes a difference for our customers and ourselves.

More about Time-Oriented Software Development (TOSD).

TOSD web page. Here you will find offers for anyone who wants to learn about TOSD or implement TOSD in their own organization.

BetaCodex Network Research Paper on Time-Oriented Software Development.

1st Bochum Conference on Time-Oriented Software Development on February 26, 2026, at the Pradtke headquarters

TOSD open source License