Pradtke GmbH

Die Software-Entwicklung als Disziplin steht, methodisch wie technologisch, vor großen Herausforderungen. 

Viele Frameworks für die Organisation der Software-Entwicklung, allen voran Scrum, haben letztlich nie die Wirkung entfaltet, die sich viele erhofft haben. Darauf deuten auch die wenigen belastbaren Studien hin. 

Es ergibt sich ein „Organizational Drifting“: Prozessuale Anpassungen führen dazu, dass sich die Frage stellt, ob das, was praktiziert wird, überhaupt noch Scrum ist. 

Der Einsatz von KI-gestützter Codegenerierung wiederum verändert derzeit die Software-Entwicklung nicht nur als Disziplin, sondern auch als Job. 

Ein viel beobachtetes Phänomen: Mit KI entsteht zwar mehr Code, aber es wird nicht mehr Software ausgeliefert. 

All das haben wir auch bei Pradke in den letzten Jahren er- und durchlebt. Mit immer wieder einer Konsequenz: Uns ist weniger gelungen, als wir uns vorgenommen haben. 

Das hat uns dazu gebracht, grundsätzlich zu hinterfragen, wie wir Software-Entwicklung organisieren.

Seit Herbst 2025 haben wir, in enger Zusammenarbeit zwischen Niels Pfläging von Red42 und unserem CTO Sebastian Kubsch, Software-Entwicklung neu gedacht und neu gemacht: Mit Zeit- statt Kapazitätsorientierung, als Single-Piece-Flow-System statt im Batch-Processing. 

Die Resultate sind bereits in der Zwischenbilanz ziemlich beeindruckend: 

Im Verhältnis zur vorherigen Vorgehensweise – Scrum-ish in Verbindung mit OKR – hat sich der Output vervielfacht: Ein Entwicklungsprojekt, dessen Umsetzungszeit zuvor auf mindestens vier Jahre geschätzt wurde, haben wir in sechs Monaten realisiert. Bei gleicher Teamgröße und ohne Abstriche. Wir haben KI in unsere Arbeitsprozesse integriert, ohne mit den systemischen „Slopware“-Schattenseiten leben zu müssen. Alle bei Pradtke wissen genau, wo wir in der Entwicklung gerade stehen und welche nächsten Features wann ausgeliefert werden. Überschaubare Tagwerke erzeugen für EntwicklerInnen das Erleben von Wirksamkeit und Sicherheit. 

Das ist toll – und das ist TOSD: Timeoriented Software-Development 

Dazu haben Niels Pfläging und André Pradke bei Pure Quhr sprechen dürfen. 
 
Den Teilnehmenden gebührt unser Dank für das Interesse und die lebhafte Debatte. 

Wenn Du Lust hat, mit uns gemeinsam entlang von TOSD zu arbeiten, laden wir Dich herzlich ein, uns kennenzulernen und Dich zu bewerben!

Wie TOSD die Softwareentwicklung revolutioniert

Interview mit Sebastian Kubsch, CTO der Pradtke GmbH

Sebastian, du bist CTO der Pradtke GmbH und hast gemeinsam mit Niels Pfläging den Entwicklungsprozess TOSD »erfunden.« Was steckt hinter »Time-Oriented Software Development?«

Sebastian: TOSD ist ein radikal neuer Ansatz für Softwareentwicklung, der Zeit als zentrale Ressource betrachtet – nicht im Sinne von Deadlines, sondern als integralen Bestandteil der Zusammenarbeit, Planung und Umsetzung. Statt klassischer Projektpläne oder Sprint-Zyklen setzen wir auf konsequente Zeitorientierung, die den natürlichen Rhythmus von Arbeit, Teams und Organisationen berücksichtigt. Das führt zu mehr Klarheit, weniger Overhead und einer deutlichhöheren Anpassungsfähigkeit.

Wie kam es zur Zusammenarbeit mit Nils Pfläging und zur Entwicklung von TOSD?

