Time-Oriented Software Development in der Praxis: Wie TOSD Softwareentwicklung neu organisiert
Wie lässt sich Softwareentwicklung so organisieren, dass nicht Auslastung, Tickets und Sprints im Mittelpunkt stehen, sondern ein verlässlicher Fluss fertiger Lösungen?
Genau darüber spreche ich in dieser Folge des agilophil Podcasts mit Niels Pflaeging. Bereits in Folge 199 haben wir die Grundlagen von Time-Oriented Software Development (TOSD) besprochen. Diesmal geht es um die Praxis: Wie ist TOSD entstanden, wie wird der Ansatz eingeführt und was verändert sich dadurch im Arbeitsalltag?
Was ist Time-Oriented Software Development?
Time-Oriented Software Development ist ein Ansatz, bei dem Zeit und Lieferfähigkeit zum zentralen Bezugspunkt der Softwareentwicklung werden.
Nicht die möglichst vollständige Auslastung vorhandener Kapazitäten steht im Vordergrund, sondern ein verlässlicher Fluss von einem Bedarf zu einer fertigen, nutzbaren Lösung.
Zentrale Elemente von TOSD sind:
- klar begrenzte Tagesportionen
- ein täglicher OK-Punkt
- die Trennung von Konzeptionierung und Realisierung
- endliche Listen statt dauerhaft wachsender Backlogs
- ein täglicher Rhythmus statt längerer Sprintzyklen
Welches Problem sollte TOSD lösen?
Der Ansatz entstand nicht aus einer theoretischen Diskussion, sondern aus einem konkreten Problem.
In einem Softwareunternehmen war die Entwicklung bereits stärker dezentral und kundennah organisiert worden. Trotzdem blieb die eigentliche Softwareentwicklung zu langsam. Es gab viele Tickets, Abstimmungen und Planungen, aber zu wenig wirklich fertige Ergebnisse.
Besonders sichtbar wurde das bei einem technischen Problem: Die bestehende Software musste modernisiert und cloudfähig gemacht werden. Ursprünglich stand dafür eine Prognose von ungefähr sieben Jahren im Raum.
Unter den neuen Arbeitsbedingungen wurde diese Aufgabe schließlich innerhalb von etwa sechs bis sieben Monatengelöst.
Das Beispiel zeigt den Kern von TOSD: Entscheidend ist nicht, wie viel Arbeit begonnen wird, sondern wie zuverlässig nutzbare Ergebnisse entstehen.
Wie entstand TOSD?
Niels verbindet in TOSD unter anderem die Konzepte von Ernst Weichselbaum zur Zeitorientierung mit Erfahrungen aus Softwareentwicklung und Organisationsdesign.
Eine entscheidende Erkenntnis war die Trennung zwischen Konzeptionierung und Realisierung.
In der Konzeptionierung wird eine Aufgabe so vorbereitet, dass daraus eine sinnvoll bearbeitbare Einheit entsteht. In der Realisierung wird daraus funktionierende Software.
Zwischen beiden liegt der OK-Punkt.
Was ist der OK-Punkt?
Der OK-Punkt ist ein verbindlicher Übergang zwischen Konzeptionierung und Realisierung.
In der Praxis findet er täglich statt. Am Morgen verständigen sich Konzeptionierende und Realisierende darauf, welche Arbeit an diesem Tag übernommen wird.
Die zentrale Frage lautet:
Welche Portion Arbeit kann heute tatsächlich vollständig realisiert werden?
Damit entsteht ein tägliches Commitment auf eine überschaubare Arbeitseinheit.
Warum arbeitet TOSD mit Tagesportionen?
Eine wichtige Lernerfahrung aus der praktischen Anwendung war: Aufgaben sollten möglichst tatsächlich innerhalb eines Tages abgeschlossen werden können.
Wenn Arbeit regelmäßig zwei oder drei Tage dauert, entstehen schnell wieder alte Muster. Aufgaben bleiben offen, Zwischenstände werden normal und der klare tägliche Rhythmus geht verloren.
„Fertig“ bedeutet deshalb nicht: „Ich habe heute daran gearbeitet.“
Fertig bedeutet: Die vereinbarte Portion wurde realisiert, getestet und ist grundsätzlich nutzbar beziehungsweise produktionsfähig.
Was verändert sich gegenüber Sprints?
TOSD arbeitet nicht mit der klassischen Sprintlogik.
Statt Arbeit für mehrere Wochen zu bündeln, entsteht ein täglicher Rhythmus:
Am Morgen gibt es den OK-Punkt. Tagesportionen werden übernommen. Im Laufe des Tages werden sie abgeschlossen. Am nächsten Arbeitstag beginnt der Ablauf erneut.
Dadurch werden Probleme schneller sichtbar und müssen nicht bis zum nächsten Review, Sprintende oder formalen Abstimmungstermin warten.
Wie wird TOSD eingeführt?
Auch die Einführung selbst folgt dem Prinzip der Zeitorientierung.
Statt eines langen Transformationsprogramms wird früh ein konkreter Go-Live-Termin festgelegt. Bei der ersten Einführung dauerte die Vorbereitung ungefähr drei bis vier Wochen. Aus späteren Erfahrungen entwickelte sich ein Vorgehen von etwa fünf Wochen.
Wichtig ist dabei ein klares Commitment der Unternehmensleitung. Gleichzeitig werden die Entwicklerinnen und Entwickler aktiv einbezogen. Ihre Fragen und praktischen Erfahrungen helfen dabei, offene Punkte im System zu klären.
Lernen ohne klassische Schulungen
Niels verzichtet bewusst auf klassische Trainings- und Zertifizierungsmodelle.
Stattdessen beschreibt er verschiedene Lernformate: Impuls-Sessions, offene Tandemgespräche und gemeinsame Comenius-Lernsessions in kleinen Gruppen.
Das Ziel ist nicht, ein Framework auswendig zu lernen. Die Beteiligten sollen verstehen, wie das System funktioniert und welche Konsequenzen es für ihre tägliche Arbeit hat.
Was passiert nach dem Go-Live?
Beim ersten praktischen Einsatz arbeiteten die Entwicklerinnen und Entwickler zunächst eng zusammen.
Am Morgen fand der OK-Punkt statt. Realisierende übernahmen konkrete Items – allein oder beispielsweise im Pair Programming. Im Laufe des Tages sollten diese Portionen vollständig abgeschlossen werden.
Am nächsten Arbeitstag begann der Rhythmus erneut.
Eine wichtige Rolle spielte dabei die direkte Kommunikation: Fragen und Probleme sollen möglichst sofort geklärt werden, statt auf spätere Meetings oder formale Prozessschritte zu warten.
Was ist die zentrale Idee hinter TOSD?
Time-Oriented Software Development verschiebt den Fokus.
Nicht maximale Auslastung steht im Mittelpunkt.
Nicht die Menge begonnener Arbeit.
Und auch nicht die Frage, wie viele Tickets in einen Sprint passen.
Entscheidend ist ein verlässlicher Fluss von einem konkreten Bedarf zu einer fertigen Lösung.
Damit verändert sich die zentrale Frage der Softwareentwicklung von:
„Wie nutzen wir unsere vorhandene Kapazität optimal aus?“
zu:
„Wie schaffen wir kontinuierlich nutzbare Ergebnisse?“
Fazit
TOSD stellt einige verbreitete Annahmen über Softwareentwicklung infrage.
Statt Kapazitätsplanung rückt Lieferfähigkeit in den Mittelpunkt. Statt langer Arbeitszyklen gibt es Tagesportionen. Statt dauerhaft wachsender Arbeitsbestände soll die Arbeit überschaubar bleiben. Und statt Probleme in Meetingzyklen zu verschieben, wird direkte Kommunikation Teil des täglichen Arbeitsflusses.
Das Interview mit Niels Pfläging zeigt damit vor allem eines: Veränderungen in der Softwareentwicklung entstehen nicht durch neue Begriffe oder zusätzliche Meetings, sondern durch ein bewusst gestaltetes Arbeitssystem.
Weiterführende Quellen
Wenn Du die Grundlagen von Time-Oriented Software Development vertiefen möchtest, empfehle ich Folge 199 des agilophil Podcasts mit Niels Pflaeging. Dort sprechen wir ausführlich über Tagesportionen, endliche Listen, List Owner und die grundlegende Logik der Zeitorientierung.
Im Gespräch verweist Niels außerdem auf das gemeinsam mit Sebastian Kupsch entwickelte White Paper zu Time-Oriented Software Development.
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
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.
