Agile Organisation – Methoden, Prozesse und Strukturen im digitalen VUCA-Zeitalter

6.3 Scrum

Scrum ist der bekannteste agile Ansatz.¹⁶² Hierbei handelt es sich um ein Vorgehensrahmen bzw. -gerüst (Managementframework). Der Ansatz stammt zwar ursprünglich aus der Softwareentwicklung, kann aber auch für andere, projektartige Prozesse, wie bspw. Produktentwicklungen (z. B. im Maschinenbau) bzw. kontinuierliche Produkt- (z. B. von Flughäfen) oder Serviceverbesserungen (z. B. von Dienstleistungsunternehmen) angewendet werden.

Das ab 1993 von KEN SCHWABER und JEFF SUTHERLAND entwickelte und insb. auf den Kerngedanken von Lean Thinking (vgl. Kapitel 2.3) und den Arbeiten von TAKEUCHI/NONAKA und DEGRACE/HULET STAHL basierende Framework¹⁶³ baut auf der Erkenntnis auf, dass es in dynamischen und komplexen Umfeldern – wie es in der Softwareentwicklung schon länger üblich ist – nicht zu den besten Lösungen führt, wenn sich wenige Experten eine (vermeintlich) optimale Lösung für ihre Kunden überlegen, einen fixen Plan aufstellen und dann über einen detaillierten, langwierigen Prozess, der hierarchisch gesteuert wird, (vermeintlich) perfekt – inkl. perfekter Dokumentation – umsetzen (lassen). Denn in einem solchen Vorgehen ist die Lösung abhängig von der Genialität weniger Experten, die sich anmaßen, den wahren Kundenbedarf zu erkennen, obwohl die meisten Kunden diesen oft selbst nicht wirklich benennen können. Auch ändern sich Kundenanforderungen und -erwartungen im Zeitablauf – gerade vor dem Hintergrund exponentieller Technologieentwicklungen. Und die hierarchische Steuerung behindert flexibles Reagieren und das Einbringen neuer Ideen im Prozess. Nicht zuletzt ist es in vielen Fällen vermessen, im ersten Versuch direkt eine „perfekte“ Lösung erstellen zu wollen. Oft zeigt sich erst am Markt, was funktioniert bzw. wirklich vom Kunden angenommen wird.¹⁶⁴

Eine zentrale Kernidee von Scrum ist es daher, Unklarheit und Komplexität durch Zwischenergebnisse (sogenannte Produktinkremente) zu beseitigen, zu denen immer wieder Feedback eingeholt wird. Auf Basis der Zwischenergebnisse bzw. der Rückmeldungen dazu lassen sich die fehlenden Anforderungen und Lösungstechniken effizienter finden als durch eine abstrakte Klärungs- und Planungsphase. Die Entwicklung läuft dann iterativ in kleinen Schritten (sogenannte Sprints), bei denen es nicht schlimm ist, wenn auch mal ein Versuch zum Irrtum und nicht (direkt) zur Lösung führt.

Durch das wiederkehrende Feedback von Produktverantwortlichen (sogenannte Product Owner), Auftraggebern und Nutzern wird eine ständige Ausrichtung an den wirklichen Kundenbedürfnissen erreicht. Dadurch ist man ständig am Lernen und Optimieren (vgl. Kapitel 4.2).

Ein weiterer Kernaspekt ist es, ein cross-funktional, mit ausgewiesenen Experten besetztes Team eigenständig und selbstorganisiert an der Umsetzung arbeiten zu lassen. Dies basiert auf der Überzeugung, dass in komplexen Umweltsituationen durch eine solche Konstellation und bei möglichst viel operativer Abstimmung „an der Basis“ i. d. R. bessere Ergebnisse entstehen als bei der (Vorab- und Gesamt-) Planung durch eine übergeordnete Managementinstanz.

