Ist Scrum-Wissen als Product Owner (PO) eigentlich notwendig, um die eigene Rolle gut auszufüllen? Tim Klein und Oliver Winter erleben in ihrer Arbeit, dass hier oft Unsicherheit herrscht. Manche POs fühlen sich unter Druck, jedes Detail auswendig kennen zu müssen, andere verlassen sich stark auf Scrum Master oder Teams und verlieren dabei das Verständnis für die Grundlagen. Und gilt das auch, wenn ich mit meinem Team gar kein Scrum mache?

Klar ist, dass Product Owner die Verantwortung für den Produkterfolg tragen. Dafür braucht es nicht nur ein Gespür für Markt, Kunden und Strategie, sondern auch ein solides Fundament im Scrum-Framework. Wer nicht weiß, wie Artefakte, Events und Verantwortlichkeiten ineinandergreifen, kann kaum sicherstellen, dass das Team wirkungsvoll zusammenarbeitet. Gleichzeitig reicht reines Regelwissen nicht aus. Ein Product Owner muss die Prinzipien verstehen, um sie im Alltag an den richtigen Stellen anzuwenden.

Verständnis für die Funktionsweise von Scrum

Scrum-Wissen ist dabei kein Selbstzweck. Es geht nicht darum, im Scrum Guide jede Passage zitieren zu können, sondern um ein Verständnis dafür, wie das Framework Teams unterstützt. Eine Product Ownerin, die versteht, warum das Sprintziel Orientierung gibt, warum ein Backlog nicht nur eine Liste, sondern ein Instrument der Fokussierung ist, und wie das Inkrement Vertrauen bei Stakeholdern schafft, wird wirkungsvoller arbeiten können.

Oliver Winter und Tim Klein betonen, dass Product Owner nicht alles alleine schultern müssen. Scrum ist ein Team-Framework, und die Verantwortung verteilt sich bewusst. Doch ohne eigenes Scrum-Wissen droht die Gefahr, die Rolle zu stark auf Stakeholder-Management oder Roadmaps einzuengen. Wer dagegen die Regeln und Prinzipien kennt, kann selbstbewusst auftreten, die Zusammenarbeit mit dem Scrum Master gestalten und dem Team eine klare Richtung geben.

An Erfahrung wachsen

Ein weiterer Aspekt ist die Weiterentwicklung. Scrum-Wissen ist nichts Statisches, das man einmal lernt und dann abhakt. Mit jeder Retrospektive, jeder Review und jedem Refinement wächst die Erfahrung, wie die Prinzipien in der eigenen Organisation wirken. Gerade in komplexen Umfeldern braucht es die Bereitschaft, immer wieder Neues auszuprobieren und das eigene Verständnis von Scrum zu hinterfragen.

Am Ende geht es nicht darum, als Product Owner ein wandelndes Scrum-Lexikon zu sein. Entscheidend ist, die Grundlagen so zu verinnerlichen, dass sie Orientierung geben, ohne dogmatisch zu wirken. Wer Scrum-Wissen klug einsetzt, schafft Klarheit im Team, fördert Verantwortung und sorgt dafür, dass das Framework seinen eigentlichen Zweck erfüllt: den Raum für wirksame Produktentwicklung.

Weiterbildungsmöglichkeiten

In der Diskussion wird auf den kostenfreien Scrum Foundations Online-Kurs der Agile Academy verwiesen. Ähnliches gibt es auch als Agile Fundamentals Online-Kurs. Die Produktwerker können hier aber auch explizit den ausführlichen Product Owner Online-Kurs mit satten zwanzig Stunden Videomaterial und Übungen empfehlen.

Wie im Podcast erwähnt, bieten die Produktwerker selbst Zertifizierungstrainings (vor Ort in Köln) an. Oliver Winter ist hierbei der Trainer. Neben dem Training „Product Owner Level 1“ gibt es auch das spannende „Product Owner Level 2“ Training als wertvolle Weiterführung für alle, die schon PSPO I (von Scrum.org) oder CSPO (von der Scrum Alliance) und weitere Erfahrung als Product Owner. Beide Trainings bietet Oliver b.a.W. jeweils einmal im Quartal an – und wie erwähnt gibt es im Anschluss die Zertifizierung der Agile Academy.