Sebastian: Niels und ich haben uns im Sommer 2024 im Rahmen unserer der Beta-Transformation bei Pradtke kennen und mögen gelernt. Wir teilen die Leidenschaft für dezentrale, agile Organisationsformen. In vielen Gesprächen haben wir festgestellt, dass »klassische« Softwareprozesse – auch so genannte »agile« Formen der Softwareentwicklung – oft nicht zu modernen, dynamischen Unternehmen passen. Aus dieser Erkenntnis heraus haben wir TOSD entwickelt – als Antwort auf die Herausforderungen, die wir selbst erlebt haben. Es war ein intensiver, kreativer Prozess, der Theorie und Praxis miteinander verbunden hat.

Du bist als CTO bei Pradtke der Allererste, der jemals TOSD eingeführt hat. Wie verlief die Implementierung und was waren die größten Learnings dabei?

Sebastian: Die Einführung war ein spannender Schritt. Wir haben TOSD nicht einfach »ausgerollt«, sondern gemeinsam mit unseren Teams erarbeitet und angepasst. Das hat enorm geholfen, hohe Akzeptanz zu schaffen und zügig echte Wirkung zu erzielen. Besonders beeindruckt hat mich, wie schnell sich die Kommunikation verbessert hat – weniger Meetings, klarere Entscheidungen, mehr Fokus.

Gleichzeitig hat sich die Geschwindigkeit der Entwicklung sofort drastisch erhöht. Ein zentrales Learning war: Wenn man den Menschen vertraut und ihnen die Zeit als Gestaltungsmittel bewusst macht, entstehen großartige Ergebnisse.

Welche konkreten Vorteile hat TOSD schon jetzt für eure Kunden gebracht?

Sebastian: Unsere Kunden profitieren direkt von der höheren Reaktionsgeschwindigkeit und der besseren Qualität unserer Software. Durch die zeitbasierte Orientierung können wir schneller auf neue Anforderungen reagieren, ohne in Hektik zu verfallen. Das schafft Vertrauen und ermöglicht eine partnerschaftliche Zusammenarbeit auf Augenhöhe.

Wie geht es mit TOSD weiter – intern bei Pradtke und darüber hinaus?

Sebastian: Wir entwickeln TOSD kontinuierlich weiter, gemeinsam mit unseren Teams –wir lernen immer noch jeden Tag, jede Woche dazu. Gleichzeitig möchten wir den Ansatz auch anderen Organisationen zugänglich machen – durch konkrete Angebote, Veröffentlichungen und vielleicht sogar ein Buch. Wir haben ein Forschungspapier zu TOSD veröffentlicht, außerdem haben wir die 1. Bochumer Konferenz für Zeitorientierte Softwareentwicklung organisiert, die am 21. Mai stattfinden wird.

Gleichzeitig arbeiten wir daran, ein internationales Team rund um TOSD zu formen und mehr Teams und Organisationen für die Zeitorientierung zu gewinnen. So haben wir bereits Andreas Schlegel aus Baden-Württemberg und Ernesto Corona aus Argentinien als Mitstreiter für TOSD gewinnen können – unser Ansatz kommt noch in diesem Jahr nach Südamerika.

Es ist viel los rund um die Zeitorientierung, aber es macht auch unglaublich viel Spaß.

Was würdest du anderen CTOs oder Softwareverantwortlichen raten, die sich für TOSD interessieren?

Sebastian: Mein Rat: Denkt Zeit neu. Betrachtet sie nicht als Gegner, sondern als Verbündete. TOSD ist kein starres Framework, sondern ein Denkansatz, der zur sich an eure Realität der Wertschöpfung anpasst und viele Probleme von Steuerung, Arbeitsorganisation, Qualität und Kosten auflöst oder bearbeitbar macht.

Wer bereit ist, die übliche Illusion der Planbarkeit und Steuerbarkeit loszulassen und Entwickler:innen Vertrauen zu schenken, wird überrascht sein, wie viel Potenzial in den eigenen Entwicklungsteams steckt.

• Mehr zur Zeitorientierten Softwareentwicklung (TOSD): www.timeoriented.dev
• Tickets für die 1. Bochumer Konferenz für Zeitorientierte Softwareentwicklung: 1. Bochumer TOSD Konferenz - Pradtke GmbH

Unser Büro ist ausgezeichnet!