Das Scrum-Framework besteht aus einem Prozessmodell mit standardisierten Phasen, Meetings und Artefakten sowie spezifischen Rollen. Im Folgenden soll zunächst das (etwas vereinfachte) Prozessmodell vorgestellt werden (vgl. Abbildung 27).

Abb. 27: Prozessmodell von Scrum¹⁶⁵

Ausgangspunkt ist eine Produktidee bzw. Produktvision, d. h. eine grobe Vorstellung über das angestrebte Ergebnis.

Hieraus werden Produktfunktionalitäten abgeleitet, die beschreiben, was das Produkt dem Nutzer bietet – dies erfolgt häufig in der Form von kleinen „Geschichten“ über den Einsatz durch die Benutzer (User Stories¹⁶⁶).

Die priorisierten Funktionalitäten/User Stories – ergänzt um eine, im Prozess immer wieder aktualisierte Schätzung des Umsetzungsaufwands (in einem Estimation Meeting) – bilden zusammen das Product Backlog. Im Gegensatz zu einem fix aufgestellten Plan/Konzept beim klassischen „Wasserfallmodell“, ändert sich das Product Backlog kontinuierlich durch die im Prozess neu gewonnenen Erkenntnisse (Product Backlog Refinement).

Die iterative Umsetzung der einzelnen Funktionalitäten/User Stories erfolgt in Form von Sprints. Dies sind Phasen von typischerweise 2-3 Wochen, in denen störungsfrei (d. h. innerhalb dieser Zeit ändern sich die Vorgaben nicht) einzelne Elemente/Funktionalitäten aus dem Product Backlog umgesetzt und vorzeig-/nutzbare (man spricht von „usable“ oder auch „potentially shippable“) Produktteile bzw. -inkremente entwickelt werden.

Am Anfang eines jeden Sprints finden zwei Planungen statt. Im Sprint Planning 1 wird festgelegt, welche Elemente des Product Backlogs bearbeitet werden (Selected Product Backlog). Im Sprint Planning 2 geht es um die Frage, wie diese Elemente umgesetzt werden sollen. Es entsteht eine Liste von Aufgaben für den anstehenden Sprint (Sprint Backlog).

Im Sprint wird meist auch mit Prinzipien und Praktiken aus Kanban gearbeitet – u. a. Aufgabenboards (Task Boards, auf denen der Umsetzungsstatus der Elemente des Sprint Backlogs dargestellt sind), dem Pull-Prinzip und WiP-Limits.

In einem kurzen, täglichen Meeting (Daily Scrum oder auch Daily Standup Meeting) stimmen die Teammitglieder ihre Aufgaben untereinander ab. Das Meeting soll kurzgehalten werden (typ. 15 min, immer zur gleichen Zeit) und findet deshalb im Stehen statt. Ziel ist es, den aktuellen Stand auszutauschen, Abhängigkeiten festzustellen und von anderen Teilnehmern Hinweise/Ideen zum Lösen von Problemen zu bekommen.

Am Ende jedes Sprints steht ein fertiggestelltes Produktinkrement (mit den umgesetzten Funktionalitäten/User Stories). Über eine sogenannte „Definition of Done“ wird definiert, was konkret unter „fertig“ verstanden wird.

Am Ende des Sprints stellt das Team das fertiggestellte Produktinkrement vor – mindestens dem Product Owner, am besten auch den Kunden und/oder Nutzern –, um Feedback zum Produkt einzuholen (Sprint Review).

Außerdem gibt es nach jedem Sprint eine Sprint Retrospektive, in der das Team die Zusammenarbeit reflektiert und überlegt, wie man diese weiter optimieren kann. Während es also beim Review um das Produkt geht (Fokus: Effektivität), geht es hier um die Arbeitsprozesse (Fokus: Effizienz).

Auf Basis der Erkenntnisse aus Sprint und Review kann das Product Backlog aktualisiert und der nächste Sprint geplant werden, d. h. die nächste Iteration startet.

