Juli 2020 · 31. Juli 2020

Design Thinking, Scrum und Kanban

Autor: Friedrich Dürst

Haben Sie schon mal etwas über ASD, DSDM, RAD oder XP gehört? Diese Akronyme stammen aus der Softwareentwicklung und bedeuten Adaptive Software Development (ASD), Dynamic System Development Method (DSDM), Rapid Application Development (RAD) und Extreme Programming (XP). Es gibt noch diverse weitere – einem breiten Publikum bekannt wurden in den letzten Jahren jedoch Scrum und Kanban. Allen gemein ist ein iterativer und inkrementeller Ansatz sowie sich selbst organisierende und interdisziplinäre Teams. Diese Eigenschaften kennen Lean Enthusiasten schon seit langem aus dem Hoshin Kanri, dem damit verbundenen Gemba Kanri oder auch dem Lean Development.

Um im Labyrinth der vielen Methoden, Techniken und Ansätze nicht die Orientierung zu verlieren, findet man in diversen Netzwerken Empfehlungen, wann und zu welchem Zweck welche Methode eingesetzt wird. Dieser rote Faden bildet meist die unterschiedlichen Status im Verlauf eines Produktentstehungs- oder Ideenfindungsprozesses ab. Am Anfang einer Produktentwicklung wird häufig der Ansatz des Design Thinking empfohlen. Dieser kann gewählt werden, wenn eine grobe Idee für ein mögliches Produkt vorhanden

ist, oder wenn noch keine Geschäftsidee besteht. In einem sehr offenen Prozess werden während des Verlaufs viele neue Ideen generiert und auch wieder verworfen. Ziel ist es dabei, Lösungen zu finden, die aus Anwendersicht überzeugend sind.

Design Thinking

Bekannt geworden ist Design Thinking in Deutschland vor allem durch Hasso Plattner, einem Mitbegründer des Softwareunternehmens SAP. Mit seiner 2005 geründeten "d.school", dem "Hasso Plattner Institute of Design" an der Stanford Uni- versity in Palo Alto in Kalifornien fördert er die Erforschung und Umsetzung des Ansatzes. In Deutschland eröffnete Plattner 2007 die "School of Design Thinking" in Potsdam und 2016 die "d.school" in Cape Town in Südafrika. Die Ursprünge des Design Thinking Ansatzes werden jedoch häufig mit der Gründung der Design- und Innovationsagentur IDEO im Jahr 1991 in Verbindung gebracht. Tatsachlich gehen die Wurzeln in die 1970er Jahre zurück. Einer der einflussreichsten Sozialwissenschaftler dieser Zeit, der Nobelpreisträger Herbert A. Simon, verfasste 1969 mit seinem Buch "The Science of Artifical" die Grundgedanken des Ansatzes. Sein Interesse galt vor allem der Kreativität und Innovation bei Entscheidungsfindung und Problemlösung. Die Rolle des Designers beschreibt er als eigenständige transdisziplinäre Form der Wissensproduktion mit Zielorientierung und sich selbst reflektierendem Redesign-Prozess.

Mit dem Meisterwerk "Experiences in Visual Thinking" knüpfte der Ingenieur Robert H. McKim 1973 an Simons Werk an. Der Inhalt beschäftigt sich mit der Art und Weise, wie Wahrnehmungsdenkver- mögen genutzt und verbessert werden kann. Beiden gemeinsam ist die Erkenntnis: "Design is a way of thinking“. Ein weiterer Vorreiter zum Thema Design Thinking ist Bryan Lawson. Der Professor für Architektur setzte sich mit dem Designprozess an sich auseinander. Sein bekanntestes Werk ist "How Designers think". In einem Experiment fand er heraus, dass es für einfache Aufgaben problemorientierte und lösungsorientierte Menschen gibt. Aufbauend auf Lawsons Ergebnissen erkannte der emeritierte Designforscher Nigel Cross, dass Wissenschaftler Probleme durch Analyse und Designer Probleme durch Synthese lösen. Design Thinking verwendet sowohl Analyse als auch Synthese.

