27. Oktober 2025 Insights ZEITORIENTIERTE SOFTWARE-ENTWICKLUNG WOZU, WIE & WIRKUNG? André PradtkeInhaber Artikel teilen Heute tritt die „Zeitorientierte Softwareentwicklung“ (Timeoriented Software Development, TOSD) in die Welt – und zwar in Form eines „impulsiven Mehrsprungs“: Mit einem dedizierten TOSD-Bereich auf der Website von Red42. Hier gibt es Angebote für alle, die sich über TOSD informieren oder TOSD bei sich konkret umsetzen wollen. Mit dem BetaCodex Network Research-Paper on Time-Oriented Software Development. Mit der 1. Bochumer Konferenz für Zeitorientierte Softwareentwicklung am 26.02.2026 bei Pradtke Mit der TOSD Open-Source-License. Worum geht’s? Zeitorientierte Software-Entwicklung ist eine neue Sozialtechnik, die das Primat der Zeitorientierung, das bereits in anderen Kontexten – bspw. der industriellen Produktion – revolutionäre Beiträge geleistet hat, für digitale Produktionssysteme nutzbar macht. Sie wurde von Niels Pfläging und Sebastian Kubsch, unserem CTO bei Pradtke, entwickelt. Worin liegt eigentlich das Problem mit den „agilen Methoden“? Die Software-Entwicklung leidet seit jeher – auch bei Anwendung agiler Methoden wie Scrum – unter dem Phänomen der Kapazitätsorientierung und dessen Konsequenzen. Die Annahme, dass eine bestimmte Kapazität vorhanden ist, deren Nutzung bzw. Nutzen es zu maximieren gilt, führt aus mehreren Gründen zu „flottierenden“ Ergebnissen dahingehend, wann bestimmte Inkremente fertiggestellt und in welchem Zustand sie dann sind. Um nur einige Beispiele aus meiner Erfahrungswelt bei Pradtke und aus der Kenntnis anderer Software-Unternehmen für diese Gründe zu nennen: Planungshorizonte von bereits einigen Wochen sind zu lang, um Kapazität gut messen oder einschätzen zu können. Ganz davon abgesehen, dass es vermutlich intelligenter ist, Kapazität nicht zu messen oder abzuschätzen, sondern im Sinne der Fähigkeit, Aufgaben abzuarbeiten, zu beeinflussen und zu entwickeln. Das wiederum hat dann nicht zwingend etwas mit der Anzahl an Personen im Team oder verfügbaren Stunden zu tun. Konzepte wie bspw. Story Points sind zudem sehr voraussetzungsvoll und regelmäßig zu abstrakt, um verlässlich zwischen Kapazität und inhaltlicher Arbeit zu vermitteln. Konzeption und Realisierung sind typischerweise nicht voneinander entkoppelt, so dass jeder Zyklus wie bspw. ein Sprint mit relevanten kausalen Zirkularitäten und Realisierbarkeitsrisiken startet. Zudem sind die Einheiten, die in den Zyklen behandelt werden sollen, oft nicht hinreichend unabhängig voneinander, um abschließend bearbeitet und als funktionale Einheit ausgeliefert werden zu können. Die Konzeptions- und Kommunikationsformate, die in Software-Entwicklungsprozessen, die z.B. auf Scrum setzen, zum Einsatz kommen, also bspw. Planning, Refinement oder Daily, produzieren viel Overhead und vergleichsweise wenig produktiven Nutzen. Es wird über die falschen Themen falsch geredet. Dass mit agilen Methoden wie Scrum per se echte Selbstorganisation in Teams eintreten würde, ist ein echter Mythos. Das begründet sich für mich übrigens in der Hauptsache nicht einmal darüber, dass sie nicht selten wie ein managementmodisches Accessoire auf klassische Command-and-Control-Systeme aufgesetzt werden. Die Ursache dafür liegt in den Methoden selbst, die Formen der Zentralisierung um bestimmte Rollen wie den Product Owner begünstigen (selbst wenn es konzeptionell so gar nicht angelegt sein mag). Zentrale Bedingung für funktionierende Selbstorganisation ist aber Dezentralisierung. Damit können Methoden wie Scrum die Produktivitäts-, Selbstwirksamkeits- und Arbeitsfreudenpotentiale, die in echter Selbstorganisation liegen, oft nicht freisetzen. In der Folge löst sich das Heilsversprechen, das diesen Methoden lange zugeschrieben wurde und wird, im konkreten Erleben oft nicht ein. Sie sind im Kleinen gar nicht besonders agil und bewirken es auch nicht auf Unternehmensebene. Sie fördern Dezentralisierung und Selbstorganisation nicht, sondern etablieren andere Formen von Zentralität und Steuerung. Sie lassen Produktivität, Qualität und Verlässlichkeit häufig nicht relevant wachsen. Statt Selbstwirksamkeit und Freude am Gelingen entsteht nicht selten das Gefühl von Ohnmacht und Frustration. Warum und wie macht Zeitorientierte Software-Entwicklung einen produktiven Unterschied? Und welchen. Zeitorientierte Software-Entwicklung invertiert bestimmte dieser Eigenschaften auf prinzipieller Ebene – und damit auch die Konsequenzen. Zeit ist die potenteste Grundstruktur, die wir kennen. Deswegen ist in der Zeitorientierten Software-Entwicklung auch die Zeit und nicht Kapazität fixiert. Die Kapazität schwingt, bspw. mittelfristig entlang der Nachfrage-Entwicklung oder kurzfristig mit Referenz auf Team-Verfügbarkeiten. Nichts in der Zeitorientierten Software-Entwicklung dauert lange. Bei Pradtke beträgt der Realisierungszyklus für ein Item (so nennen wir unsere Arbeitseinheiten) bspw. niemals mehr als drei aufeinanderfolgende Tage. Häufig ist es nur ein Tag. In Verbindung mit Continuous-Deployment erzeugt das einen konstanten Flow an neuen Features, die unmittelbar bei unseren Kunden zum Einsatz kommen. Das stiftet Nutzen und bringt Beweglichkeit. Diejenigen, die bei uns Items realisieren, haben wiederum jeden Tag oder zumindest mehrfach die Woche das Gefühl, etwas für Kunden Relevantes geschafft zu haben. Dieses andauernde Gelingen stiftet Arbeitsfreude und Motivation. Konzeption und Realisierung sind in der Zeitorientierten Software-Entwicklung durch den so genannten „OK-Punkt“ entflochten – und stehen damit zugleich in einer klug gestalteten Kopplung zueinander: Wenn dieser Punkt erreicht ist, kann ein Item „rückfragefrei“ umgesetzt werden. Ganz konkret heißt das: Diejenigen, die ein Konzept für ein Item formuliert haben und diejenigen, die es realisieren, geben sich die Hand und vereinbaren dessen Umsetzung in ein, zwei oder drei Tagen. Welche Items zur Realisierung bereit sind, lässt sich wiederum transparent und unternehmensöffentlich einer einfachen Liste entnehmen. Bei Pradtke gibt es Menschen, die autorisiert sind, zu konzipieren. Andere sind in der Lage, zu realisieren. Manche dürfen und können beides. Konzeption und Realisierung erfolgen entweder allein oder zu zweit. Aber natürlich darf und soll man mit KollegInnen und Kunden darüber reden und sich Rat holen, wenn es notwendig ist. Smarte Konzipierende suchen sich die Realisierenden bewusst aus, Realisierende treffen am OK-Punkt eine bewusste Vereinbarung mit den Konzipierenden. Realisierung und Umsetzung laufen also immer parallel – nur nicht für ein einzelnes Item. Denn das würde oszillierende Schleifen produzieren und den Flow unterbinden. Zeitorientierte Software-Entwicklung ist folglich dezentral und folgt darin den Prinzipien des Beta-Codex, den wir uns auch als Unternehmen insgesamt zu eigen gemacht haben. Daraus resultieren echte Selbstorganisation und ein echter Zuwachs an Leistungsfähigkeit. Wer aus der Entflechtung zwischen Konzeption und Realisierung nun ableitet, es würde weniger miteinander geredet, irrt. Die Konsequenzen sind mehr zugewandte und produktive Gespräche, die gemeinsam ins Gelingen führen, mehr soziale Dichte und mehr Präsenz im Büro. Wer mehr zum Konzept der Zeitorientierten Software-Entwicklung wissen möchte, sei auf das entsprechende Research-Paper verwiesen. Es ist komprimiert, kurzweilig und konkret. Was bewirkt Zeitorientierte Software-Entwicklung in der Pradtke-Praxis? Bei Pradtke haben wir aufgrund der Zusammenarbeit mit Red42 und der konzeptionellen Mitautorenschaft unseres CTO Sebastian Kubsch das Privileg, Zeitorientierte Software-Entwicklung bereits seit einigen Wochen real zu erleben. Die Resultate sind selbst nach dieser kurzen Zeit mehr als nur verblüffend: Beschleunigung. Unser Output ist – bei wohlgemerkt gleicher Teamgröße – bereits jetzt um den Faktor acht gewachsen. Dank Continuous Deployment kommt dieser Geschwindigkeitszuwachs auch direkt bei unseren Kunden an. Verbindlichkeit und Verlässlichkeit. Wir wissen genau, was in den nächsten ein, zwei oder drei Tagen passieren wird. Beweglichkeit. Wir können spätestens jeden dritten Tag – in der Regel aber deutlich früher – entscheiden, was wir aus welchen Gründen als nächstes tun. Zukunftsorientierung. Parallelisierung von Konzeption und Realisierung, die Rasanz in der Umsetzung, die Unmittelbarkeit in der Wirkung, das Gefühl von Transparenz und Beherrschbarkeit sowie die Zeitorientierung an sich erzeugen eine nie dagewesene Innovationsorientierung. Denn wir wissen: Wenn wir für unsere Kunden etwas Neues machen, wird es innerhalb von Tagen in der Welt sein. Bereicherung. Das Pradtke-Team empfindet die Zeitorientierte Software-Entwicklung als motivierend und bereichernd. Wir haben das Gefühl, selbstorganisiert „richtig was zu schaffen“ – ohne dabei Steuerungsdrücken ausgesetzt zu sein. Begegnung. Seit der Einführung der Zeitorientierten Software-Entwicklung sind wir besser miteinander im Gespräch als viele Jahre zuvor. Dabei stehen unsere Kunden und unsere Software wieder ganz im Zentrum. Begehrlichkeit: Wir merken im Recruiting, das Menschen Lust darauf haben, in einer Beta-Organisation und im Kontext der Zeitorientierten Software-Entwicklung zu arbeiten (und wenn auch Du Lust darauf hast, melde Dich einfach bei mir oder schau unter Karriere, für welche Profile wir aktuell insbesondere Zuwachs suchen). Wir bei Pradtke GmbH können auf mehr als 30 Jahre Erfahrung und Wachstum in der Software-Entwicklung zurückblicken. In dieser Zeit sind wir mit einem starken Produkt und exzellenten Services Marktführer für Personaleinsatzsoftware in Krankenhäusern, Feuerwehren und anderen Bereichen der Daseinsfürsorge geworden. Noch viel mehr als der Blick zurück interessiert und aber der Blick nach vorn. Deswegen ist die Einführung der Zeitorientierten Software-Entwicklung nach unserer Beta-Transformation, der Einführung des Zellstrukturdesigns und der Modernisierung unseres Geschäftsmodells mit TIMEOFFICE Complete ein weiterer Schritt, den wir in Zusammenarbeit mit Red42 gehen. Für neue Beweglichkeit, die für unsere Kunden uns uns selbst wirklich was bewegt.