Der Scrum-Prozess endet typischerweise dann, wenn die vorgegebene Zeit bzw. das vorgegebene Budget verbraucht ist. Dann sind zwar nicht zwingend alle Funktionalitäten/User Stories aus dem Product Backlog umgesetzt, aber die wichtigsten. Hier unterscheidet sich die Scrum-Logik von der klassischen Planungslogik, bei der der Scope fixiert ist, aber Zeit und Budget regelmäßig „aus dem Ruder“ laufen.¹⁶⁷

Parallel zu diesem operativen Prozess wird ein sogenanntes Impediment Backlog geführt. Dies ist eine Liste aller Hindernisse, die das Team bei der Arbeit stören und (vom Scrum Master verantwortet) aus dem Weg geräumt werden sollten, um eine effektive und effiziente Arbeit zu ermöglichen.

Innerhalb dieses Prozessmodells agieren die folgenden Rollen (wobei nur die ersten drei Rollen zum Kern des Frameworks gehören):

Der Product Owner ist für das zu erstellende Ergebnis/Produkt und die finanzielle Seite des Projekts verantwortlich. Er lenkt die Produktentwicklung durch eine möglichst greifbare Produktvision sowie klar formulierte Rahmenbedingungen. Er ist verantwortlich für die kontinuierliche Aktualisierung des Produkt Backlogs und arbeitet täglich mit dem Entwicklungsteam.

Das Entwicklungsteam besteht aus den, i. d. R. cross-funktional/multi-disziplinär zusammengesetzten, Personen (typischerweise 5-9), die für die Entwicklung des Produkts erforderlich sind. Es steuert seine Arbeitsmenge selbst und trägt die Verantwortung für die professionelle Produkterstellung.

Der Scrum Master kümmert sich um die (kontinuierliche Erhöhung der) Produktivität des Teams. Auch wenn er nicht weisungsbefugt ist, sorgt er dafür, dass der Scrum-Prozess eingehalten wird (Prozessverantwortung) und kontinuierliches Lernen und Verbessern stattfindet. Außerdem kümmert er sich um das Lösen von Problemen (Impediments), die das Scrum-Team vom Arbeiten abhalten. Viele dieser Impediments resultieren aus Abhängigkeiten von anderen Organisationseinheiten oder Externen.

Product Owner, Entwicklungsteam und Scrum Master bilden zusammen das Scrum-Team.

Diejenigen Personen, die die Ressourcen (insb. die beteiligten Personen) zur Verfügung stellen und generelle Rahmenbedingungen setzen, werden in der Scrum-Terminologie als „das Management“ bezeichnet. Der Scrum Master geht auf das Management zu, um gemeinsam die identifizierten Probleme (Impediments) zu lösen.

Der (interne oder externe) Kunde soll das Ergebnis des Projekts kaufen. Er ist somit der Finanzier bzw. Budgetverantwortliche.

Der User (Nutzer) verwendet das Produkt bzw. Projektergebnis. Damit seine Bedürfnisse möglichst gut erfüllt sind, sollte er in regelmäßigen Reviews die Zwischenergebnisse testen und Feedback geben.

Durch dieses Framework bzw. Rahmenmodell schafft Scrum ein definiertes, verlässliches Gerüst, das Sicherheit und Orientierung bietet. Man macht nicht einfach irgendwas, sondern das ganze hat Struktur bzw. ist organisiert. Aber Scrum macht ganz bewusst keine inhaltlichen Vorgaben, d. h. es wird z. B. gerade nicht festgelegt, wie die eigentliche Produktentwicklung abläuft und was für ein Produkt entwickelt wird. Es wird „nur“ definiert, wie die Arbeitsteilung und Koordination im Team erfolgt. Das heißt, der Metaprozess ist geregelt und standardisiert. Innerhalb dieses Standardprozessmodells hat das Team alle Freiheiten („freedom within a frame“, vgl. Kapitel 4.5). Dementsprechend eignet sich Scrum dann, wenn es keinen klaren inhaltlichen Problemlösungsprozess gibt. In der Logik der Stacey-Matrix (vgl. Kapitel 2.4) also insbesondere bei komplexen Aufgaben. Dies ist der zentrale Unterschied zu Kanban.

