Time-struck: An entrepreneur‘s view of time-orientation in software development
André Pradtke, entrepreneur and managing director at Pradtke GmbH in Germany, shares why he is convinced that time-orientation is key to the future of software development
Just a couple of weeks ago, Time-Oriented Software Development (TOSD) entered the world of tech. It did so in a multi-faceted way, arriving as a theory, as a social technology and an applied practice used at my company – Pradtke GmbH based in Germany’s North Rhine-Westphalia region.
Time-orientation as a powerful concept isn’t new, having made its debut roughly 70 years ago at Toyota, where it was embedded in their systemic approach to work known as the Toyota Production System (TPS). Time-orientation in software development, however, actually IS new. Born in the Summer of 2025, Time-Oriented Software Development (TOSD) is bringing time-orientation to center stage in the domain of digital production, at last.
Just like industrial production did before Toyota, software development has long suffered from the dire consequences brought about by the ideology of capacity orientation. The introduction of so-called Agile methods such as Scrum has done little to avoid these consequences, as you will see below. The assumption that a certain capacity is available, and it must be maximized leads to “floating” results in terms of delivery time and product quality.
When capacity-oriented software development systems are in place, several problems occur
Here are a few examples from my experience at Pradtke and my knowledge of other software companies:
Planning horizons of even a few weeks are too long to accurately measure or estimate capacity. 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. Capacity does not necessarily have much 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 way too abstract to reliably mediate between capacity and development work.
Conception and realization of software features are typically neither distinguished nor sufficiently uncoupled. This way, each cycle of work, such as a Sprint, starts with significant causal circularities and feasibility risks. In addition, the units to be dealt with in the work cycles are often not sufficiently independent of each other to be reliably processed and delivered in one functional batch.
Lots of overhead is needed. The design and communication formats used in software development processes in Agile approaches such as Scrum – like planning, refinement, or dailies – require a lot of overhead and provide relatively little productive benefit. In the accompanying communication formats, the wrong topics are discussed in the wrong way.
The idea that methods such as Scrum, et al would lead to self-organization among teams is no more than an Agile 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 in Scrum, even if this is not the intended purpose. Decentralization is a key requirement for self-organization to function. As a result, methods such as Scrum are unable to unlock the potential for productivity, self-efficacy, and job satisfaction that lies in genuine self-organization.
In consequence, the promise of salvation that has long been attributed to these methods fails to materialize in practice. Methods like Scrum are not particularly agile on a small scale and will not foster serious agility at the corporate level either. 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.
How is TOSD different from Waterfall and Agile?
Time-orientation prevents the occurrence of these problems at a fundamental level. Time is the most potent basic structure we are aware of. 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 of development, or in the short term with reference to team availability.
Nothing in Time-Oriented Software Development takes long. At Pradtke, for example, the Realization cycle for a single item (as we call our work units) never exceeds three consecutive days. Realization is often accomplished in a single day. In conjunction with Continuous Deployment and Test-Driven Development, this generates a constant flow of new features that is immediately put to use by our customers. Such speed creates value, flow and high responsiveness.
Those in our company who realize items, in turn, get the feeling every day, or at least several times a week, that they have achieved something relevant for customers. This ongoing perception of success creates job satisfaction and motivation. It is irreplaceable.
Introducing the OK Point
In TOSD, Conceptualization and Realization are disentangled by the OK Point and are thereby linked to each other in a very smart way (see concept overview below). Once the OK Point has been reached, an item can be realized without further inquiry or approval. In specific terms, this means that those who have formulated the concept for an item and those who will realize it shake hands and agree on its Realization within one, two, or three days. Which items are ready for Realization is transparent and publicly visible within the company through a simple list that’s shared with everyone.
At Pradtke, there are some people who are authorized to conceptualize items. Others have mastery in Realization of items. Some are authorized and capable of doing both. Conceptualization and Realization are carried out either alone or in pairs. Everyone dedicated to Conceptualization and Realization is called upon to talk to to colleagues and customers the the work and seek advice if necessary. Smart Conceptualizers consciously pick apt and fitting Realizers for the items they work on, and witty Realizers get engaged with Conceptualizers and take over items at the OK Point they want to work on.
Conceptualization and Realization therefore always run in parallel – but never for a single item. This would produce oscillating loops and interrupt the flow. The river only flows in one direction.
Time-orientation & decentralization are a natural fit
In a sense, TOSD is based on the concept of decentralization. It follows the principles of the BetaCodex, which we have adopted as a company, in the shape of a decentralized Cell Structure Design, at the end of 2024. In a Cell Structure Design, highly autonomous business cells in the periphery take care of client relationships and service, but also of most of our software development. This structural arrangement results in genuine self-organization and, as we learned, in a significant increase in performance. The company has become steadily profitable, and we were able to solve plenty of business problems we had. But back to TOSD.
To conclude from the separation of Conceptualization and Realization that there might be less communication in TOSD than in other approaches to development would be mistaken. Instead, among the consequences of time-orientation is more focused and productive discourse that leads to joint success, greater social density, and more employee presence in the office.
If you would like to know more about the concept of Time-Oriented Software Development, please read the corresponding BetaCodex research paper. It is concise, entertaining, and specific.
TOSD is having several effects on Pradtke’s practice
Thanks to our collaboration with Niels Pflaeging | Red42 and the conceptual co-authorship in TOSD of our CTO Sebastian Kubsch, we at Pradtke have had the privilege of experiencing time-orientation for real for several weeks now. Even after this short period of time, the results have been noteworthy:
Our output has grown by a factor of eight, while the team’s size remained the same. Thanks to continuous deployment, this increase in speed directly benefits our customers.
Commitment and reliability. We know exactly what will happen in the next one, two, or three days. We can also see what everybody is working on. We never had such visibility around development work.
Adaptability. Every three days the latest—but usually much sooner—we can decide what to do next and why.
Future orientation. The parallelization of Conceptualization and Realization, the speed of implementation, the immediacy of effects of acting, the feeling of transparency and accountability, and 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 the experience of TOSD stimulating and enriching. Developers feel that they are “actually creating something” in a self-organized way – without being subjected to pressure or external steering.
Connectedness. Since the introduction of TOSD, we have been communicating better with each other than we did for many years. Our client needs 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 BetaCodex organization and in a system of Time-Oriented Software Development. If you are interested, just contact me or take a look at our careers page (in German) to see which kind of 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)
Download the 26th BetaCodex Network Research Paper, “Introducing Time-Oriented Software Development” - the PDF download is free of charge and free of registration
Participate in the 1st Bochum Conference on Time-Oriented Software Development on February 26, 2026, at Pradtke headquarters in Germany. This conference will be held in German language
Visit the TOSD web page. Here you will find offers for anyone who wants to learn about TOSD or who wants to bring TOSD to their own organizations
Check out the TOSD open source license: It allows you to use TOSD - even commercially, under the conditions of a Creative Commons license
 | A guest post by
|
Großartige Einsichten und Einordnungen (auch) aus deiner unternehmerischen Perspektive. Danke Dir dafür.