Der Begriff "Design Thinking tauchte erstmals im gleichnamigen Buch von Peter Rowe auf. Er liefert eine systematische

Darstellung des Designprozesses in Architektur und Stadtplanung. Dazu untersuchte er mehrere und oft unterschiedliche the- oretische Positionen und Verfahren zur Lösung von Problemen. Schließlich erweiterte der Professor für Industriedesign, Rolf Faste in den 1980er Jahren McKims Arbeit und erfand den Begriff "Design Thinking" als Methode des kreativen Handelns. In seiner einfachsten Form ist es "eine formale Methode zur praktischen, kreativen Lösung von Problemen oder Fragen, mit der Absicht, eine bessere Zukunft herbeizuführen". Roger Martin und auch Tom und David Kelley von IDEO gelten heute als die Väter des Design Thinking. Sie haben die Methode aus der Wissenschaft in die Wirtschaft abgeleitet, und in ihrer jetzigen Form etabliert. Das gefällt Richard Buchanan, Professor für Design der Weatherhead School of Management, einer der weltweit führenden Design- Theoretiker gar nicht. In seinem im Jahre 1992 erschienen Artikel "Wicked Problems in Design Thinking" bemängelte er die Kommerzialisierung und starre Formalisierung des Ansatzes. Seine Forderung der Ablehnung fand vor allem bei Designern, Architekten und anderen gestalterischen Berufen Anklang.

Betrachtet man die Methode genauer, gestaltet sich der tatsächliche theoretische Design Thinking Prozess recht übersichtlich. Er besteht aus sechs aufeinander- folgenden Phasen:

Phase 1 ist das "Verstehen". Hier sollen zunächst die Nutzer verstanden werden. Somit können Problemstellung und The- menfeld eingegrenzt und definiert werden. Ziel ist es, Experte in dem betrachteten Gebiet zu werden. Dazu betrachtet man die Expertise innerhalb des Teams. Gegebenenfalls kontaktiert man außenstehende Experten oder sucht Studien zum Thema im Internet. Hilfreiche Tools sind das Moodboard, die Stakeholder- oder Market Map. Man arbeitet mit Hypothesen, nicht mit fixen Annahmen.
"Beobachten" ist die Phase 2. Latente Bedürfnisse und emotionale Hintergründe von Kunden und anderen Stakeholdern werden hier identifiziert und erfasst. Man geht in die Tiefe, betrachtet den Kontext und sucht extreme User. Interviews, Fly-on-the- Wall, Personal Inventory, Shadowing oder Emphathy Maps sind dabei hilfreich.
Die anschließende analytische 3. Phase, die "Synthese", zeichnet sich durch die Informationssammlung, die Aufbereitung, Interpretation, Analyse und Bewertung aus. Sie ist die wahrscheinlich herausforderndste Phase. Ziel ist es hier, die Problemstellung konkret zu formulieren und zu Erkenntnissen zu verdichten. Tools wie Persona (Prototypenkunden), Customer Journey oder Timelines sind dabei nützlich. Man versucht durch die erlebten Geschichten die emotionalsten Momente zu extrahieren. In den ersten drei Phasenwerden keine Lösungen, jedoch Muster für das am Anfang formulierte Problem erarbeitet.
Dies geschieht in der 4. Phase, der "Ideenfindung". Erst hier werden zahlreiche kreative Lösungen beschrieben. Diese dürfen und sollen absolut verrückt sein (Quantität statt Qualität). Abschließend werden die Einfälle vom Team bewertet.
Die entwickelten Ideen werden in Phase 5 ("Prototypen") konkretisiert, und in greifbare Objekte umgesetzt. Basteln, Bauen, Blueprints oder Rollenspiele sind behilflich. Wesentlich hierbei ist die Konzentration auf wegweisende Funktionalitäten, modularer Aufbau und Schnelligkeit statt Perfektion.
Die Prototypen werden in Phase 6 („Testen“) von einer großen Anzahl an Kunden und Stakeholdern in der Realität getestet und bewertet. Die Feedbacks werden zur Inspiration, Verbesserung und Validierung der Problemstellung herangezogen. Man nennt diese Phase auch oft die 2. Beobachtungsphase. Ein Tool hierfür ist zum Beispiel das Play-Station Chart.