Es ist auch durchaus möglich, einzelne Praktiken aus Scrum zu verwenden, um weitere Unternehmensprozesse agil zu gestalten oder diese mit klassischen Organisationselementen in einer hybriden Form zu kombinieren. Ein Beispiel liefert der in Kapitel 10 vorgestellte agile Strategieprozess der SAXONIA SYSTEMS AG. Und NAGEL/WILHELM beschreiben in ihrem Beitrag, wie sie in der NRW.BANK mithilfe der Stacey-Matrix Scrum als agiles Methodengerüst in eine hybride Projektstruktur integrierten.

Soll Scrum für größere Projekte bzw. Produktentwicklungen angewendet werden, muss der Ansatz skaliert werden. Wie dies möglich ist, zeigen die agilen Skalierungsframeworks in Kapitel 7, die wesentlich auf dem Scrum-Framework aufbauen.

6.4 Lean Startup

Der Grundgedanke von Scrum, nicht in einem großen Ansatz ein komplettes Produkt zu erstellen, sondern iterativ vorzugehen und dabei durch Feedback zu lernen, findet sich so auch bei der Lean-Startup-Methode.¹⁶⁸ Der Ansatz wurde von ERIC RIES entwickelt, der Anfang dieses Jahrtausends in die Gründung und den Aufbau mehrerer Start-ups involviert war, die „naturgemäß“ nicht alle erfolgreich waren. Insbesondere scheiterten einige daran, dass das Geld ausging, bevor das geplante Produkt fertig war und an den Markt gehen konnte.

Basierend auf dieser Erkenntnis und unter Nutzung einiger Ideen von STEVE BLANK und aus dem Lean-Management-Umfeld (vgl. Kapitel 2.3) entwickelte RIES ein schlankes Learning-by-Doing-Modell für Start-ups. Kernidee ist ein iteratives, inkrementelles Vorgehen, bei dem Hypothesen mit echten Kunden bzw. Nutzern getestet werden. Durch dieses Lernen vom bzw. am Markt wird Unsicherheit reduziert.

Der Kern des Modells ist der in Abbildung 28 dargestellte, sich wiederholende Zyklus aus Bauen, Messen und Lernen (Build, Measure, Learn). Auf Basis einer Geschäftsbzw. Produktidee wird bewusst nicht in einem großen Schritt ein „komplettes“ Geschäft bzw. Produkt gebaut, sondern es wird lediglich ein „minimal funktionsfähiges Produkt“ erstellt und am Markt mit echten Kunden bzw. Nutzern getestet. Auf Basis der am echten Markt gemessenen Befunde wird gelernt (validiertes Lernen), was funktioniert und – genauso wichtig – was nicht. Dieser Prozess wird ständig wiederholt, um das Geschäft bzw. Produkt kontinuierlich zu verbessern. Dadurch soll gesichert werden, dass ein Geschäft bzw. Produkt entwickelt wird, das auch wirklich vom Markt angenommen wird. Nicht tragfähige Ideen bekommen frühzeitig – bevor große Summen investiert sind – die Rückmeldung, dass hierfür kein Markt existiert.

Abb. 28: Prozessmodell von Lean Startup¹⁶⁹

Die Denklogik des hypothesengetriebenen Vorgehens ist genau andersherum, d. h. es sollte in der Logik von Abbildung 28 gegen den Uhrzeigersinn gedacht werden. Sinnvollerweise sollte bei der Konzeption damit gestartet werden, zu überlegen, was man lernen bzw. wissen will (Welche Hypothese über das Produkt bzw. den Markt soll geprüft werden?). Darauf aufbauend sollte ein passendes Test- bzw. Messmodell konzipiert werden (Wie kann man das testen und messen?) und auf der Basis dann das dazu passende minimal funktionsfähige Produkt (Was muss das Produkt bieten/können, damit der Test möglich ist?) gebaut werden.