Warum wir nun auch zertifizierte Trainings anbieten, erklärt sich durch diese recht aktuelle Podcast-Folge Anwendungsnahe Weiterbildung – für mehr Erfolg als Product Owner und diesen LinkedIn-Beitrag von Oliver.

Verweise auf ältere Folgen

Die aktuelle Ausgabe des Podcasts steht auch im Blog der Produktwerker bereit: „Wie viel Scrum-Wissen brauchst du als Product Owner?„.

(mdo)

Jujutsu, auf der CLI jj genannt, ist eine von Google entwickelte Alternative zu Git. Sie bricht mit vertrauten Konventionen und führt neue Konzepte ein. In dieser Podcastfolge der programmier.bar geht es darum, wie Jujutsu Merge-Konflikte zu First-Class Citizens macht, wie Versionsverwaltung ohne klassische Branches funktioniert und was hinter Features wie den sogenannten Mega-Merges steckt.

Zu Gast ist Daniel Danner, erfahrener Jujutsu-Nutzer. Er erläutert die fundamentalen Unterschiede zu Git, sowohl in der Architektur als auch in der praktischen Nutzung auf der Konsole. Außerdem zeigt er, wie Jujutsu durch seine modulare Struktur trotz radikal neuer Ansätze kompatibel zu Git bleibt und sich in bestehende Workflows integrieren lässt.

Die Hosts Jan Gregor Emge-Triebel und David Koschitzki diskutieren mit Daniel Danner auch mögliche Nachteile und Inkompatibilitäten. Etwa, wenn sich die gesamte Historie bearbeiten lässt oder Merge-Konflikte auf einmal breiter verteilt werden.

Die aktuelle Ausgabe des Podcasts steht auch im Blog der programmier.bar bereit: „Jujutsu zur Versionskontrolle mit Daniel Danner„. Fragen und Anregungen gerne per Mail oder via Mastodon, Bluesky, LinkedIn oder Instagram.

(mdo)

Ruby Central, eine Non-Profit-Organisation der Ruby-Community, hat Mitte September ohne Vorwarnung die Kontrolle über die GitHub-Repositories und einige wichtige Gems des Paket-Ökosystems RubyGems und Bundler an sich gerissen. Langjährige Maintainer sprechen von einer feindlichen Übernahme („hostile takeover“) und sind teils aus Protest zurückgetreten.

Ruby Central rechtfertigt das Vorgehen mit der Notwendigkeit, die Supply-Chain-Sicherheit im Ruby-Ökosystem zu stärken. Hinter den Kulissen spielen jedoch Finanzierungsprobleme und der Einfluss des Unternehmens Shopify (ein bedeutender Ruby-Sponsor) eine große Rolle. Der Vorfall wirft grundlegende Fragen zur Governance von Open-Source-Projekten auf: Wer besitzt Community-Code, und wie viel Einfluss dürfen Geldgeber auf Open-Source-Infrastruktur nehmen?

Ruby Central, RubyGems und Bundler – wer ist wer?

RubyGems (abgekürzt Gems) ist das offizielle Paketsystem für die Programmiersprache Ruby. Über das zentrale Verzeichnis RubyGems.org werden Gems publiziert und installiert. Bundler wiederum ist ein in Ruby integriertes Abhängigkeitsmanagement-Tool, das sicherstellt, dass in einem Projekt alle benötigten Gems in den richtigen Versionen verfügbar sind. Betrieben wird RubyGems.org seit jeher von Ruby Central, einer gemeinnützigen Organisation, die die jährlichen Ruby-Konferenzen (z.B. RubyConf und RailsConf) ausrichtet und sich um wichtige Community-Infrastruktur kümmert.

Ruby Central finanzierte in der Vergangenheit auch Entwickler, die an RubyGems und Bundler arbeiten, hatte aber formal keine Eigentumsrechte an deren Quelltext. Vielmehr wurden RubyGems und Bundler als Open-Source-Projekte von Community-Maintainern über Jahre hinweg gepflegt und weiterentwickelt.