Unser Büro wurde vom Callwey Verlag als einer der „Best Workspaces 2026“ ausgezeichnet und in das gleichnamige Jahrbuch aufgenommen. Damit gehört unser Pradtke HQ jetzt auch offiziell zu den herausragenden Arbeitsorten des Jahres 2026. Für uns ist diese Auszeichnung weit mehr als ein Designpreis. Sie bestätigt unsere Überzeugung, dass Räume nicht Kulisse sind, sondern ein integraler Bestandteil organisationaler Wirksamkeit. Arbeitsräume prägen Verhalten, Zusammenarbeit und Kultur.

Unser Büro sieht nicht nur gut aus, sondern fühlt sich auch so an: Es gibt uns viel Raum für kollegiale Kommunikation, konstruktive Konzentration, für unsere Kunden und für Kulinarik. Denn alle, die im Büro sind, begegnen sich jeden Tag bei einem gemeinsamen Mittagstisch, zu dem wir uns selbst einladen.

Ernst Weichselbaum starb am 27. Dezember 2024, zwei Tage nach Weihnachten. Er wurde 80 Jahre alt. Der österreichische Berater, Philosoph und Pionier zeitorientierter Arbeitssysteme hinterließ ein Werk, das fast niemand in der Softwareentwicklung gelesen hat. Er hinterließ zudem den OK-Punkt – ein Konzept, das mehr als sieben Jahrzehnte nach Taiichi Ohnos ersten Experimenten bei Toyota endlich den Weg in den Bereich gefunden hat, in dem es am dringendsten benötigt wird.

In diesem Artikel geht es um die Linie, die von Toyota City in den 1950er Jahren über Wien in den 1980er Jahren bis hin zum OK Point führt, wie wir ihn heute kennen: den täglichen Austausch zwischen Konzeptentwicklern und Umsetzern im Herzen der zeitorientierten Softwareentwicklung. Es geht auch darum, warum diese Linie 70 Jahre gebraucht hat, um uns zu erreichen, und warum es wichtig ist, dass wir anerkennen, auf wessen Schultern wir stehen.

Die Entdeckung in Toyota City

Taiichi Ohno wurde 1912 in Dalian an der mandschurischen Küste geboren. Er trat als junger Ingenieur bei Toyota Spinning and Weaving ein und wechselte 1943 zur Toyota Motor Company. In den folgenden drei Jahrzehnten entwickelte er – fast im Verborgenen – das, was später als „Toyota-Produktionssystem“ bekannt werden sollte: eine Reihe von Methoden, die so radikal waren, dass westliche Führungskräfte, die Toyotas Fabriken besichtigten, jahrelang mit dem Eindruck zurückkehrten, ihnen entginge etwas. Und das tat es auch.

Das, was ihnen fehlte, war einfach zu beschreiben, aber fast unmöglich zu verinnerlichen. Ohno hatte die grundlegende Annahme der industriellen Produktion auf den Kopf gestellt. Im Westen ging man davon aus, dass die Kapazität feststeht – man hat seine Maschinen, seine Arbeiter, seine Arbeitszeiten – und die Lieferzeit schwankt um diese herum. Steigt die Nachfrage, werden die Warteschlangen länger, die Kunden warten. Sinkt die Nachfrage, stehen die Maschinen still, werden Arbeiter entlassen. Die Kapazität ist die Konstante; die Zeit ist die Variable.

Ohno tat das Gegenteil. Er legte die Zeit fest und ließ die Kapazität schwanken. Er konzipierte Toyota so, dass die Produktion mit gleichmäßigen, zuverlässigen Lieferungen – der berühmten Taktzeit – auf die Kundennachfrage reagierte und sich die Kapazität des Systems selbst anpasste, um diesen Rhythmus aufrechtzuerhalten. Wo sich die Kapazität nicht anpassen ließ, gestaltete Ohno sie so, dass sie umgestaltet werden konnte. Multifunktionale Mitarbeiter. Schnellwechselwerkzeuge. Kleine Losgrößen. Pull statt Push. Das Ergebnis war in den 1970er Jahren ein Fertigungssystem, das Autos in einer Qualität und zu Kosten produzieren konnte, mit denen westliche Autohersteller nicht mithalten konnten, ohne die zugrunde liegende Philosophie zu kopieren. Die meisten von ihnen versuchten, nur die äußeren Merkmale zu kopieren – die Kanban-Karten, die Andon-Schnüre – und scheiterten.