Ein schönes Beispiel liefert der US-amerikanische Online-Modehändler ZAPPOS.¹⁷⁰ Das 1999 von NICK SWINMURN gegründete Unternehmen basierte auf der damals keineswegs sicheren Annahme, dass es möglich ist, Schuhe gewinnbringend über das Internet zu verkaufen. Während SWINMURN an diese Idee glaubte, bezweifelten dies viele seiner Gesprächspartner und potenziellen Investoren, weil Schuhe und Füße unterschiedlich ausfallen, verschiedene Modelle anprobiert werden müssten und daher entweder erst gar nicht online bestellt oder zu extrem großen Rücksendungen (und damit hohen Retourkosten) führen würden.

Aufgrund dieser großen Gefahr bzw. Unsicherheit wäre es extrem risikoreich gewesen, eine komplette, voll funktionsfähige Website mit einer großen Datenbank mit Schuhen zu erstellen sowie ggf. sogar ein Sortiment an Schuhen zu kaufen und dann erst festzustellen, ob die Idee überhaupt zu einem tragfähigen Geschäft führt. Im Negativfall wäre viel Zeit und Geld verschwendet.

Um herauszufinden, ob Schuhe überhaupt online gekauft werden und wie hoch die Rücksendungen tatsächlich sind, wandte sich SWINMURN stattdessen an örtliche Schuhgeschäfte, fotografierte deren Bestände, stellte die Bilder nur auf einer sehr einfach gehaltenen Website online, kaufte die Schuhe nach dem Verkauf zum vollen Preis in den Geschäften und versandte sie dann direkt an die Kunden. Die Rückmeldungen vom echten Markt zeigten, dass die Kundennachfrage vorhanden und die Rücksendungen geringer als befürchtet bzw. handhabbar waren.

Im Beispiel von ZAPPOS ist die einfache Website mit Fotos von Schuhen und der Möglichkeit diese zu bestellen das „minimal funktionsfähige Produkt“ (MFP) – im Englischen Minimal Viable Product (MVP) – um die beiden zentralen Hypothesen (bzgl. Bestellungen und Retouren) zu testen. Es bietet alle notwendigen Kernfunktionen, verzichtet aber auf jedweden ergänzenden „Schnick-Schnack“. Dadurch wird zum einen der Aufwand und Ressourcenbedarf minimal gehalten und zum anderen wird gesichert, dass der Erfolg bzw. Misserfolg auch tatsächlich auf dem untersuchten Element und nicht irgendeiner ergänzenden Funktion oder einem tollen Design basiert. In weiteren Iterationen können dann zusätzliche Funktionalitäten ergänzt und wiederum getestet werden.

Oft wird vor einem wirklichen MVP auch schon mit Prototypes bzw. Mockups, d. h. Attrappen, die das Design bzw. (Teil-)Funktionen eines Produktes demonstrieren, gearbeitet, um mit minimalen Kosten einen ersten Markteindruck zu bekommen. In diesem Fall wird das Produkt dann lediglich auf Papier den Kunden bzw. Nutzern vorgeführt. Dies liefert schonmal erste Rückmeldungen, hat aber das Problem, dass es oft Unterschiede zwischen dem gibt, was Menschen in Interviews als interessant bezeichnen und dem Verhalten, wenn tatsächlich Geld dafür zu bezahlen ist.

Die Lean-Startup-Methode eignet sich natürlich insbesondere für Start-ups. Zum einen verfügen sie typischerweise über sehr beschränkte finanzielle Mittel und zum anderen operieren sie in einem Umfeld großer Ungewissheit. Kundensegment und Produkt sind zwar z. T. definiert, basieren aber oft auf Vermutungen. Bei etablierten Unternehmen ist zwar im Regelfall mehr Geld vorhanden und es ist finanziell eher möglich, direkt ein komplettes Produkt bzw. Geschäftsmodell zu bauen. Aber auch sie bewegen sich bei Innovationen, insbesondere in einer VUCA-Umwelt, in großer Ungewissheit. Um diese Ungewissheit zu reduzieren und nicht am Markt und den Kunden vorbei zu entwickeln, empfiehlt sich auch hier die Anwendung der Lean-Startup-Methode bzw. -Denke.