David Heinemeier Hansson (DHH) ist in diesem Kontext eine prominente Figur: Als Schöpfer des Web-Frameworks Ruby on Rails und Mitgründer der Firma Basecamp genießt er einerseits Kultstatus, andererseits eckt er mit umstrittenen politischen Aussagen zunehmend an. In der Ruby-Community gab es zuletzt Empörung über Blogposts von Hansson, in denen er z.B. beklagte, London sei „nicht mehr voll von einheimischen Briten“, und Sympathie für den rechten Aktivisten Tommy Robinson zeigte. Solche Äußerungen bezeichneten Community-Mitglieder als „toxisch“ und forderten eine neue Führungsstruktur für Rails oder einen Fork. Hanssons polarisierendes Auftreten hat dazu geführt, dass seine Teilnahme an Community-Events – wie der letzten RailsConf in Philadelphia – kontrovers diskutiert wird.

Shopify, ein kanadischer E-Commerce-Gigant, ist einer der größten Nutzer von Ruby on Rails. Das Unternehmen beschäftigt zahlreiche Rails-Entwickler und investiert viel in das Ruby-Ökosystem. Shopify-CEO Tobias Lütke ist zugleich ein Unterstützer von DHH (Hansson sitzt sogar im Aufsichtsrat von Shopify). In den letzten Jahren hat Shopify zu den Hauptsponsoren von Ruby Central gezählt und somit erheblichen Einfluss – sowohl finanziell als auch personell (einige Ruby-Central-Vorstandsmitglieder sind Shopify-Mitarbeiter).

Finanzierungskrise: DHH-Kontroverse führt zu Sponsorenverlust

Die Wurzeln der aktuellen Krise liegen zum Teil in einem Finanzierungsengpass. Ruby Central verlor Anfang 2025 mit Sidekiq (ein in der Ruby-Welt verbreitetes Hintergrundjob-Framework) einen wichtigen Sponsor (250.000 US-Dollar im Jahr), nachdem DHH als Redner für die RailsConf 2025 eingeladen worden war (es war übrigens die finale RailsConf). Mike Perham von Sidekiq störte sich daran, dass Ruby Central Hansson trotz seiner umstrittenen Ansichten eine Bühne bot. Dieser Wegfall riss ein großes Loch ins Budget – Ruby Central war damit praktisch finanziell auf Shopify angewiesen.

Shopify wiederum soll die Gunst der Stunde genutzt haben, um Bedingungen zu stellen. Laut einzelnen, aber nicht belegten, Berichten aus der Community habe Shopify ein Ultimatum formuliert: Ruby Central solle bis zu einer bestimmten Frist die vollständige Kontrolle über RubyGems erlangen – sowohl über die Code-Repositories auf GitHub als auch über essenzielle Gems (namentlich die Projekte rubygems und bundler sowie die Gems bundler und rubygems-update) – andernfalls würde Shopify seine Förderung einstellen. Diese Forderung wurde mit Hinweis auf die Supply-Chain-Security begründet, war aber gleichzeitig eindeutig an die weitere finanzielle Unterstützung geknüpft – ein „klar umrissener Ultimatum-Deal“.

Dabei muss man wissen, dass eine solche Forderung von Shopify gut gemeint sein könnte. Es gibt nicht viele Firmen, die so auf ein funktionierendes Ruby-Ökosystem angewiesen sind wie Shopify. Aber gut gemeint ist nicht immer auch gut gemacht.

Ruby Central geriet dadurch massiv unter Druck. Intern war offenbar klar: Sollte man Shopifys Forderung ignorieren, stünde die Existenz der Organisation auf dem Spiel. Freedom Dumlao, Mitglied des Ruby-Central-Vorstands, brachte es später so auf den Punkt: Hätte er gegen die Übernahme gestimmt, hätte er damit faktisch „den Prozess eingeleitet, Ruby Central dichtzumachen“. Die Vorstandsmehrheit entschied sich also – trotz aller Bedenken – für das Befolgen von Shopifys Bedingungen, um die finanzielle Zukunft und den Betrieb von RubyGems.org nicht zu gefährden.

Ablauf der Übernahme: Von null Kommunikation zum Komplett-Reset