Ohno hat die grundlegende Erkenntnis aller Zeitorientierung erkannt: Die Welt schwingt. Die Nachfrage schwingt. Die Jahreszeiten schwingen. Die Erde schwingt. Arbeitssysteme aufzubauen, die so tun, als wäre dies nicht der Fall, bedeutet, gegen die Physik zu arbeiten. Arbeitssysteme aufzubauen, die mit der Welt schwingen, bedeutet, mit ihr zu arbeiten.

Der Philosoph, der die Fackel trug

Ohno war ein Praktiker. Er war zudem, allen Berichten zufolge, ein schwieriger Mensch – direkt, unverblümt und intolerant gegenüber der ausweichenden Sprache, die den Großteil des Managementdenkens umgibt. Er verfasste drei Bücher, von denen eines ins Englische übersetzt wurde. Er starb 1990, nachdem er miterlebt hatte, wie das Toyota-Produktionssystem weltberühmt und fast überall missverstanden wurde.

Etwa zur gleichen Zeit, als westliche Berater damit beschäftigt waren, TPS in „Lean Manufacturing“ umzuwandeln – eine freundliche, vermarktbare, etwas entschärfte Version von Ohno’s Werk –, war in Österreich ein Denker ganz anderer Art am Werk. Ernst Weichselbaum war ein Berater, der Jahrzehnte in produzierenden Unternehmen verbracht hatte, wo er mit den von Ohno entwickelten Systemen arbeitete, dabei aber andere Fragen zu ihnen stellte. Weichselbaum war ein Philosoph im älteren Sinne des Wortes: jemand, der versuchte, die Prinzipien hinter der Praxis zu verstehen, und nicht jemand, der diese Praktiken in Schulungen verpacken wollte.

Weichselbaums einzigartiger Beitrag, auf den wir bei TOSD täglich zurückgreifen, war der „OK-Punkt“. In seiner ursprünglichen Formulierung befand sich der OK-Punkt an der Schnittstelle zwischen Kunde und Lieferant. Es war der Moment der Einigung – konkret, bezeugt, oft physisch –, in dem ein Projekt von der Konzeptphase, in der die Anforderungen noch verhandelbar waren, in die Umsetzungsphase überging, in der dies nicht mehr der Fall war. Vor dem OK-Punkt konnten beide Seiten noch darüber sprechen, wie die Arbeit aussehen sollte. Danach verlagerte sich das Gespräch darauf, ob die Arbeit wie vereinbart ausgeführt wurde. Der OK-Punkt war der Moment, in dem Transparenz unvermeidlich wurde: nicht, weil jemand sie erzwang, sondern weil das Überschreiten dieses Punktes beide Parteien an dieselbe gemeinsame Definition von „fertig“ band.

Weichselbaum erkannte, was Ohno erkannt hatte – dass der Wert der Zeitorientierung nicht in der Geschwindigkeit liegt, sondern in der Disziplin, die die Zeitorientierung schafft. Doch er dehnte Ohnos Erkenntnis nach innen aus, vom Fließband hin zum Gesprächsgeschehen. Der OK-Punkt ist eine zeitliche Struktur, die in einer Beziehung zwischen zwei Parteien existiert. Das ist auch der Grund, warum sich Zeitorientierung anders anfühlt als Lean: Lean versucht, Verschwendung zu beseitigen, Zeitorientierung versucht, Rhythmus zu gestalten.

Weichselbaum widmete seine Karriere der Einführung von Zeitorientierung in Unternehmen, die noch nie von Toyota gehört hatten. Er arbeitete mit produzierenden Unternehmen zusammen, aber auch mit Organisationen im Bereich der Wissensarbeit. Er verfasste nur wenige Schriften. Das meiste, was wir über sein Denken wissen, stammt von den Menschen, die er beeinflusst hat – darunter Niels Pflaeging, der den kürzlich erschienenen Band „What would Ernst Weichselbaum do?“ herausgegeben hat und der mehr als jeder andere dafür gesorgt hat, dass Weichselbaums Name nicht in derselben Anonymität verschwindet, die so viele von Ohno’s tatsächlichen Mitarbeitern umgab.

