Was passiert wenn Theorie und Praxis aufeinander treffen könnt ihr auch hier nochmal nachlesen.
Es gibt diese Momente auf Konferenzen, da spürt man sofort: Hier reden Menschen, die wissen, wovon sie sprechen – und die sich nicht zu schade sind, auch über die eigenen Baustellen zu lachen. Genau so begann der Vortrag von Fabian (Product Owner & CEO) und Dex (Architect & Developer) auf den TYPO3 Developer Days 2025 – kurz T3DD25.
„Willkommen in unserer kleinen Selbsthilfegruppe für Anforderungsmanagement!“, begrüßte Fabian das Publikum – und schon war klar: Das hier wird kein dogmatischer Prozessvortrag und keine Ansammlung von Patentlösungen. Stattdessen: gelebtes Requirements Engineering, viele Learnings aus agiler Praxis und ein ehrlicher Blick hinter die Kulissen unserer Scrum-Teams.
Konflikte aber auch Chancen
Warum Requirements Engineering so oft aneckt
Fabian und Dex arbeiten seit über 14 Jahren zusammen – und sind seit 16 Jahren befreundet. Diese lange Zusammenarbeit prägt auch ihre Sicht auf agiles Requirements Engineering. Für sie ist es nicht einfach ein Arbeitsschritt zwischen Konzept und Umsetzung. Es ist Beziehungspflege, Kommunikation – und manchmal auch Konfliktbewältigung.
Sie stellten gleich zu Beginn klar, warum das Thema so wichtig ist: Anforderungen sind oft die größte Reibungsfläche zwischen Projektmanagement und Entwicklung. In der agilen Welt, insbesondere in Scrum, kann diese Reibung schnell sichtbar werden – und das ist nicht nur anstrengend, sondern auch eine Chance für besseren Austausch.
Ein zentrales Bild aus dem Vortrag blieb hängen: das „echte“ Projektmanagement-Dreieck. Offiziell spricht man von Zeit, Budget und Qualität. In der Realität ihres Entwicklerteams sind es eher Zeit, Geld und Nerven. Denn gute Qualität bekommt man oft auch unter Druck hin – aber nicht unbegrenzt, ohne dass es auf die Stimmung und Motivation schlägt.
Von der Theorie in die agile Praxis
Dazu kommt die Politik: Anforderungen sind selten nur fachlich. Der Kunde will ein gutes Produkt, der Product Owner möchte zufriedene Kunden und effiziente Prozesse, das Dev-Team will coole technische Lösungen, die Agentur denkt an Wirtschaftlichkeit. All das steckt in einem Ticket – und oft merkt man gar nicht, dass man gar nicht über dieselben Dinge spricht. Erst wenn alle Interessen offen auf dem Tisch liegen, kann ein sinnvoller Kompromiss entstehen.
Fabian und Dex erzählten, wie sie selbst diesen Weg gegangen sind. In ihrem Projekt „Bembel“ – dem Start ihres Frankfurter Standorts – waren sie überzeugt: Wir kennen uns gut, also funktioniert die Kommunikation schon. Tat sie nicht. Die Folge: Missverständnisse, Doppelarbeit, Frust.
Schritt für Schritt bauten sie eine Struktur auf, die sowohl im Scrum-Prozess als auch im Tagesgeschäft funktioniert: ein gemeinsames Ticket-Template in Jira, feste RE-Meetings, die Trennung zwischen Refinement (in kleinen, fokussierten Gruppen) und Estimation (im ganzen Team). Das führte nicht nur zu besseren Ergebnissen, sondern auch zu mehr Verantwortungsbewusstsein bei den Einzelnen. Besonders wertvoll: Wenn ein Experte mit jemandem arbeitet, der das Thema noch nicht kennt, entstehen oft genau die Fragen, die ein Projekt voranbringen.
Just Do It
Agil heißt auch: Pragmatismus vor Dogma
Trotz aller Struktur blieben sie realistisch: Nicht jede Anforderung muss durch den kompletten Requirements-Engineering-Prozess. Manchmal ist es effizienter, einfach loszulegen. „Wenn ich vier Stunden brauche, um ein Ticket vorzubereiten, das in einer Stunde umgesetzt ist, habe ich es wahrscheinlich übertrieben“, meinte Dex trocken.
Am Ende fassten sie ihre Haltung zusammen: Früh miteinander reden. Verantwortung teilen, statt sie weiterzuschieben. Klarheit schaffen, statt Annahmen zu treffen. Direkt kommunizieren – auch quer über Rollen hinweg. Und nicht vergessen: Humor hilft.
Das Ziel ihres Vortrags war nicht, den einen perfekten Prozess zu verkaufen. Es war zu zeigen, dass agiles Requirements Engineering ein lebendiges Zusammenspiel aus Menschen, Prozessen und Rahmenbedingungen ist. Es wird nie perfekt laufen – aber mit Offenheit, Struktur und einer Portion Gelassenheit kann man gemeinsam Großartiges schaffen.
Und offenbar kam das gut an: Mit diesem Talk haben Fabian und Dex auf der T3DD25 den zweiten Platz beim Best Speaker Award geholt – und wir freuen uns riesig über diese Wertschätzung aus der Community.
Einige witzige Reels
Vielen Dank
Ein Dank an dieser Stelle: Wir haben einige Reels unserer Kolleg:innen von tl;dv verwendet, um unsere Thesen zu verdeutlichen. Dank des unkomplizierten Austauschs und des direkten Supports konnten wir unseren Vortrag gut auflockern und für einige Lacher im Publikum sorgen. Vielen Dank an dieser Stelle und schaut gerne auch auf ihrem Instagram-Kanal vorbei. (https://www.instagram.com/tldv.io/?hl=de)
Lust, das Thema Requirements Engineering mit uns zu vertiefen?
Falls du bei der T3DD25 nicht dabei sein konntest oder den Talk verpasst hast, aber die Herausforderungen im Requirements Engineering kennst – lass uns sprechen. Wir teilen unsere Erfahrungen aus agilen Scrum-Projekten gerne, helfen bei der Optimierung von Prozessen und unterstützen dich dabei, bessere Ergebnisse für dein Team und deine Kunden zu erzielen.
➡ Jetzt Beratung zu Softwareprojekten anfragen
Es gibt diese Momente auf Konferenzen, da spürt man sofort: Hier reden Menschen, die wissen, wovon sie sprechen – und die sich nicht zu schade sind, auch über die eigenen Baustellen zu lachen. Genau so begann der Vortrag von Fabian (Product Owner & CEO) und Dex (Architect & Developer) auf den TYPO3 Developer Days 2025 – kurz T3DD25.
„Willkommen in unserer kleinen Selbsthilfegruppe für Anforderungsmanagement!“, begrüßte Fabian das Publikum – und schon war klar: Das hier wird kein dogmatischer Prozessvortrag und keine Ansammlung von Patentlösungen. Stattdessen: gelebtes Requirements Engineering, viele Learnings aus agiler Praxis und ein ehrlicher Blick hinter die Kulissen unserer Scrum-Teams.
Konflikte aber auch Chancen
Warum Requirements Engineering so oft aneckt
Fabian und Dex arbeiten seit über 14 Jahren zusammen – und sind seit 16 Jahren befreundet. Diese lange Zusammenarbeit prägt auch ihre Sicht auf agiles Requirements Engineering. Für sie ist es nicht einfach ein Arbeitsschritt zwischen Konzept und Umsetzung. Es ist Beziehungspflege, Kommunikation – und manchmal auch Konfliktbewältigung.
Sie stellten gleich zu Beginn klar, warum das Thema so wichtig ist: Anforderungen sind oft die größte Reibungsfläche zwischen Projektmanagement und Entwicklung. In der agilen Welt, insbesondere in Scrum, kann diese Reibung schnell sichtbar werden – und das ist nicht nur anstrengend, sondern auch eine Chance für besseren Austausch.
Ein zentrales Bild aus dem Vortrag blieb hängen: das „echte“ Projektmanagement-Dreieck. Offiziell spricht man von Zeit, Budget und Qualität. In der Realität ihres Entwicklerteams sind es eher Zeit, Geld und Nerven. Denn gute Qualität bekommt man oft auch unter Druck hin – aber nicht unbegrenzt, ohne dass es auf die Stimmung und Motivation schlägt.
Von der Theorie in die agile Praxis
Dazu kommt die Politik: Anforderungen sind selten nur fachlich. Der Kunde will ein gutes Produkt, der Product Owner möchte zufriedene Kunden und effiziente Prozesse, das Dev-Team will coole technische Lösungen, die Agentur denkt an Wirtschaftlichkeit. All das steckt in einem Ticket – und oft merkt man gar nicht, dass man gar nicht über dieselben Dinge spricht. Erst wenn alle Interessen offen auf dem Tisch liegen, kann ein sinnvoller Kompromiss entstehen.
Fabian und Dex erzählten, wie sie selbst diesen Weg gegangen sind. In ihrem Projekt „Bembel“ – dem Start ihres Frankfurter Standorts – waren sie überzeugt: Wir kennen uns gut, also funktioniert die Kommunikation schon. Tat sie nicht. Die Folge: Missverständnisse, Doppelarbeit, Frust.
Schritt für Schritt bauten sie eine Struktur auf, die sowohl im Scrum-Prozess als auch im Tagesgeschäft funktioniert: ein gemeinsames Ticket-Template in Jira, feste RE-Meetings, die Trennung zwischen Refinement (in kleinen, fokussierten Gruppen) und Estimation (im ganzen Team). Das führte nicht nur zu besseren Ergebnissen, sondern auch zu mehr Verantwortungsbewusstsein bei den Einzelnen. Besonders wertvoll: Wenn ein Experte mit jemandem arbeitet, der das Thema noch nicht kennt, entstehen oft genau die Fragen, die ein Projekt voranbringen.
Just Do It
Agil heißt auch: Pragmatismus vor Dogma
Trotz aller Struktur blieben sie realistisch: Nicht jede Anforderung muss durch den kompletten Requirements-Engineering-Prozess. Manchmal ist es effizienter, einfach loszulegen. „Wenn ich vier Stunden brauche, um ein Ticket vorzubereiten, das in einer Stunde umgesetzt ist, habe ich es wahrscheinlich übertrieben“, meinte Dex trocken.
Am Ende fassten sie ihre Haltung zusammen: Früh miteinander reden. Verantwortung teilen, statt sie weiterzuschieben. Klarheit schaffen, statt Annahmen zu treffen. Direkt kommunizieren – auch quer über Rollen hinweg. Und nicht vergessen: Humor hilft.
Das Ziel ihres Vortrags war nicht, den einen perfekten Prozess zu verkaufen. Es war zu zeigen, dass agiles Requirements Engineering ein lebendiges Zusammenspiel aus Menschen, Prozessen und Rahmenbedingungen ist. Es wird nie perfekt laufen – aber mit Offenheit, Struktur und einer Portion Gelassenheit kann man gemeinsam Großartiges schaffen.
Und offenbar kam das gut an: Mit diesem Talk haben Fabian und Dex auf der T3DD25 den zweiten Platz beim Best Speaker Award geholt – und wir freuen uns riesig über diese Wertschätzung aus der Community.
Einige witzige Reels
Vielen Dank
Ein Dank an dieser Stelle: Wir haben einige Reels unserer Kolleg:innen von tl;dv verwendet, um unsere Thesen zu verdeutlichen. Dank des unkomplizierten Austauschs und des direkten Supports konnten wir unseren Vortrag gut auflockern und für einige Lacher im Publikum sorgen. Vielen Dank an dieser Stelle und schaut gerne auch auf ihrem Instagram-Kanal vorbei. (https://www.instagram.com/tldv.io/?hl=de)
Lust, das Thema Requirements Engineering mit uns zu vertiefen?
Falls du bei der T3DD25 nicht dabei sein konntest oder den Talk verpasst hast, aber die Herausforderungen im Requirements Engineering kennst – lass uns sprechen. Wir teilen unsere Erfahrungen aus agilen Scrum-Projekten gerne, helfen bei der Optimierung von Prozessen und unterstützen dich dabei, bessere Ergebnisse für dein Team und deine Kunden zu erzielen.
➡ Jetzt Beratung zu Softwareprojekten anfragen