In der Realität ist die theoretische lineare Vorgehensweise nicht immer zu halten. Ständiges Vor- und Zurückschreiten innerhalb der einzelnen Phasen ist normal und auch gewollt. Die größte Herausforderung ist anfangs das Contra- Intuitive der ersten drei Phasen.

Scrum als nächster Schritt

Wenn das Produkt definiert oder ein Geschäftsmodell bestimmt ist, dann kann man in einem nächsten Schritt an die Aus- gestaltung gehen. Im Rahmen des agilen Projektmanagements setzt man gerne auf das Framework Scrum. Der Begriff "Scrum" wurde erstmals von Ikujirō Nonaka undHirotaka Takeuchi genannt, die damit das Gedränge (englisch "scrum") im Rugby als Analogie für außergewöhnlich erfolgreiche Produktentwicklungsteams bei Toyota und Canon in Japan beschrieben. Diese Teams arbeiten als kleine, selbstorganisierte Ein- heiten und bekommen von außen nur eine Richtung vorgegeben, bestimmen aber selbst die Taktik, wie sie ihr gemeinsames Ziel erreichen. Die beiden Organisations- experten führen den Erfolg dieser Teams auf ein bestimmtes Wissensmanagement zurück. In japanischen Firmen ist Wissen in erster Linie implizit, damit subjektiv und intuitiv. Es enthält Bilder der Realität und die Vision der Zukunft. Explizites Wissen lässt sich dagegen leicht darstellen und verarbeiten. Unternehmen wie Toyota oder Canon profitieren vom impliziten Wissen ihrer Mitarbeiter, indem sie hohen Wert auf die Interaktion zwischen ihren Mitar- beitern legen.

Aus diesen Beobachtungen und Erkennt- nissen entwickelten Nonaka und Takeuchi die Wissensspirale, auch SECI-Modell (Socialization, Externalization, Combi- nation, Internalization) genannt. Dieses dynamische Modell stellt den Wissens- übergang vom impliziten auf das explizite Wissen dar und ermöglicht so den Prozess der Wissensbeschaffung und Wissens- weitergabe in Unternehmen. Beeindruckt von diesem Modell definierten die US- amerikanischen Softwareentwickler Jeff Sutherland und Ken Schwaber 1994 in einem Projekt für die Guinness Peat Avi- ation eine neue Rolle für die Projektleiter. Scrum lässt sich in diesem Zusammenhang als Gegenentwurf zur Befehls- und. Kontroll- Organisation verstehen, in der Mitarbeiter genaue Arbeitsanweisungen erhalten. Stattdessen baut Scrum auf hochqualifi- zierte, interdisziplinär besetzte Entwick-

lungsteams, die zwar eine klare Zielvorgabe bekommen, für die Umsetzung jedoch allein zuständig sind. Dadurch bekommen die Entwicklungsteams den nötigen Freiraum, um ihr Wissens- und Kreativitätspotenzial in Eigenregie zur Entfaltung zu bringen. Nach diversen Veröffentlichungen („Agile Software Development with Scrum“ 2001, „Agile Project Management with Scrum 2003) erschien schließlich Ken Schwabers drittes Buch “The Enterprise and Scrum“, in dem er die Ausweitung von Scrum auf das gesamte Unternehmen beschreibt.