Die 70-jährige Lücke

Hier ist die Frage, die uns beschäftigt hat, während wir TOSD aus diesem Erbe aufgebaut haben: Warum hat es 70 Jahre gedauert, bis die Zeitorientierung die Softwareentwicklung erreicht hat?

Die ehrliche Antwort lautet: Die Softwareentwicklung hat sich dagegen gewehrt. Sie hat sich aus Gründen gewehrt, die bei nüchterner Betrachtung wenig schmeichelhaft sind. Der erste und am weitesten verbreitete Grund war die Überzeugung, dass Software Kunst sei. Durch diese Einordnung in den Kunstkontext fühlte sich jeder Versuch, der Entwicklung eine zeitliche Struktur zu geben, wie ein Verstoß gegen die kreative Integrität an. Außerdem entband sie die Branche bequemerweise von der Disziplin, die andere Bereiche des Ingenieurwesens längst akzeptiert hatten. Die kapazitätsorientierte Herangehensweise mit ihren langen Planungshorizonten und ihrer Toleranz gegenüber Terminüberschreitungen passte perfekt zu einer Praxis, die im Kunstkontext verortet war. Die zeitorientierte Herangehensweise tat dies nicht.

Der zweite Grund war, dass die frühe Agile-Bewegung um das Jahr 2001 herum die eine Hälfte von Ohno’s Erkenntnis aufgriff und die andere Hälfte verwarf. Das Agile Manifest und die Methoden, die sich darum herum entwickelten – Scrum, dann Kanban, dann die Skalierungs-Frameworks – übernahmen den „Small-Batch“-Ansatz aus Lean und nannten ihn „Iteration“. Aber sie behielten die Kapazitätsorientierung als zugrunde liegenden Rahmen bei. Ein Scrum-Team hat eine feste Kapazität, ausgedrückt in Story-Points, von der angenommen wird, dass sie stabil ist. Sprints kommen und gehen; was schwankt, ist das, was in sie hineinpasst. Das ist die Wand, die mit einer anderen Farbe gestrichen wurde. Ohno hätte darin keine Zeitorientierung erkannt.

Der dritte Grund war soziologischer Natur. Zeitorientierung führt zu einer Dezentralisierung der Macht. Sie lässt sich nicht mit der dichten Schicht von Vermittlerrollen – Product Owner, Scrum Master, Agile Coaches, Projektmanager, Architekten im Titel – vereinbaren, die sich in den letzten zwei Jahrzehnten rund um die Softwareentwicklung gebildet hat. Eine ganze Branche hat sich um die Aufrechterhaltung dieser Rollen herum organisiert. Zeitorientierung bedeutet unter anderem das Verschwinden dieser Branche. Wie zu erwarten war, hat die Branche diese Entwicklung nicht gerade begeistert aufgenommen.

Der vierte und vielleicht entscheidende Grund war, dass KI die Rechnung verändert hat. Bevor KI-Assistenten ins Spiel kamen, war der Aufwand beim Tippen von Code so groß, dass die Kapazitätsorientierung vorgeben konnte, das richtige Modell zu sein. Sobald die KI den Aufwand für das Tippen auf nahezu null senkte, verlagerte sich der Engpass. Er verlagerte sich zum Denken – zur Präzision dessen, was gebaut wird, bevor es gebaut wird. Ein Bereich, in dem der Engpass die Präzision ist, ist ein Bereich, der einen OK-Punkt benötigt. Die Software hatte schließlich keinen Ort mehr, an dem sie sich verstecken konnte.

Die Übertragung auf TOSD

