TOSD – Softwareentwicklung neu gedacht: Zeitorientierung statt Kapazitätsplanung mit Niels Pfläging
Warum brauchen wir nach Scrum, Kanban und Lean noch einen neuen Ansatz?
Scrum, Kanban, SAFe, DevOps und andere Ansätze prägen die Softwareentwicklung seit vielen Jahren. Sie haben Prozesse verändert, neue Rollen geschaffen und den Blick auf Zusammenarbeit und iterative Entwicklung geschärft. Trotzdem bleibt in vielen Organisationen ein bekanntes Problem bestehen: Softwareentwicklung dauert lange, Backlogs wachsen, Prioritäten ändern sich ständig und trotz aufwendiger Planung ist häufig unklar, wann etwas tatsächlich fertig wird.
Genau an diesem Punkt setzt Time-Oriented Software Development, kurz TOSD, an.
In dieser Folge des agilophil Podcasts spreche ich mit Niels Pfläging, Organisationsdenker, Autor und gemeinsam mit Sebastian Kutsch Entwickler von TOSD. Mit Niels habe ich bereits in den Folgen 64 und 65 über Organisationsgestaltung, Zellstrukturdesign und Komplexität gesprochen. Dieses Mal geht es um eine ziemlich grundsätzliche Frage: Was passiert, wenn wir Softwareentwicklung nicht mehr an Kapazitäten, sondern konsequent an Zeit ausrichten?
Zeitorientierung ist mehr als eine Timebox
Wer Scrum kennt, könnte zunächst einwenden: Zeitorientierung gibt es doch längst. Schließlich arbeiten Scrum-Teams in zeitlich begrenzten Sprints.
Niels widerspricht genau an diesem Punkt.
Für ihn sind Sprints weiterhin Ausdruck einer Kapazitätsorientierung: Für einen festgelegten Zeitraum wird versucht, eine bestimmte Menge Arbeit zu erledigen. TOSD dreht diese Logik um. Nicht die verfügbare Kapazität soll bestimmen, wann etwas fertig wird. Entscheidend ist die verlässliche Zeit bis zur Fertigstellung.
Die zentrale Idee lautet deshalb: Ein Arbeitselement soll idealerweise innerhalb eines Tages vollständig fertiggestellt, getestet und ausgeliefert werden.
Niels spricht vom „Tagwerk“: Am Ende eines Arbeitstages ist ein klar abgegrenztes Stück Wertschöpfung abgeschlossen und beim Kunden beziehungsweise im produktiven System angekommen.
Von Toyota und Quick Response Manufacturing zur Softwareentwicklung
Die Idee der Zeitorientierung kommt nicht ursprünglich aus der Softwareentwicklung. Niels verweist im Gespräch unter anderem auf das Toyota Production System, auf Quick Response Manufacturing (QRM) und auf die von Ernst Weichselbaum entwickelte „schwingende Produktion“.
Gemeinsam ist diesen Ansätzen ein Perspektivwechsel: Statt Ressourcen möglichst vollständig auszulasten, soll Arbeit in einem verlässlichen Rhythmus durch das System fließen.
Das hat weitreichende Konsequenzen. Wenn die Zeit beziehungsweise der Rhythmus feststeht, muss die Kapazität bei Bedarf variieren können. Niels formuliert es so: Die Kapazität muss schwingen.
Damit stellt TOSD auch die verbreitete Vorstellung infrage, Teams müssten permanent möglichst vollständig ausgelastet sein.
Keine Backlogs, sondern endliche Listen
Besonders deutlich wird der Unterschied zu klassischen agilen Ansätzen beim Umgang mit Anforderungen.
TOSD kennt nach Niels‘ Beschreibung keinen klassischen Backlog. Stattdessen beginnt die Arbeit mit einem konkreten Business-Problem. Für dieses Problem entsteht eine eigene, begrenzte Liste von Arbeitselementen.
Der entscheidende Unterschied: Diese Liste muss sich erschöpfen.
Ein Backlog kann über Jahre wachsen und immer neue Anforderungen aufnehmen. Eine TOSD-Liste existiert dagegen nur so lange, wie das dazugehörige Problem bearbeitet wird. Ist das Problem gelöst, endet auch die Liste.
Mehrere solcher Listen können gleichzeitig existieren. Niels verwendet dafür das Bild einer „Listenwäscheleine“: Die Organisation kann nur eine begrenzte Zahl von Problemen gleichzeitig bearbeiten.
Der List-Owner ist keine neue Version des Product Owners
Auch die Verantwortung wird anders organisiert.
Jede Liste besitzt einen List-Owner. Diese Rolle ist jedoch ausdrücklich keine dauerhafte Stellenbeschreibung. List-Owner wird, wer für das konkrete Business-Problem die notwendige Könnerschaft besitzt, das Problem wirklich gelöst sehen will und die erforderliche Autorität dafür hat.
Ist die Liste abgearbeitet, endet auch die Rolle.
Damit verbindet TOSD fachliche Kompetenz, Verantwortung und Entscheidungsmacht enger miteinander. Der List-Owner soll nicht nur Anforderungen verwalten, sondern tatsächlich in der Lage sein, die Voraussetzungen zur Lösung des Problems zu schaffen – einschließlich der benötigten Kapazität.
Was bedeutet TOSD für Scrum, Kanban und agile Softwareentwicklung?
Im Gespräch wird es an dieser Stelle durchaus kontrovers. Niels vertritt die These, dass Scrum und auch Software-Kanban zentrale Denkweisen des klassischen Projektmanagements nicht wirklich überwunden haben. Schätzungen, Priorisierung, Kapazitätsplanung, Backlogs und länger laufende Arbeitspakete sind aus seiner Sicht Symptome dieses Denkens.
Ich halte im Gespräch dagegen und frage unter anderem, ob viele dieser Probleme nicht eher aus einer schlechten Umsetzung von Scrum entstehen als aus Scrum selbst.
Genau diese Reibung macht das Gespräch spannend.
TOSD muss deshalb auch nicht als weiteres Framework verstanden werden, das Scrum oder Kanban einfach ersetzt. Interessanter ist die dahinterliegende Denkfrage:
Was würde sich verändern, wenn wir Fertigstellung, Flow und Zeit zum Ausgangspunkt der Softwareentwicklung machen – statt Auslastung, Planung und Kapazität?
Gerade mit Blick auf KI wird diese Frage noch relevanter. Wenn AI Teile der Softwareentwicklung beschleunigt, können kleinere Arbeitspakete und sehr kurze Lieferzyklen leichter möglich werden. Die Herausforderung verschiebt sich dann weiter vom reinen Coding hin zur richtigen Strukturierung von Problemen und Arbeit.
Fazit
TOSD fordert dazu auf, eine tief verankerte Annahme zu hinterfragen: dass wir Arbeit planen müssen, indem wir verfügbare Menschen und Kapazitäten möglichst optimal auslasten.
Die Alternative lautet: Zeit und Flow werden fixiert – Kapazität darf sich verändern.
Ob man dieser radikalen Sicht vollständig folgt oder nicht: Der Blick auf Tagesportionen, endliche Problemlisten, klare Verantwortung und tatsächliche Fertigstellung bietet einige interessante Denkanstöße für alle, die Softwareentwicklung organisieren.
Links und Empfehlungen
Weiterführende Empfehlung: Wer sich mit den Ursprüngen der Zeitorientierung beschäftigen möchte, findet interessante Anknüpfungspunkte im Quick Response Manufacturing (QRM) von Rajan Suri sowie in den Arbeiten von Ernst Weichselbaum zur schwingenden Produktion. Und natürlich lohnt sich auch ein Blick auf TOSD selbst als Open-Source-Sozialtechnologie:
Time-Oriented Software Development (TOSD): www.timeoriented.dev
Das erste Konzeptpaper zu TOSD (Deutsch und Englisch):
https://betacodex.org/white-papers/paper/introducing-time-oriented-software-development-26
Fast-Umsonst-TOSD-Tag in Wiesbaden (17.11.2026):
https://www.redforty2.com/product-page/tosd-arbeitstag
Weitere Episoden des agilophil Podcasts findest du auf der Übersichtsseite Podcast.
Dein agilophiler Frank
Hinweis: bei diesem Text handelt es sich um eine überarbeitete Version einer KI-generierten Zusammenfassung des Transkripts der Episode.