Das Framework an sich ist übersichtlich, jedoch sehr formal. Im originalen Scrum- Guide werden drei Rollen, fünf Ereignisse/ Rituale und drei Artefakte/Dokumente beschrieben. In einem typischen Durchlauf sind alle drei Rollen involviert. Die Rolle Product Owner ist Herr über das Produkt und dessen Anforderungskatalog und sie ist verantwortlich für die Arbeit des Ent- wicklungsteams. Die Einhaltung der Scrumregeln überwacht die Rolle Scrum Master. Er sorgt auch für ein entsprechendes Bewusstsein bei allen Beteiligten und verbessert das Scrum Framework. Vor allem bei Interaktionen zwischen dem Scrum Team und externen Stakeholdern hat er zu moderieren. Er wird oft als Servant Leader bezeichnet, der unterstützt, trainiert und schützt. Funktioniert Scrum, hat er sich überflüssig gemacht. Schließlich ist da noch die Rolle des Entwicklungsteams, dass für die Erstellung des nächsten Produktinkrements notwendig ist. Das erste Artefakt ist das Product Backlog. Es beinhaltet die Anforderungen an das Produkt und wird vom Product Owner verantwortet. Er sorgt für klar formulierte Einträge, die Priorisierung und Verständlichkeit. Das Artefakt Sprint Backlog (Prognose der Funktionalitäten im nächsten Inkrement) ist ein Auszug des Product Backlog und wird vom Entwicklungsteam verwaltet. In ihm stehen zusätzliche Informationen. Das letzte Artefakt ist das Produktinkrement selbst.

Alle Artefakte haben die Aufgabe, Transparenz, Überprüfbarkeit und Anpassbarkeit zu gewährleisten. Und sie sind allen Interes- sengruppen jederzeit zugänglich. Aktualität, Richtigkeit und Detailliertheit sind Voraussetzung. Am Anfang jedes Sprints (Ritual 1) gibt es eine Sprint-Planungssitzung (Ritual 2), geleitet vom Scrum Master. Während des Sprints wird das neue und potenziell nutzbare Inkrement erstellt. Der Scrum Guide sieht hier eine immer gleiche Timebox (zeitliche Vorgabe) von maximal einem Monat vor. In der täglichen Sitzung, dem Daily Scrum (Ritual 3), wird die Arbeit des Entwicklungsteams der nächsten 24 Stunden geplant und synchronisiert. Die Zeitvorgabe beträgt lediglich 15 Minuten, immer zur selben Uhrzeit. Am Ende jedes Sprints wird ein Sprint Review (Ritual 4) abgehalten, um das Produktinkrement zu überprüfen. Hierbei wird ggf. das Product Backlog angepasst. Das Sprint-Review ist ein informelles Meeting und hat eine Zeitvorgabe von maximal vier Stunden. Der Product Owner lädt das Scrumteam und die jeweiligen Interessenvertreter dazu ein. Der Scrum Master ist für Organisation und Vorbereitung der Teilnehmer verantwortlich. Hier wird das Produktinkrement beurteilt. Es muss allen Anforderungen aus allen vorhergehenden Sprints genügen und in einem einsatzfähigen Zustand sein. In der Sprint Retrospektive (Ritual 5), also dem Rückblick nach einem Sprint, gilt es, Verbesserungsmöglichkeiten für zukünftige Sprints zu ermitteln. Der Rückblick findet zwischen dem Sprint-Review und der nächsten Sprint-Planungssitzung statt. Die Vorgabezeit beträgt maximal drei Stunden. Auch hier ist der Scrum Master für Durchführung und Sinnverständnis verantwortlich.

Kanban als visuelles System

Ein ähnliches Framework ist Kanban als visuelles System zur Verwaltung von Tätigkeiten während eines Prozesses. Kanban visualisiert sowohl den Prozess (den Workflow) als auch die tatsächliche Arbeit, die diesen Prozess durchläuft. Das Ziel von Kanban ist es, potenzielle Engpässe im Prozess zu identifizieren und zu beheben, damit die Arbeit kostengünstig und mit optimaler Geschwindigkeit oder optimalem Durchsatz durchgeführt werden kann. Der Ursprung von Kanban liegt in den frühen 1940er Jahren. Das erste Kanban- System wurde von Taiichi Ohno für Toyota in Japan entwickelt. Es wurde als einfaches Planungssystem angefertigt, dessen Ziel es war, Arbeit und Lagerbestand in jeder Phase der Produktion optimal zu steuern und zu verwalten. Besondere Aufmerksamkeit liegt auf Engpässen, die den Produktionsprozess verlangsamen könnten. Ziel ist es, höheren Durchsatz bei geringeren Lieferzeiten zu erzielen. Im Laufe der Zeit entwickelte sich Kanban zu einem effizienten Weg in zahlreichen Produktionssystemen.