Im White Paper Nr. 26 beschreiben wir den „OK-Punkt“ in der Softwareentwicklung. Die Übertragung von Weichselbaums „Kunde-Lieferant-Nahtstelle“ ist nicht metaphorisch gemeint: Die Struktur ist dieselbe, nur die Parteien sind andere. In TOSD ist der „OK-Punkt“ die Nahtstelle zwischen Konzeption und Realisierung. Der Konzeptionist übernimmt die Rolle der konzeptionellen Seite; der Realisierer übernimmt die Rolle der realisierenden Seite. Der Handschlag ist ein tägliches Ritual, kein vertragliches, aber der zugrunde liegende Mechanismus – es wird eine Einigung erzielt, die Einigung wird bezeugt, die Arbeit überschreitet eine Schwelle – entspricht dem, was Weichselbaum beschrieben hat.

Wir haben auch den von Ohno entdeckten Rhythmus fast unverändert übernommen. Tägliche Portionen sind die Kadenz des Fließbandes in der Softwareentwicklung. Die Zeitbox der Realisierung (ein, zwei oder drei Tage) ist die kleine Charge. Das TTEO-Prinzip – „Talk To Each Other“ (Miteinander reden) – ist die Andon-Schnur, an der jederzeit gezogen wird, wenn etwas nicht stimmt. Das Zellstruktur-Design ist in vielerlei Hinsicht die Philosophie der vielseitig qualifizierten Arbeitskräfte, angewandt auf eine gesamte Organisation. Das sind keine Zufälle. Es sind die strukturellen Grundsätze jedes zeitorientierten Arbeitssystems, übertragen auf einen Bereich, den Ohno nie gesehen hat und den Weichselbaum sich erst zu erahnen begann.

Warum die Tradition wichtig ist

Es wäre einfach und verlockend, TOSD als etwas Neues darzustellen. Aus marketingtechnischer Sicht ist es das auch. Aus intellektueller Sicht ist es jedoch der jüngste Ausdruck eines 70-jährigen Projekts. Ich halte diese Unterscheidung aus mindestens drei Gründen für wichtig.

Erstens verschafft die Tradition jedem, der TOSD anwendet, Zugang zur umfassenderen Fachliteratur. Wenn Sie sich damit schwertun, wie die Kapazität in Ihrer Organisation schwanken sollte, müssen Sie die Antwort nicht von Grund auf neu erfinden – Ohno hat diese Frage bereits ausführlich für einen Bereich beantwortet, der schwieriger ist als der Ihre. Wenn Sie sich damit schwertun, wie sich der „OK-Punkt“ in der Praxis anfühlt, können Sie Weichselbaum lesen und seine ursprüngliche Formulierung nachschlagen. Die Menschen von diesem Erbe abzuschneiden, indem man so tut, als sei TOSD im Oktober 2025 erfunden worden, würde die Praxis verarmen lassen.

Zweitens schützt die Herkunft vor der häufigsten Fehlerquelle neuer Methoden, nämlich der stillschweigenden Wiedereinführung alter Annahmen. Die Zeitorientierung wurde sieben Jahrzehnte lang kontinuierlich abgelehnt, neu interpretiert und wieder vereinnahmt. Die Kenntnis der Geschichte hilft Ihnen, die Muster zu erkennen, wenn sie bei TOSD auftreten. Und das werden sie.

Drittens, und das ist das Wichtigste: Diese Tradition mahnt uns zur Demut. Ohno starb, bevor er erleben konnte, dass seine Arbeit richtig verstanden wurde. Weichselbaum starb, bevor er erleben konnte, dass seine Arbeit in Software Einzug hielt. Das Mindeste, was wir tun können, um diese Linie um ein weiteres Segment zu verlängern, ist, die Menschen zu nennen, deren Erkenntnisse wir in die Praxis umsetzen. Das Whitepaper Nr. 26 ist Weichselbaum gewidmet. Das Whitepaper Nr. 27 ist Ohno gewidmet. Jeder, der TOSD nutzt, hält – ob er es weiß oder nicht – diese Linie ebenfalls am Leben.

Wir hoffen, dass zukünftige Praktiker sie weiter ausbauen werden. Ich hoffe, dass jemand im Jahr 2050 auf unsere heutige Darstellung zurückblicken und sie als primitiv empfinden wird – nicht, weil sie falsch war, sondern weil sieben Jahrzehnte weiterer Arbeit sie so erscheinen lassen. So funktionieren schließlich Traditionen.

Erfahren Sie mehr über TOSD: https://timeoriented.dev