Robert Károly
Scrum Master @synyx
Scrum Master @synyx
Hambrücken, Germany
Actions
As a passionate gamer and computer scientist, I’ve always been fascinated by the magic behind software. ✨
But my real _aha_ moment came when I discovered agility! 🚀
In my first role, I witnessed how a team with an agile mindset could surpass itself – almost like magic. 🪄
That experience shaped my journey:
Today:
- I empower teams,
- help organizations become future-ready,
- and address critical issues with sharp humor and honest communication. 😄
My Mission:
To break down barriers, unlock potential, and explore the dynamic clash between traditional corporate culture and startup mentality. 💡
Als leidenschaftlicher Gamer und Informatiker entdeckte ich schon früh die Magie hinter Software. ✨
Doch mein echter _Aha-Moment_ kam mit der Agilität! 🚀
Bei meiner ersten Stelle durfte ich erleben, wie ein Team mit agilem Mindset über sich hinauswuchs – fast wie Magie. 🔮
Das hat mich nachhaltig inspiriert:
Heute:
- Empower ich Teams,
- mache Organisationen fit für die Zukunft,
- und unterstütze dabei, Blockaden zu lösen und Potenziale zu entfalten. 💡
Mein Ansatz:
Ich lege den Finger in die Wunde 🩹 und spreche Klartext – immer mit einer Prise sarkastischem Humor und einem Augenzwinkern. 😉
Mein Ziel:
Die Begeisterung für Agilität wecken – auch im Spannungsfeld zwischen Mittelstandskultur und Startup-Mentalität. 🌟
Links
Area of Expertise
Topics
Von Gamern lernen – Die vergessenen Pioniere der Agilität de en
Agilität ist für viele Unternehmen noch immer ein holpriger Lernprozess – dabei haben Gamer bereits in den 90er- und 2000er-Jahren gezeigt, wie selbstorganisierte Teams unter extremem Druck funktionieren. Ob Clans in kompetitiven Spielen, Speedrunner-Communities oder Raid-Gilden in MMORPGs: Überall finden sich Prinzipien, die der modernen agilen Softwareentwicklung erstaunlich ähnlich sind.
Gamer sind Meister der schnellen Feedbackzyklen. Sie iterieren, experimentieren, passen ihre Strategien an – und das oft in Echtzeit. Sie kommunizieren effizient, verteilen Rollen dynamisch und priorisieren nach Teamzielen statt nach Hierarchien. Während Unternehmen Scrum einführen, haben Gamer längst bewiesen, dass echtes Agieren in iterativen Prozessen keine Zertifikate braucht, sondern eine Kultur des Lernens und Anpassens.
Dieser Vortrag verbindet Gaming-Anekdoten mit bewährten agilen Prinzipien und zeigt, was Software-Teams von den besten Spielern der Welt lernen können. Ein Perspektivwechsel für alle, die Agilität nicht nur als Methode, sondern als Mindset begreifen wollen.
Das Konzept von "Done" ist broken de en
Software-Teams feiern „Done“ als Erfolg – aber was bedeutet „Done“ wirklich? Ein Feature ist nicht nur dann „fertig“, wenn es im Produktivsystem läuft. Es bringt laufende Kosten mit sich: Bugs, Wartung, Abhängigkeiten, Refactoring. Wer „Done“ sagt, ohne den langfristigen Aufwand einzukalkulieren, geht eine Verpflichtung ein, die das Team über Jahre begleitet.
Der Begriff „technische Schulden“ ist dabei irreführend. Schulden kann man tilgen – aber Software ist kein Kredit, sondern eine Immobilie, die gepflegt werden muss. Ein besseres Konzept ist „technischer Unterhalt“: Wie halten wir die laufenden Kosten gering? Wie vermeiden wir es, uns mit jedem neuen Feature weiter in Wartungspflichten zu verstricken?
In diesem Talk analysieren wir, warum unser Verständnis von „Done“ problematisch ist und zeigen Wege auf, um den technischen Unterhalt niedrig zu halten – für nachhaltige Softwareentwicklung statt eines wachsenden Wartungsmonsters.
Gängige Gesetze und häufige Lügen in der Software Entwicklung de en
Softwareentwicklung folgt nicht nur technischen Prinzipien – sie folgt auch scheinbar unvermeidbaren „Gesetzen“. Murphy’s Law („Alles, was schiefgehen kann, wird schiefgehen.“) ist allseits bekannt, aber auch Conway’s Law („Die Architektur eines Systems spiegelt die Kommunikationsstrukturen des Unternehmens wider.“) oder Brook’s Law („Mehr Entwickler machen ein verspätetes Projekt noch später.“) sind Realität im Alltag von Softwareteams.
Doch nicht nur Gesetze prägen unsere Arbeit – auch bestimmte Lügen halten sich hartnäckig. „Das ist nur ein Prototyp, also muss der Code nicht sauber sein!“ – und dann läuft der „Prototyp“ zehn Jahre lang in Produktion. „Refactoring machen wir später!“ – nur um es dann nie anzupacken.
In diesem Vortrag analysieren wir, welche „Gesetze“ Entwicklerinnen wirklich kennen sollten, warum sich manche Probleme immer wiederholen und welche Konsequenzen sich daraus für eine bessere Softwareentwicklung ableiten lassen. Gleichzeitig decken wir einige der häufigsten Lügen auf und zeigen, wie Teams sich davor schützen können.
Kontrolle ist eine Illusion - Kausalität bei agilen Anti-Pattern de en
Agile Entwicklung ist voller Fallstricke – und viele davon hängen enger zusammen, als es auf den ersten Blick scheint. Anti-Pattern wie Micromanagement, Overcommitment, künstliche Deadlines oder übermäßige Prozessbürokratie sind oft nicht die eigentlichen Probleme, sondern Symptome einer tieferliegenden Ursache: der menschlichen Sehnsucht nach Sicherheit und Vorhersehbarkeit.
„Wie lange dauert das?“, „Wie können wir garantieren, dass wir liefern?“, „Wie können wir verlässliche Zusagen machen?“ – diese Fragen führen zu einem Kontrollzwang, der paradoxerweise genau das Gegenteil bewirkt: Unsicherheit, Druck und ineffiziente Strukturen.
In diesem Vortrag analysieren wir, welche Anti-Pattern besonders häufig auftreten, wie sie zusammenhängen und wie Teams sie gezielt aufbrechen können. Der Schlüssel? Ehrliches Erwartungsmanagement, bessere Kommunikation und ein realistisches Verständnis von Unsicherheiten in der Softwareentwicklung. Wer Kontrolle abgibt, gewinnt echte Agilität.
Fighting Agile! – When and Why Agility Fails en de
"Agile? _Yawn_ We tried it. Doesn’t work for us." Have you ever heard something like this before? Is "Agile" or "Scrum" already a burned-out term in your company, one that makes your colleagues run for the hills the moment you mention it?
The reasons for Agile failure are often complex. However, in my years of experience across various companies, I have identified recurring patterns—what I call agile anti-patterns.
This talk is about precisely that. Whether you want to foster agility in your company or sabotage it—this session will show you how to do it effectively.
We will explore the root causes of Agile failure, uncover what agility is truly about, and examine why it is so easy to kill. Then, we will delve into the most common anti-patterns before concluding with how Agile success is deeply tied to company culture.
Fighting Agile! - Wann und warum Agilität scheitert. en de
"Agile? *gähn* Haben wir probiert. Funktioniert bei uns nicht." Haben Sie so etwas so, oder so ähnlich, schon Mal gehört? Ist Agile oder Scrum bei Ihnen bereits ein "verbrannter Begriff", bei dem Kollegen um Sie herum das Weite suchen, wenn Sie ihn verwenden?
Die Gründe sind dabei oft vielfältig. In meiner mehrjährigen Erfahrung mit verschiedensten Unternehmen haben sich dabei jedoch einige Muster herauskristallisiert, die ich als agile Anti-Pattern bezeichnen würde.
Genau darum soll es hier gehen. Unabhängig davon, ob Sie die Agilität in ihrem Unternehmen unterstützen oder sabotieren wollen: hier lernen Sie, wie sie es effektiv anstellen können.
Wir beginnen hier dabei mit verschiedensten Ursachen für das Scheitern, schauen worum es im Kern bei Agilität geht und warum es so leicht ist sie abzuwürgen. Dann Schweifen wir über die häufigsten Anti-Pattern und schließen damit ab, was Agilität mit gelebter Unternehmenskultur zu tun hat.
Von Projekten und Produkten - Warum der Unterschied erfolgskritisch ist de en
Viele Softwareprodukte beginnen als kleine Projekte oder Proof-of-Concepts: „Können wir das überhaupt umsetzen?“ oder „Wir brauchen nur schnell ein kleines Tool für X.“ Doch aus Prototypen werden MVPs, aus MVPs werden ernsthafte Produkte – und genau hier liegt die Gefahr.
Der entscheidende Moment, an dem aus einem Projekt ein Produkt wird, wird oft übersehen. Doch Projektmanagement und Produktmanagement folgen völlig unterschiedlichen Prinzipien. Wer ein Produkt wie ein Projekt behandelt, steuert auf falsche Metriken zu, priorisiert kurzfristige Deadlines über langfristige Wartbarkeit und trifft Entscheidungen, die den Erfolg auf lange Sicht gefährden können. Qualitätsmerkmale verschieben sich, Feature-Fokus allein reicht nicht mehr – Skalierbarkeit, Wartbarkeit und strategische Planung treten in den Vordergrund.
In diesem Vortrag beleuchten wir, woran man erkennt, dass ein Projekt zum Produkt wird, welche Management- und Entwicklungsfehler dann drohen und wie Teams den Übergang erfolgreich gestalten, um nachhaltigen Produkterfolg zu sichern.
The Concept of "Done" is Broken de en
Software teams celebrate “Done” as a success—but what does “Done” really mean? A feature isn’t truly “finished” just because it’s running in production. It carries ongoing costs: bugs, maintenance, dependencies, and refactoring. Saying “Done” without accounting for the long-term effort is a commitment that will follow the team for years.
The term “technical debt” is misleading. Debt can be repaid—but software is not a loan; it’s a property that requires continuous upkeep. A better concept is “technical maintenance”: How do we keep recurring costs low? How do we avoid entangling ourselves in growing maintenance obligations with every new feature?
This talk analyzes why our understanding of “Done” is problematic and presents strategies to keep technical maintenance low—fostering sustainable software development instead of an ever-growing maintenance nightmare.
Projects vs. Products – Why the Difference is Critical to Success de en
Many software products start as small projects or proof-of-concepts: “Can we even build this?” or “We just need a quick tool for X.” But prototypes become MVPs, and MVPs turn into serious products—and this is where the danger lies.
The crucial moment when a project becomes a product is often overlooked. Yet project management and product management follow entirely different principles. Treating a product like a project leads to the wrong metrics, prioritizing short-term deadlines over long-term maintainability, and making decisions that can jeopardize success in the long run. Quality standards shift, focusing solely on features is no longer enough—scalability, maintainability, and strategic planning take center stage.
In this talk, we explore how to recognize when a project transitions into a product, the management and development pitfalls that arise, and how teams can navigate this shift successfully to ensure sustainable product success.
Learning from Gamers – The Forgotten Pioneers of Agility de en
Agility is still a bumpy learning process for many companies—yet gamers have demonstrated since the 1990s and 2000s how self-organized teams perform under extreme pressure. Whether competitive gaming clans, speedrunning communities, or MMORPG raid guilds: everywhere, we find principles strikingly similar to modern agile software development.
Gamers are masters of rapid feedback cycles. They iterate, experiment, and adapt their strategies—often in real-time. They communicate efficiently, assign roles dynamically, and prioritize team goals over hierarchy. While companies struggle to adopt Scrum, gamers have long proven that true iteration doesn’t require certifications but a culture of learning and adaptation.
This talk blends gaming anecdotes with proven agile principles, showing what software teams can learn from the best players in the world. A perspective shift for anyone who sees agility as more than just a method but as a mindset.
Control is an Illusion – Causality in Agile Anti-Patterns de en
Agile development is full of pitfalls—and many are more interconnected than they first appear. Anti-patterns like micromanagement, overcommitment, artificial deadlines, or excessive process bureaucracy are often not the root problems themselves but symptoms of a deeper issue: the human desire for security and predictability.
“How long will this take?” “How can we guarantee delivery?” “How can we make reliable commitments?”—these questions lead to a compulsion for control, which paradoxically has the opposite effect: uncertainty, pressure, and inefficient structures.
In this talk, we analyze which anti-patterns occur most frequently, how they interconnect, and how teams can break free from them. The key? Honest expectation management, better communication, and a realistic understanding of uncertainty in software development. Those who let go of control gain true agility.
Common Laws and Frequent Lies in Software Development de en
Software development does not only follow technical principles—it also adheres to seemingly inevitable “laws.” Murphy’s Law (“Anything that can go wrong will go wrong.”) is well-known, but Conway’s Law (“The architecture of a system reflects the communication structures of the company.”) and Brook’s Law (“Adding more developers to a late project makes it even later.”) also shape the daily reality of software teams.
But it’s not just laws that define our work—certain lies persist just as stubbornly. “This is just a prototype, so the code doesn’t need to be clean!”—and then the “prototype” runs in production for ten years. “We’ll do the refactoring later!”—only for it to never happen.
In this talk, we analyze which “laws” developers should truly be aware of, why certain problems keep recurring, and what lessons we can draw for better software development. At the same time, we expose some of the most common lies and show how teams can protect themselves from them.
IT-Tage
Fighting Agile!
Developer Week '23 Sessionize Event
Robert Károly
Scrum Master @synyx
Hambrücken, Germany
Links
Actions
Please note that Sessionize is not responsible for the accuracy or validity of the data provided by speakers. If you suspect this profile to be fake or spam, please let us know.
Jump to top