Während Kanban von Taiichi Ohno in der Fertigungsindustrie eingeführt wurde, war es David J. Anderson, der das Konzept 2004 als erster auf IT, Softwareentwicklung und Wissensarbeit im Allgemeinen anwendete. Anderson baute auf den Arbeiten von Taiichi Ohno auf. Eliyahu Goldratt, Edwards Deming, Peter Drucker und andere definieren die Kanban-Methode mit Konzepten wie Pull-Systemen, Warteschlangentheorie und Flow. Andersons erstes Buch über Kanban ("Kanban: Erfolgreicher evolutionärer Wandel für Ihr Technologieunternehmen"), das 2010 veröffentlicht wurde, ist die umfassendste Definition der Kanban-Methode für die Wissens- arbeit. Die Kanban-Methode folgt dabei einer Reihe von Grundsätzen und Praktiken zur Steuerung und Verbesserung des Arbeitsflusses. Es ist eine evolutionäre, unterbrechungsfreie Methode, die schrittweise Verbesserungen der Prozesse eines Unternehmens fördert. Er beschrieb vier Grundprinzipien und sechs Kernpraktiken, die Unternehmen in ihre Arbeitsweise inte- grieren, wenn sie Kanban anwenden:

Beginne mit dem, was du gerade tust. Man beendet die aktuelle Arbeit, bevor etwas Neues begonnen wird. Kanban kann einfach eingeführt werden.
Vereinbare, dass evolutionäre Veränderung verfolgt wird. Weiterentwicklung und Verbesserungen durch kleine/evolutionäre Schritte.
Respektiere initial bestehende Prozesse/Rollen/Verantwortlichkeiten. Bei der Einführung bleiben alle bestehenden Rollen, Prozesse etc. bestehen.
Ermutige dazu, Führung auf jeder Ebene der Organisation zu zeigen. Verbesserung gelingt nur, wenn alle Ebenen in der Organisation involviert sind. Direkt an der Arbeit beteiligte Mitarbeiter müssen "Acts of Leadership" zeigen und konkrete Verbes- serungsvorschläge einbringen.

Kanban legt großen Wert darauf, dass nicht sofort Änderungen am vorhandenen Prozess vorgenommen werden. Erforderliche Änderungen können über einen bestimmten Zeitraum hinweg schrittweise in einem Tempo erfolgen, mit dem das Team vertraut ist. Es sollen kleine inkrementelle Veränderungen vorgenommen werden, um keinen Widerstand innerhalb des Teams und der

Organisation zu erzeugen. Im Gegensatz zu anderen Methoden führt Kanban selbst keine organisatorischen Änderungen durch. Es ist daher nicht erfor- derlich, Änderungen an vorhandenen Rollen und Funktionen vorzunehmen, die mögli- cherweise eine gute Leistung erbringen. Das Team identifiziert und implementiert gemeinsam alle erforderlichen Änderungen.

Die Kernpraktiken der Kanban-Methode:

Visualisiere den Arbeitsfluss: Die Wertschöpfungskette mit ihren Pro- zessschritten wird für alle visualisiert. Ein Kanban-Board hilft hierbei. Die einzelnen Anforderungen werden auf Karteikarten oder Haftnotizen festge- halten und durchwandern mit der Zeit als so genannte Tickets das Kanban-Board von links nach rechts.

