Warum gibt es in SCRUM keine Product Discovery?

Worauf SCRUM abzielt

Das Ziel hinter SCRUM ist es, werthaltige Lösungen für Probleme in einem komplexen Umfeld hervorzubringen. Es ist ein von Softwareentwickler:innen entwickeltes Framework für die Organisation und Abläufe im Produktteam. Der Produktmanager spielt dabei eine zentrale Rolle, insbesondere in der Phase der Product Discovery.

Per Definition ist SCRUM leichtgewichtig. Das heißt, es bietet einen Rahmen – aber keine strikten Leitfäden – für iterative Arbeitsschritte, die du im Detail individuell auf dein Team anpassen kannst. Dieser Freiraum ist Absicht, führt aber häufig dazu, dass Teams denken SCRUM alleine reicht aus um wirklich Wert beim Kunden zu schaffen.

Was fehlt in SCRUM?

Um, wie von SCRUM gefordert, einen Wert zu schaffen, müssen du und dein Produktteam eure Kund:innen verstehen. Dazu braucht es ein Zusammenspiel von SCRUM und Discovery bzw. anderen Methoden. Diese Methoden sind entscheidend für einen erfolgreichen Produktentwicklungsprozess. Laut Sebastian fehlen SCRUM jedoch die konkreten Methoden, auch wenn mittlerweile etwa die Bedeutung des Produktziels und der Produktvision erwähnt werden.

Das Problem in der Anwendung liegt in der Annahme, dass ein Team nur durch die Ausbildung in SCRUM agiler wird. Der Wert für die Kund:innen kann nicht alleine mittels SCRUM entstehen, wenn durch den Fokus auf das reine Framework wichtige Methoden unbeachtet bleiben.

SCRUM in seiner reinen Form verlockt zu einer falschen Handhabung, in der sich der Fokus des Teams rein auf die Velocity beschränkt (Output) und den echten Wert beim Kunden (Outcome) vernachlässigt. Sebastian sagt dazu im Video:

„Das macht es total anfällig für Missbrauch – dass einfach SCRUM genutzt wird als reine Feature-Ballermaschine.“

Viele Features zu produzieren, ohne einen wirklichen Wert zu schaffen, ist nicht zielführend. Dies kannst du mit Discovery und einem daraus resultierenden, besseren Kundenverständnis verhindern.

Vereine SCRUM und Discovery effizient in der Produktentwicklung

Wie bindest du nun aber die Discovery in SCRUM ein? Besonders zeitlich gesehen, kann dies in der Praxis knifflig werden. Selten ist es zwingend erforderlich, dass Softwareentwickler:innen an der Arbeit im Problemraum mit den Kund:innen teilnehmen. Dabei ist es wichtig, die tatsächlichen Bedürfnisse der Nutzer zu verstehen und zu berücksichtigen. Discovery geht häufig schneller, wenn Ideen für Lösungen nicht komplett umgesetzt werden. In vielen Fällen reicht es, den Kund:innen eine Lösung erst einmal nur visuell zu präsentieren.

Zeitlich findet häufig eine Trennung zwischen Discovery und Entwicklung statt. Die Geister scheiden sich bei der Frage, wo auf dem Zeitstrahl die Discovery am besten angesiedelt ist. Es ist schwierig, in einen Sprint gleichzeitig zu discovern und umzusetzen. Deswegen wird die Discovery oft vor dem Sprint platziert.

Am Ende gibt es nicht allzu viele Wege für die tatsächliche Platzierung der Discovery. Hier findest du einige Ideen, die Sebastian und Thomas im Video ab Minute 7:00 diskutieren:

a)   Dual-Track SCRUM

Nutze zwei SCRUM-Tracks – für Discovery und Entwicklung. Diese Tracks können unterschiedliche Bereiche der Produktentwicklung abdecken, wie den Problemraum und den Lösungsraum. So kann dein Team in SCRUM entwickeln und gleichzeitig die Bedürfnisse der Kund:innen erforschen, um ein werthaltiges Produkt auf den Markt zu bringen.

b)   UX / Product Owner / Produktmanager in den Prozess integrieren

Bestimmte Aufgaben in Discovery und Entwicklung können Product Owner oder auch UXler:innen übernehmen. Dabei ist es wichtig, dass die Entwicklung und Validierung von Produktideen kontinuierlich erfolgt. Unterschiedliche Bereiche fallen unterschiedlichen Spezialist:innen leichter – dafür gibt es sie. Gleichzeitig sollten sie nicht völlig getrennt voneinander arbeiten, um effizient und effektiv zu bleiben.

c)    Finden einer Lösung ins Sprint-Ziel aufnehmen

Discovery und Entwicklung werden häufig als zwei getrennte Prozesse betrachtet. Zuerst kommt die Discovery – dann der Sprint für die Entwicklung. Du kannst jedoch auch das Finden einer Lösung für „Problem Y“ in das Sprint-Ziel integrieren. Dies stellt sicher, dass das Team das richtige Problem löst und das richtige Produkt entwickelt. So gibt es im Zeitstrahl keine Teilung zwischen Entwicklung und Discovery.

• Für großartige Produkte benötigst du im Produktmanagement mehr als das SCRUM-Framework.
• Ohne andere Methoden, wie Discovery, verleitet SCRUM zu Quantität statt Qualität.
• Sei dir der Unvollständigkeit bewusst, integriere komplementäre Methoden…

… und verbinde diese mit SCRUM.

‍