In der zweiten Septemberwoche 2025 setzten Verantwortliche bei Ruby Central den Plan abrupt in die Tat um. Ohne vorherige Ankündigung oder Absprache mit den bisherigen Maintainer-Teams nahmen sie innerhalb weniger Tage drastische Änderungen vor:

• 9. September 2025: Ein RubyGems-Maintainer (Hiroshi SHIBATA, GitHub-Alias HSBT) benannte die GitHub-Organisation „RubyGems“ eigenmächtig in „Ruby Central“ um, fügte Ruby-Central-Direktor Marty Haught als neuen Owner hinzu und entzog allen anderen Maintainern ihre Admin-Rechte. Als verblüffte Community-Mitglieder Protest einlegten, weigerte sich HSBT zunächst, diese Änderungen rückgängig zu machen – er behauptete, dafür erst Martys Erlaubnis zu benötigen.
• 15. September 2025: Nach mehreren Tagen Unruhe erklärte Marty Haught gegenüber dem RubyGems-Team, die vorigen Rechteänderungen seien ein „Fehler“ gewesen und „hätten niemals passieren dürfen“. Daraufhin stellte HSBT einen Teil der alten Berechtigungen wieder her. Allerdings blieb Marty selbst als Owner der GitHub-Orga eingetragen – obwohl das Maintainer-Team ihm dieses Recht nie eingeräumt hatte. Die Community-Maintainer nutzten die Atempause und begannen sofort mit der Ausarbeitung einer formellen Governance-Richtlinie für RubyGems, um künftige Kompetenzstreitigkeiten zu vermeiden. (Diese orientierte sich am Vorbild des Paketmanagers Homebrew, der solche Strukturen bereits etabliert hat.)
• 18. September 2025: Ohne weitere Erklärung machte Marty Haught den Schritt, alle verbliebenen Admin-Mitglieder der GitHub-Organisation in den Teams RubyGems, Bundler und RubyGems.org zu entfernen. Praktisch über Nacht verloren damit sämtliche langjährigen Maintainer den Zugriff auf ihre Projekte. Am selben Tag deaktivierte Ruby Central zudem die Berechtigungen dieser Personen auf der RubyGems-Hosting-Plattform selbst – konkret wurden die Gems bundler und rubygems-update auf RubyGems.org unter die Kontrolle von Ruby Central gestellt. Durch diesen Schritt waren die bisherigen Maintainer vollkommen entmachtet, und das RubyGems-Ökosystem lag nun in den Händen von Ruby Central (bzw. deren Mitarbeitern).

Ellen Dash, seit über zehn Jahren Maintainerin von RubyGems, kommentierte die Vorgänge unumwunden: „Das war eine feindliche Übernahme“. Die „gewaltsame Entfernung derjenigen, die RubyGems und Bundler über ein Jahrzehnt gepflegt haben“, könne gar nicht anders bezeichnet werden. Dash trat kurz darauf von ihrer Rolle bei Ruby Central zurück. Sie hatte die Ereignisse, beginnend beim 9. September, in einem ausführlichen PDF-Bericht mit dem Titel „Ruby Central’s Attack on RubyGems“ öffentlich gemacht.

Auch andere Maintainer und Community-Mitglieder reagierten schockiert. Die plötzliche Machtübernahme war ohne jede Vorwarnung oder Community-Konsultation erfolgt. Mehrere der Entfernten betonten, Ruby Central habe hier Projekte an sich gerissen, die der Organisation gar nicht gehörten – der Code von RubyGems, Bundler und der RubyGems.org-Webanwendung sei Gemeingut der Community, nicht Eigentum von Ruby Central.

Selbst Ruby-Central-nahe Personen räumten ein, dass Marty Haught und der Vorstand wussten, dass man kein Recht auf diese Repositories hatte. Marty soll dem Vorstand in einer Sitzung am 17. September sogar alternativ eine Abspaltung (Fork) der betreffenden Codebases vorgeschlagen und vor den absehbaren Folgen einer erzwungenen Übernahme gewarnt haben. Dennoch fiel die Entscheidung zugunsten des harten Durchgreifens.