Begrenze die Menge angefangener Arbeit: Die Anzahl der Tickets ist limitiert. Wenn z.B. die Programmierung gerade zwei Tickets bearbeitet und das Limit für diese Station zwei beträgt, darf sie kein drittes Ticket annehmen. Hierdurch entsteht ein Pull-System, bei dem sich jede Station ihre Arbeit bei der Vorgängerstation abholt, anstatt fertige Arbeit einfach an die nächste Station zu übergeben.
Miss und steuere den Fluss: Die Längen von Warteschlangen, Zykluszeit und Durchsatz zeigen, wie gut die Arbeit organisiert ist, wo etwas verbessert werden kann und welche Versprechen man an die Partner geben kann, für die man arbeitet. Dadurch wird die Planung erleichtert und die Verlässlichkeit gesteigert.
Mache die Regeln für den Prozess explizit: Um sicherzustellen, dass alle Beteiligten des Prozesses wissen, unter welchen Annahmen und Gesetzmäßigkeiten man arbeitet, werden möglichst alle Regeln, die es gibt, explizit erstellt.
Implementiere Feedbackzyklen: In festgesetzten Terminen gibt sich das Team gegenseitig Feedback. Retrospektiven, Stand-up-Meeting oder Operation-Reviews helfen dabei, Erfahrungen auszutauschen.
Verwende Modelle, um Chancen für kollaborative Verbesserungen zu erkennen: Modelle sind Vereinfachungen des Prozesses. Sie helfen, ein besseres Prozessverständnis zu erreichen und Experimente zu finden, die zu einer Verbesserung des Prozesses führen.

Die Visualisierung und die Begrenzung der Arbeit sind einfache Mittel, mit denen sichtbar wird, wie die Tickets die verschie- denen Stationen durchlaufen und wo sie sich stauen. Die Stellen, vor denen sich Tickets häufen, werden als Bottlenecks bezeichnet. Durch Analysen des Kanban- Boards können immer wieder Maßnahmen ergriffen werden, um einen möglichst gleichmäßigen Fluss zu erreichen.

Fazit

Der Einsatz eines agilen Frameworks macht aus einem Sachbearbeiter noch keinen Designer. Es gibt keine Garantie für Geschwindigkeit, Transparenz, Resonanz und für Kreativität. Es löst auch keine Probleme, aber das tut auch keine andere Methode. Mit einer anspruchsvollen inneren Haltung, fachlicher Expertise und genug Übung kann ein agiles Framework helfen, kurzzyklische (Teil-)Ergebnisse zu liefern und Mitarbeitern notwendige Verantwortung zu übergeben. Ob die Ergebnisse wirksam sind und ob Verantwortung angenommen wird, hängt jedoch nicht vom Framework ab. Allen agilen Methoden gemeinsam ist die inkrementelle und iterative Vorgehensweise sowie die Fokussierung auf Selbstorganisation. Für wen welches Framework geeignet ist, hängt von mehreren Faktoren – aber auch vom persönlichen Geschmack – ab. Sicherlich ist Kanban das ungezwungenste Framework, denn damit kann in bestehenden Strukturen einfach begonnen werden. Scrum bedingt den Aufbau einer dazu passenden Organisation.

Agile Frameworks sind damit eben auch nur Ansätze, die ohne eine entsprechende Haltung wirkungslos bleiben. Erfolgreiche Unternehmen bedienen sich nicht singulärer Methoden, sondern haben als Basis immer eine bestimmte Kultur.

Literaturempfehlung, Quellen und Bildnachweis

Anderson, Davis J. / Carmichael, Andy:

Kanban: Successful Evolutionary Change for Your Technology Business

Auflage 1, Sequim, Blue Hole Press, 2010 (ISBN-10 0984521453, ISBN-13 978-0984521456)

Schwaber, Ken:

The Enterprise and Scrum

Auflage 1, Redmond, Microsoft Press, 2007 (ISBN-10 0735623376, ISBN-13 978-0735623378)

Nonaka, Ikujirō und Takeuchi, Hirotaka:

Die Organisation des Wissens: Wie japanische Unternehmen eine brachliegende Ressource nutzbar machen

Auflage 2, Frankfurt am Main, Campus Verlag, 2012 (ISBN-10 9783593396316, ISBN-13 978-3593396316)

Kelley, Tom:

The Art Of Innovation: Lessons in Creativity from IDEO, America's Leading Design Firm

Auflage 1, New York, Random House Inc., 2001 (ISBN-10 0385499841, ISBN-13 978-0385499842)

Faste, Rolf:

Ambidextrous Thinking

Stanford, Innovations in Mechanical Engineering Curricula for the 1990s, American Society of Mechanical Engineers, November 1994

Tags: Scrum, Kanban, Design Thinking, Visual Thinking, Development, Visual system, Framework, Agil, Agility, Transformation, Methode