Design Thinking & Scrum

Worum es geht

Viele Teams springen direkt in die Umsetzung – sie entwickeln Features und Produkte basierend auf dem, was sie annehmen, zu wissen. Das Problem ist nur: Diese Annahmen werden selten hinterfragt oder mit echten Nutzern validiert. Das führt zu Produkten, die niemand braucht, zu langen Diskussionsschleifen und zu frustrierten Teams ohne gemeinsame Vision.

In dieser Episode geht Ralf dieser strukturellen Herausforderung mit Inga Wiele auf den Grund. Gemeinsam ergründen sie, wie Design Thinking und Scrum keine konkurrierenden, sondern sich ergänzende Ansätze sind. Sie zeigen auf, wie Teams durch eine strukturierte Problemverständnis-Phase (Design Thinking) ein klares, gemeinsames Fundament legen, auf dem die iterative Umsetzung (Scrum) dann viel erfolgreicher aufbauen kann.

Für wen?

Episoden-Insights

Design Thinking schafft Struktur für die chaotische Vorphase

Scrum ist hervorragend für die iterative Umsetzung und Lieferung von Wert. Was aber, wenn das Team noch nicht genau weiß, was überhaupt das richtige Problem ist oder welche Lösung sinnvoll ist? Hier setzt Design Thinking ein. Es bietet einen durchdachten Rahmen, um genau diese unsichere Phase zu navigieren – vom Verstehen des Nutzers und Problems über die Ideenfindung bis zum Prototyping.

"Design Thinking ist für mich einfach, wenn man das strukturiert durchführt, kommt man in allen Stationen, die für Produktentwicklung wichtig sind, einmal vorbei."

Der Fokus muss auf dem Lernen, nicht dem Beweisen liegen

Ein zentrales Risiko bei der Validierung von Annahmen ist die Bestätigungsverzerrung. Teams laufen Gefahr, nur nach Beweisen zu suchen, die ihre eigene Hypothese stützen. Die eigentliche Kunst liegt darin, mit einer neutralen, neugierigen Haltung an den Test heranzugehen. Das Ziel ist echtes Lernen und nicht der krampfhafte Versuch, die eigene ursprüngliche Idee zu retten.

"Die Gefahr ist natürlich immer, dass man versucht, krampfhaft die Annahme zu verifizieren."

Personas als Werkzeug für gemeinsame Entscheidungen

Oft werden Personas als sehr detaillierte, fast fiktive Charaktere mit Namen und Hobbys erstellt. Der pragmatischere und wertvollere Ansatz ist es, sie als vereinbarte Projektionsfläche für das Team zu sehen. Es geht weniger um biografische Details, sondern darum, ein gemeinsames Modell des Nutzers zu haben, auf das sich alle beziehen können, um Priorisierungen und Design-Entscheidungen zu diskutieren und zu treffen.

"Für mich ist Persona eigentlich eher so dieses, was können wir uns gemeinsam einigen, unsere Projektionsfläche."

Dein nächster Schritt

Du erkennst das Problem ungeprüfter Annahmen in deinem Team wieder und möchtest praktische Methoden an die Hand bekommen, um dagegen vorzugehen? Unser Kompakt-Guide fasst die wichtigsten Techniken zur Annahmenvalidierung und Nutzerforschung für agile Teams zusammen.