Der Marktlaunch eines MVPs ermöglicht das Überprüfen von grundlegenden Geschäftshypothesen und Annahmen am wirklichen Markt. So können frühzeitig die tatsächlichen Wünsche und Bedürfnisse der Zielgruppe ermittelt werden. Eine frühe Marktrückmeldung durch zahlende Kunden ermöglicht schnelle Anpassungen und erlaubt es, neue Richtungen einzuschlagen. Durch validiertes Lernen ist es möglich, Entscheidungen anhand von Daten zu treffen, anstatt auf Vermutungen zu bauen.

Die zentralen Grundideen von Lean Startup zeigen einige Gemeinsamkeiten zu Scrum. In beiden Fällen geht es um iteratives Lernen und Optimieren durch regelmäßiges Feedback. Während Scrum aber eher auf die Entwicklung eines Produktes fokussiert, zielt Lean Startup auf die Entwicklung von Geschäft(smodell)en.

6.5 Design Thinking

Gedanklich vor Scrum und Lean Startup bewegt sich Design Thinking. Es handelt sich um eine agile Methode zum systematischen Erfinden und Innovieren.¹⁷¹ Der Ansatz orientiert sich an der Arbeit von Designern, was den Namen erklärt. Design steht dabei aber weniger für schönes Aussehen, sondern mehr für die dahinterliegenden Funktionalitäten.

Der Design-Thinking-Prozess besteht, wie in Abbildung 29 dargestellt, aus sechs klar definierten, aber nicht streng linear ablaufenden Prozessschritten. Dabei sind die ersten drei Schritte (Verstehen, Beobachten und Sichtweise definieren) darauf ausgerichtet, zunächst einmal die Situation, Position und Motivation der Anwender genau zu verstehen. Diesem Aspekt wird bewusst ein großer Raum gegeben. Hier zeigen sich deutliche Unterschiede zu Scrum und Lean Startup.

Im zweiten Prozessteil (Ideen finden, Prototyp(en) entwickeln und testen) zeigen sich dagegen etliche Parallelitäten zu Scrum und Lean Startup. Es sollen Lösungsideen gefunden sowie passende Prototypen entwickelt und getestet werden, um daraus zu lernen. Auch Design Thinking folgt einem iterativen Vorgehen, d. h. man kann und soll jederzeit ein oder mehrere Schritte vor- und zurückgehen, bis das Ergebnis stimmig ist.

Abb. 29: Prozessmodell von Design Thinking¹⁷²

Der in Abbildung 29 dargestellte, an der D-SCHOOL des HASSO-PLATTNER-INSTITUTS in Stanford und Potsdam angewandte Prozess lässt sich folgendermaßen erläutern:

1. Kontext verstehen: Das Team versucht zunächst alle relevanten Dimensionen der Problemstellung zu verstehen (Analyse vorhandener Literatur und vergleichbarer Projekte), um Wissenslücken zu erkennen und Themen für die qualitative Recherche zu definieren.

2. Menschen beobachten: Das Team wendet qualitative Forschungsmethoden (z. T. in kreativer Art und Weise) an. Durch teilnehmende Beobachtungen und Interviews sollen die Vorstellungs- und Lebenswelten, Nutzungskontexte, Erwartungen und Erfahrungen von potenziellen Nutzern analysiert und Verhaltensmuster, Emotionen und Bedürfnisse erkannt werden (oft wird dabei mit „Customer Journey“-Modellen gearbeitet).

