Agile Sprint vs. Design Sprint: Was ist der Unterschied?

Wer schnell irgendwo ankommen will, muss schneller gehen, am besten sprinten. Das gilt im Sport genauso wie in der Produktentwicklung. Doch eine erhöhte Geschwindigkeit hilft nicht nur schneller am Ziel zu sein. Wer schnell zu Ergebnissen kommt, kann diese auch eher bewerten. Auf sie reagieren. Veränderungen vornehmen. Sowohl im Agilen Sprint als auch im Design Sprint ist dieses Reagieren auf neue Erkenntnisse ein zentrales Element. Doch worin liegt der Unterschied? Und wie passt das zusammen?

Agiles Sprinten

Flexibler zu sein, besser auf Kundenbedürfnisse einzugehen und funktionierende Software abzuliefern, sind Grundpfeiler des Agilen Ansatzes, der in der Softwareentwicklung Ende der 90er Jahre als Gegenmodell zum klassischen Top-Down Projektmanagement entwickelt wurde. Aufbauend auf dieser grundsätzlichen Herangehensweise haben sich verschiedene Methoden entwickelt. Eine zentrale Methode sind kurze, iterative Entwicklungszyklen — Sprints — innerhalb derer eigenverantwortlich arbeitende Teams Produkteigenschaften einer Software (sog. Funktionalitäten oder Inkremente) fertigstellen.

Welche Funktionalitäten dies sind, wird am Anfang eines zwei bis vier wöchigen Sprints anhand von konkreten Anforderungen mit dem Team, dem Produktverantwortlichen (Product Owner) und ggfs. weiteren Projektverantwortlichen bestimmt. Innerhalb eines Sprints arbeitet das Team hauptsächlich selbstbestimmt und wird nicht mit neuen Anforderungen konfrontiert. Am Ende eines Agilen Sprints prüft man die zuvor definierten Anforderungen. Sind sie erfüllt, kann man die Funktionalität zur Veröffentlichung freigeben. Wenn nicht, wird die weitere Bearbeitung offener Anforderungen im Planungstreffen des nächsten Sprints festgelegt.

Die schrittweise Bearbeitung und Veröffentlichung von Teilen eines gesamten Produktes hat den Vorteil, das innerhalb der laufenden Entwicklung darauf Einfluss genommen werden kann. Gibt der Kunde Feedback zum aktuellen Stand, wünscht er sich eine bestimmte Funktionalität oder kommt er mit einer bestehenden nicht zurecht, kann dies berücksichtigt werden. Die Entwicklung oder Veränderung entsprechender Funktionalitäten erhält eine höhere Priorität und kann vorgezogen werden. Gleichermaßen können während der Entwicklung Probleme oder nötige, bisher unberücksichtigte Anforderungen zu Tage treten, auf die dynamisch reagiert werden kann.

Design Sprint

Während es im Agilen Sprint um die tatsächliche Entwicklung eines (Software-) Produktes geht, befinden wir uns mit dem Design Sprint noch einen Schritt weiter vorn im Innovationsprozess.

Der Design Sprint ist ein vergleichsweise junger Prozess und basiert auf Design Thinking. Er wurde u.a. von Jake Knapp bei Google entwickelt und ca. 2015 populär. Innerhalb von vier oder fünf Tagen erarbeitet dein Team eine Idee, überführt diese in einen Prototypen und testet sie qualitativ an fünf Zielgruppenvertretern.

Die Einsatzmöglichkeiten sind dabei sehr divers. Am besten eignet sich ein Design Sprint dann, wenn ein Team grundsätzliche Entscheidungen innerhalb der Produktentwicklung treffen werden müssen. Beispielsweise bevor ein neues Produkt entwickelt wird, um die Kernfunktionalitäten eines MVP zu definieren. Oder auch in der Weiterentwicklung, um beispielsweise auf Besonderheiten einer bestimmten Zielgruppe einzugehen.

Ziel des Design Sprints ist es, die Kernthesen bezüglich Funktionalität und Design eines Produktes möglichst früh im Innovationsprozess zu validieren. Hierdurch werden unnötige und teure Schleifen in der späteren Umsetzung vermieden.

Design Sprint oder Agile Sprint – Die Kombination macht’s!

Design Sprints und Agile Sprints kommen ursprünglich aus unterschiedlichen Welten, was nicht heißt, dass man sie nicht kombinieren sollte. Wie ich bereits in meinem Artikel “Innovation ist ein Prozess” angerissen habe, bereiten wir am Ende unserer auf dem Design Sprint basierenden Product Sprints, die Umsetzung nach agilen Methoden bereits vor.

Zum Beispiel haben wir neben dem Product Owner, grundsätzlich mindestens einen Entwickler im Product Sprint, der auch später an der Umsetzung beteiligt ist. Hierdurch können mögliche Stolpersteine schon frühzeitig mitgedacht werden. Am Ende eines oder mehrerer Product Sprints definieren wir gemeinsam mit dem Team die Produkt-Vision und Road Map. Im Anschluss können die Entwickler sofort loslegen.

Im Umsetzungsprozess selbst können wiederum einzelne Design Sprints dabei helfen, Probleme des Entwicklerteams zu lösen. Beispielsweise, um im Prozess vom Kunden gewünschte Features zu evaluieren und zu konkretisieren oder Lösungen für neu entstandene Herausforderungen zu finden.

Weiterführende Informationen zum Thema

Agile & Scrum: http://agiles-projektmanagement.org/

Design Sprint: https://www.gv.com/sprint/ & https://sprintstories.com/