Warum gibt es in SCRUM keine Discovery?

Dass eine gelungene Discovery entscheidend für ein erfolgreiches Produkt ist, ist mittlerweile vielen klar. Als Grundstein für ein validiertes Backlog arbeiten viele Teams die Discovery in ihren Prozess ein. Warum SCRUM das Thema Discovery nicht erwähnt, warum es aber wichtig ist mitzudenken, schauen wir uns heute an.

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.

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 schafeen.

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. 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

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. 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. 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:innen in den Prozess integrieren

Bestimmte Aufgaben in Discovery und Entwicklung können Product Owner:in oder auch UXler:innen übernehmen. 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. So gibt es im Zeitstrahl keine Teilung zwischen Entwicklung und Discovery.

Das Wichtigste in Kürze

• 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.

‍