3. Sichtweise definieren: Das Team führt die Ergebnisse aus den vorherigen rechercheorientierten Prozessschritten zusammen, fokussiert sich auf die vielversprechendsten Erkenntnisse und entscheidet, in welche Richtung und für welche Nutzergruppen (typischerweise in Form von „Personas“) es Lösungen entwickeln möchte.

4. Ideen finden: Das Team generiert mithilfe verschiedener Kreativmethoden möglichst zahlreiche Ideen (Mix aus stiller, konzentrierter Einzelarbeit und energetischer Teamarbeit) und gruppiert diese (u. a. nach Umsetzbarkeit und Nutzenpotenzial).

5. Prototyp(en) entwickeln: Das Team arbeitet ausgewählte Ideen mithilfe unterschiedlicher Medien und Materialien (z. B. Kunststoffverpackungen, Pappkartons, Legosteine etc.) konkreter aus. Ziel der oft multimedialen Prototypen ist es, einerseits eine konkrete Vorstellung vom finalen Ergebnis zu entwickeln und andererseits die Ideen schnell und (be)greifbar an Dritte vermitteln zu können.

6. Prototyp(en) testen: Anders als bei traditionellen Entwicklungsprozessen wird jeder Prototyp in iterativen Zyklen mit (aktuellen und) potenziellen Nutzern getestet. Basierend auf den Erkenntnissen entscheidet das Team, ob es noch einmal im Prozess zurückgehen möchte, um den Prototypen zu verbessern. Durch jede Iterationsschleife werden die Prototypen realistischer, da sie mit steigender Detailgenauigkeit konkreter und funktionaler werden.

Der Kern von Design Thinking ist die konsequente Orientierung und Ausrichtung am Kundennutzen. Die Methode stellt heraus, dass es wichtig ist, bei den Bedürfnissen und Motivationen der Menschen anzusetzen, die „am Ende” die Anwender und Nutzer der jeweiligen Ergebnisse sind. Der Innovations- und Entwicklungsprozess muss sich auf diese Nutzer – und deren Bedürfnisse – ausrichten, dafür ist es wichtig sie umfassend zu beobachten und sich in sie hinein zu versetzen.

Ein Kernaspekt von Design Thinking ist auch das immer wieder ausweiten und verengen des Betrachtungshorizonts, sog. Divergieren und Konvergieren (vgl. Abbildung 29). Im Prozess wechseln ganz bewusst Phasen ab, in denen es einerseits darum geht, weit und breit zu denken und möglichst viele Eindrücke zu bekommen und Ideen zu entwickeln, und andererseits, die vielfältigen Ansätze und Ideen auf ein konkretes gemeinsames Verständnis bzw. einen Prototyp zu fokussieren.

Neben dem Prozess sind selbstorganisierte, interdisziplinäre Teams und flexible Arbeitsumgebungen zwei weitere Kernelemente des Design-Thinking-Ansatzes:

Wie bei Scrum sollte auch bei Design Thinking in selbstorganisierten, interdisziplinären Teams gearbeitet werden. Der Ansatz basiert auf der Annahme, dass Probleme besser gelöst werden können, wenn Menschen unterschiedlicher Disziplinen und mit verschiedenen Kompetenzen in einem die Kreativität fördernden Umfeld zusammenarbeiten.

Typisch für Design Thinking sind auch freie und flexible Arbeitsumgebungen, die (spontan) auf die Bedürfnisse des jeweiligen Projektes anpassbar sind. Dies impliziert bewegbare Möbel, ausreichend Platz für Whiteboards und Präsentationsflächen sowie Materialien zur prototypischen Gestaltung von Ideen.

Das Ergebnis von Design Thinking sind (visuelle und haptische) Prototypen und Modelle, keine fertigen Produkte. Dementsprechend lässt sich dieser agile Kreativitäts- und Innovationsansatz mit Lean Startup oder Scrum verbinden, wo es dann darum geht, das Produkt umzusetzen bzw. den Prototyp oder das (minimal funktionsfähige) Produkt am Markt zu testen bzw. das Produkt zu bauen.