Wir entwickeln heute Software nicht mehr auf der grünen Wiese, sondern wir erweitern und verändern vorhandene Systeme. Dabei wird der Code immer komplexer und sammelt technische Schulden an. Im Entwicklungsteam ist uns das allen klar, aber wie erklären wir dem Management, dass es sinnvoll ist, frühzeitig technische Schulden abzubauen?
In diesem Vortrag berichte ich auch meiner Erfahrung aus verschiedensten Kontexten und gebe Empfehlungen, wie die Kommunikationsbarriere zwischen Management und Entwicklungsteams übersprungen werden kann. 

APIs gelten als der eine Baustein schlechthin für die Digitalisierung, aber für Entwicklungsteams sind sie oft eine Quelle der Frustration. Das liegt daran, dass beim Design und der Entwicklung vieler APIs, Protokolle wie HTTP oder Architekturstile wie REST nach Gutdünken zurechtgebogen werden, was sich negativ auf Erlernbarkeit und Developer Experience auswirkt. Nur wer die Standards gut kennt, kann bewusste statt zufällige Entscheidungen treffen, ob und wann es Sinn ergibt, vom Standard abzuweichen.

Dieser Vortrag zeigt anhand wahrer Begebenheiten, wie es nicht geht, und worauf beim API-Design und der Entwicklung geachtet werden sollte, darunter:
    • wie HTTP richtig eingesetzt wird
    • warum REST nicht immer die richtige Lösung ist
    • was bei fehlenden Tests und fehlender Dokumentation hilfreich ist
    • warum die Konsumenten der API wichtig sind
Daraus wird abgeleitet, welche Präventivmaßnahmen auf Organisationsebene helfen, Misserfolge zu vermeiden.

Wir beherrschen heute viele Methoden, um ein Produkt richtig zu bauen (z.B. TDD, DDD, CI/CD, Scrum …). Mindestens genauso wichtig ist es aber, das richtige Produkt zu bauen (Stichwort: Product Discovery). Hierbei hat das Entwicklungs-Team oft das Gefühl, am Katzentisch zu sitzen und auch nicht mit dem Product Management und Design auf Augenhöhe sprechen zu können. Ich gebe einen kurzen Abriss über die wichtigsten Discovery-Techniken, die alle in der Software-Entwicklung kennen sollten, um mitreden zu können.

Mithilfe eines der tausenden verfügbaren Online-Tutorials kann man sehr schnell ein RAG-System (Retrieval Augmented Generation) bauen. Damit aber wirklich gute Ergebnisse zu erzielen, steht - leider - auf einem ganz anderen Blatt: Denn selbst das beste LLM kann keine vernünftige Antwort generieren, wenn der Retrieval-Teil der Lösung nicht die richtigen Dokumente findet. 

In dieser Session zeigt Ihnen Sebastian Gingter, wie man den Retrieval-Teil eines RAG-Systems massiv verbessern kann - und vor allem wie man diesen Prozess strukturiert und kontrolliert begeht! Lernen Sie, die schlummernde Macht von RAG zu entfesseln und die Verbesserungen messbar zu machen, um damit zu atemberaubenden Ergebnissen zu kommen. Lassen Sie uns mit Ihren Daten reden!

Die Automatisierung von Prozessen ist entscheidend für die Agilität, Geschwindigkeit und Innovation des Business. Ein durchgängig orchestrierter Prozess integriert bestehende Systeme, menschliche Arbeit und Technologien wie KI und IoT und bildet die Grundlage für das Verständnis von Geschäftsabläufen, die Verbesserung von Prozessen und die Innovation von Geschäftsmodellen.
Die Umsetzung der Prozessorchestrierung ist jedoch mit Herausforderungen verbunden. Die Marktverwirrung in Bezug auf Technologien, die Abhängigkeit von Einzellösungen, die End-to-End-Prozesse beeinträchtigen können, sowie die Komplexität der Integration von Legacy-Systemen und die Überwindung von Unternehmenssilos tragen alle zu den Schwierigkeiten bei.
Dieser Vortrag bietet IT-Entscheidern, Architekten und Geschäftsführern eine praktische Anleitung für die Implementierung von Prozessorchestrierung auf Unternehmensebene und behandelt Anwendungsfälle, Technologien, Teamstrukturen, Rollen und Fähigkeiten.

Ein Team, ein Produkt. So sind wir mit „agil“ vor über 20 Jahren gestartet. Heute sieht die Realität häufig anders aus: Es werden mehrere Teams für die Entwicklung benötigt. 
Leider gestalten sich viele dieser Multi-Team-Entwicklungen bürokratisch träge – mit der teamübergreifenden Zusammenarbeit kam die Bürokratie: zusätzliche Abstimmungsmeetings, Artefakte und Rollen. Das liegt daran, dass die klassischen statischen Teams (z.B. geschnitten entlang der Customer Journey) nicht so radikal an der Wertschöpfung ausgerichtet sind, wie wir gerne glauben.
Der Vortrag führt in fluide Teamkonzepte abseits des Mainstreams anhand von Fallbeispielen ein: Mobile Teams, Mission Teams, Floating Teams. Neben der Mechanik werden auch die teils anspruchsvollen Voraussetzungen für die jeweiligen Teamtypen diskutiert.
Du wirst nach dem Vortrag Ideen haben, welche neuen Perspektiven auf Teams bei dir zu mehr Wumms führen können.

Key Takeaways:
•    klassische statische Teams sind nicht so stark an der Wertschöpfung ausgerichtet, wie wir glauben wollen
•    fluide Teams können das besser, haben aber anspruchsvollere Voraussetzungen
•    i.d.R. wird man verschiedene Teamtypen benötigen: statisch bis floating

Zielgruppen: Scrum Master:innen, Projektmanager:innen, Agile Coaches, Führungskräfte, Product Owner:innen, Manager:innen