Vom Problem zur Lösung ohne Übergabe – die Dual-Track-Methode

Der DigitalService arbeitet agil und nutzerzentriert. Wir entwickeln Produkte gemeinsam mit unseren Nutzenden und passen unsere Lösungen fortlaufend an ihre Bedürfnisse an. Um auch in großen und komplexen Projekten agil zu arbeiten und früh in die Entwicklung gehen zu können, setzen wir auf die Dual-Track-Methode.

Statt zunächst alles im Detail festzulegen und anschließend umzusetzen, lernen, planen und liefern wir kontinuierlich und parallel. Im Folgenden geben wir einen Einblick in unseren Prozess und teilen unsere Erfahrungen aus der Praxis.

Dual-Track-Produktentwicklung bedeutet, dass wir unsere Arbeit in zwei parallele Arbeitsstränge aufteilen: Discovery und Delivery.

Während ein Teil eines Teams in der Discovery ein neues Themenfeld erkundet, setzt der andere Teil des Teams in der Delivery bereits erkundete Themen technisch um. In der Discovery verstehen wir durch Interviews, Workshops und Prototypen die Bedürfnisse unserer Nutzenden und entwickeln erste Lösungsideen. In der Delivery entwickeln, testen und integrieren wir neue Funktionen direkt ins Produkt.

Durch dieses parallele Vorgehen können wir technisch implementierte Features schnell mit unseren Nutzenden testen. So entsteht Software, die nicht nur funktioniert, sondern auch tatsächlich genutzt und geschätzt wird.

Im klassischen Projektmanagement verlaufen Projekte in klar definierten Phasen: Initiierung, Planung, Umsetzung und Abschluss. Die Anforderungen werden zu Beginn vollständig erhoben, danach wird eine Lösung konzipiert und anschließend ohne weitere Anpassungen umgesetzt.

Dieses Vorgehen birgt Risiken: Was, wenn sich herausstellt, dass die geplante Lösung das eigentliche Problem gar nicht löst? Oder wenn während der Umsetzung neue Anforde­run­gen auftauchen, die einen deutlich größeren Mehrwert schaffen könnten? So entstehen Software-Produkte, die an den tatsächlichen Bedürfnissen der Nutzenden vorbeigehen.

Die strikte Abfolge der Phasen bremst den gesamten Prozess: Mit der Entwicklung wird erst begonnen, wenn alle Anforderungen vollständig erhoben sind. Unsere Erfahrung zeigt, dass dadurch nicht selten mehrere Jahre vergehen, bevor die erste nutzbare Lösung entsteht.

Wir sehen in der Dual-Track-Produktentwicklung eine Alternative. Durch die Paralle­lisie­rung von Anforderungserhebung und Umsetzung wird es möglich, kontinuierlich neue Themen zu erkunden und Lösungsansätze zu erproben, ohne die laufende Entwicklung zu unterbrechen. So können wir die Bedürfnisse der Nutzenden besser verstehen, Risiken frühzeitig reduzieren und die Produktentwicklung gezielt steuern.

Das Ergebnis: Software, die tatsächlich genutzt wird, weil sie echte Probleme löst.

Unsere Entwicklungsteams sind interdisziplinär aufgestellt: Software-Entwicklung, Design, User-Research und Produktmanagement arbeiten eng zusammen. Je nach Teamgröße unterteilen wir die Teams in Teilteams, sodass parallel an mehreren Themen in der Discovery und Delivery gearbeitet wird.

Auch an einer Discovery ist typischerweise jeweils eine Person aus den Disziplinen Software-Entwicklung, Design, User-Research und Produktmanagement beteiligt. Die Rollen sind unterschiedlich eingebunden: Während Produktmanagement, User-Research und Design die Discovery aktiv vorantreiben, werden unsere Engineers einbezogen, um die technische Perspektive sicherzustellen. So wird vermieden, dass Lösungen entwickelt werden, die später technisch nicht umsetzbar sind.

Die parallele Arbeit in Discovery und Delivery erfordert vorausschauende Planung. Themen durchlaufen typischerweise zwei bis drei Monate Discovery, bevor sie in die Delivery übergehen. Das klingt nach viel Zeit, ist aber deutlich kürzer als klassische Anforderungserhebungen, die oft Jahre dauern. Und vor allem: Während ein Thema in der Discovery erkundet wird, entwickelt das Team parallel bereits andere Features weiter.

Was passiert in der Discovery? Wir führen Gespräche mit den Nutzenden, analysieren bestehende Lösungen und entwickeln verschiedene Ansätze, die wir mit Prototypen testen. Das Ziel ist nicht, schnell Anforderungen zu definieren, sondern erst zu verstehen, welches Problem wir eigentlich lösen müssen.

Mehrmals pro Woche tauschen wir uns mit unseren Projektpartnern aus, holen Feedback ein und schärfen gemeinsam die Lösungen. So bringen die Fachexpert:innen ihr Wissen direkt in die Entwicklung ein – und wir stellen sicher, dass wir die richtigen Probleme lösen. Die Erkenntnisse aus der Discovery teilen wir kontinuierlich im gesamten Team. So verstehen alle, welchen Zweck das Produkt erfüllt und welchen Mehrwert es schaffen soll. Dieses gemeinsame Verständnis ist entscheidend für die spätere Umsetzung.

Am Ende einer Discovery steht kein Hunderte von Seiten langes Lastenheft, sondern ein erprobtes Designkonzept und konkrete, priorisierte Entwicklungsaufgaben. Das Thema bleibt flexibel – Anpassungen sind auch später noch möglich. Aber durch die vorgelagerte Discovery wissen wir, dass wir uns in die richtige Richtung entwickeln.

Der entscheidende Unterschied zu klassischen Projekten: Das Team benötigt Entschei­dungskompetenz. Statt jede Weichenstellung abzustimmen, muss das Team selbstständig über die nächsten Schritte entscheiden können. Typischerweise übernimmt ein:e Product Owner diese Rolle und ist mit dem entsprechenden Mandat ausgestattet.

Unsere Erfahrung zeigt: Für die Verwaltung ist es eine echte Herausforderung, einen Teil der Planungssicherheit abzugeben. Es gibt nicht mehr die absolute Sicherheit über das genaue Ergebnis. Dafür braucht es Vertrauen und Klarheit über die Spielregeln mit Prozessen, Rollen, Eskalationsstufen und Risikomanagement.

Was man dafür bekommt: Von Anfang an entsteht ein lauffähiges, nutzbares Produkt, das früh von den Nutzenden auf seinen Mehrwert geprüft werden kann. Nicht erst nach Jahren der Planung, sondern nach Monaten der Entwicklung.