Direkt zum Hauptbereich

Design Thinking, Scrum und Improvement Kata im Vergleich

Ein aufmerksamer Leser hat uns Feedback zu unserem Buch "Unternehmenssoftware einführen" (https://leanpub.com/unternehmenssoftwareagileinfuehren/) gegeben. In der Diskussion kam die Frage auf: "Wie unterscheidet sich Euer Vorgehen mit Scrum eigentlich von Design Thinking oder Verbesserungs-Kata?" Eine gute Gelegenheit für einen Blogbeitrag.

Bevor wir die Begriffe vergleichen können, sollten wir klarstellen, was mit ihnen gemeint ist.

Was ist Scrum?

Scrum ist die populärste agile Arbeitsweise. Scrum versteht sich als Arbeitsrahmen für Teams, der gut für unsichere Ausgangssituationen geeignet ist. Scrum ist eine Feedbackmaschine. Durch das Feedback aus kurzen Arbeitszyklen findet das Team den richtigen Weg heraus. Softwareentwicklung ist ein Beispiel für solche Situationen. Deswegen ist Scrum dort auch sehr verbreitet.

Um das Feedback zu organisieren, pflegt der Auftraggeber (der sog. Product Owner) eine Liste sowohl mit konkreten als auch mit groben Ideen (das sog. Product Backlog). Die Ideen, die ihm am wichtigsten sind, werden nach oben priorisiert und feiner ausgearbeitet (Refinement). Der Auftraggeber trifft sich in regelmäßigen Abständen mit einem Team, das ihm hilft, die Ideen umzusetzen. Dabei wird darauf geachtet, dass das Team verschiedene Kompetenzen abdeckt, um als ganzes Team Dinge abschließen zu können.

Es gibt ein Planungsmeeting, bei dem die Aufgaben bis zum nächsten Treffen besprochen und konkret geplant werden (das sog. Sprint Planning, in dem das Sprint Backlog erstellt wird). Es gibt ein Auswertungsmeeting, bei dem sich Product Owner und Team die fertigen Arbeiten (das sog. Inkrement) ansehen und prüfen, ob der eingeschlagene Weg richtig ist oder ob nachgesteuert werden muss (der sog. Sprint Review). Anschließend setzt man sich zusammen, um die Arbeitsabläufe konkret zu verbessern (Sprint Retrospektive). Die Rolle Scrum Master achtet darauf, dass alle Beteiligten die neuen Regeln der Zusammenarbeit kennen und einhalten, ohne aber Scrum-Polizist zu sein.

Scrum wurde von Jeff Sutherland und Ken Schwaber entwickelt und populär gemacht. Der Scrum Guide listet die Spielregeln auf und ist kostenlos in verschiedenen Sprachen verfügbar: www.scrumguides.org. Scrum ist übrigens keine Abkürzung, sondern bedeutet im Englischen einfach Gedränge.

Was ist Design Thinking?

Design Thinking ist eine Vorgehensweise, die ursprünglich von Mitarbeitern der Design- und Innovationsberatungsfirma IDEO entwickelt wurde, um kreative Lösungen für schwierige Probleme zu finden. Als Entwickler gilt vor allem David Kelley, einer der Gründer von IDEO. Tim Brown, ebenfalls von IDEO, hat ein wichtiges Buch über Design Thinking ("Change by Design") geschrieben.

Viele Menschen halten sich nicht für besonders kreativ. David Kelley konnte beobachten, wie ein bekannter Psychologe Patienten mit Phobien behandelt hat. Schlüssel zum Erfolg war ein schrittweiser Prozess. Kelley und andere haben mit Design Thinking einen Prozess entwickelt, mit dem JEDER Mensch kreative Lösungen entwickeln kann:
  • Verstehe die Menschen, beobachte sie, sammle Daten. Entwickle Empathie für ihre Lage, um das wirkliche Problem zu verstehen.
  • Entwickle Idee und baue einfache Prototypen.
  • Teste Deine Ideen, sammle Daten und verbessere die Lösungen.
Während die meisten unter Design eine praktische und ästhetische Gestaltung von Gegenständen oder Prozessen verstehen, geht Design Thinking weiter. Weg vom Objekt, hin zur Gesamtlösung.

Bei Design Thinking ist es wichtig, dass man verschiedene Sichtweisen im Raum hat, um eine gute Lösung zu finden, die sowohl erstrebenswert, als auch technisch machbar und bezahlbar ist.

IDEO hat übrigens eine eigene Seite zu Design Thinking zusammengestellt: https://designthinking.ideo.com/

Was ist mit Katas gemeint?

Der Begriff Kata kommt aus dem Japanischen und steht für Bewegungsabfolgen bei Kampfsportarten wie Aikido oder Karate, die detaillierter festgelegt sind. Mike Rother hat die Begriffe Verbessungs-Kata und Coaching-Kata geprägt, nachdem er genauer untersucht hat, wie die Mitarbeiter und Führungskräfte bei Toyota Prozesse verbessern. In der Einzahl heißt es übrigens "die Kata".

Beim Beobachten hat Mike Rother festgestellt, dass die Mitarbeiter in der Produktion bei Toyota immer den gleichen Schritten folgen, wenn sie Dinge verbessern wollen. Aus dem Lean Management kennen wir viele Einzeltechniken, die bei Toyota entwickelt wurden, z. B. Kanban-Systeme, Kamishibai-Boards oder Heijunka-Boxen. Toyota hat aber nicht einfach Kanban erfunden. Stattdessen suchte man nach einer einfachen Lösung, den Umgang mit Nachschub zu regeln. Und es war auch nicht so, dass einfach einer auf die richtige Idee kam. Und es ist auch nicht, dass ein einmal eingeführtes Kanbansystem immer so bleibt.

Wenn es bei Toyota etwas zu verbessern gibt, wird zunächst ein Zielzustand definiert. Dann findet das Team heraus, was eigentlich der aktuelle Zustand ist. Anschließend macht man Experimente, um näher an den Zielzustand heranzukommen. Das kann durchaus Monate oder Jahre dauern. Wenn der Zielzustand erreicht ist, sucht man sich einen neuen Zielzustand und das Spiel geht von vorne los. Im Kern ist es also wissenschaftliches Arbeiten: Problem definieren, Situation genau beobachten, Daten sammeln, Experimente machen, weiter verbessern. Hier treffen wir auch den berühmten PDSA-Zyklus (auch Deming-Cycle genannt) wieder.

Wieso heißt es Kata? Mike Rother hat festgestellt, dass diese Arbeitsweise so gut eingeübt ist, dass die Mitarbeiter es nicht einmal merken. Sie heißt auch bei Toyota nicht so. Sie hat wahrscheinlich gar keinen besonderen Namen dort. Aber sie ist erlernt und wenn Toyota neue Fabriken aufmacht oder Produktionsstätten übernimmt, fehlen häufig gute Führungskräfte, die mit den anderen Führungskräften und Mitarbeitern die Verbesserungs-Kata üben.

Mike Rother hat auf seiner Webseite viel Material zur Verfügung gestellt: http://www-personal.umich.edu/~mrother/Materials_to_Download.html

Sehr gut ist aber auch sein Kata-Buch (in deutscher oder in englischer Sprache):
  • Rother, Mike ; Kinkel, Silvia: Die Kata des Weltmarktführers : Toyotas Erfolgsmethoden. 2. Aufl.. Frankfurt am Main: Campus Verlag, 2013.
  • Rother, Mike: Toyota Kata: Managing People for Improvement, Adaptiveness and Superior Results. Madison: McGraw Hill Professional, 2009.
Das E-Book zur deutschen Ausgabe gibt es übrigens nur über die Verlagswebseite.

Wann nutzt man was?

Scrum, Design Thinking und Verbesserungs-Kata arbeiten iterativ. Man arbeitet schrittweise auf einen guten Zielzustand hin:
  • Scrum liefert alle zwei Wochen ein neues Product Inkrement, bis das Produkt gut genug ist.
  • Bei Design Thinking baut immer wieder neue Prototypen, bis man eine gute Lösung gefunden hat.
  • Mit der Verbesserungs-Kata wird ein Ablauf immer wieder angepasst, bis ein guter Zielzustand erreicht wurde.
Alle drei Arbeitsweisen verlangen das Sammeln von echten Daten und ein wirkliches Einarbeiten in die Problemlage. Sind sie also austauschbar?

Nein, sind sie nicht. Jede Vorgehensweise wurde für eine bestimmte Situation entwickelt. Ich würde die Benutzungsreihenfolge so definieren: Design Thinking --> Scrum --> Verbesserungs-Kata.
  • Mit Design Thinking erarbeite ich mit künftigen Nutzern eine Idee, wie eine gute Lösung überhaupt aussehen soll. Es gibt einen oder ein paar Workshops und dann hört Design Thinking wieder auf.
  • Mit Scrum entwickle ich mit einem interdisziplinären Team ein konkretes Produkt für die Lösung. Häufig wird dafür ein Projekt aufgesetzt. Input für das Projekt sind die Ideen aus den Design Thinking Workshops, Output ist das fertige Produkt.
  • Wenn die Lösung in Betrieb ist, kann ich mich mit Katas weiter verbessern. Input ist das fertige Produkt bzw. die neuen Prozesse. Output sind die erreichten vereinbarten Zielzustände.
Der Anlass zu diesem Beitrag war eine Diskussion darüber, wie man Unternehmenssoftware einführt.

Im o. g. Buch nutzen wir Scrum als Arbeitsrahmen, um Unternehmenssoftware in eine Organisation einzuführen. Ob eine neue Software grundsätzlich eine gute Lösung ist, dafür setzt man eher einen oder mehrere Design Thinking Workshops an. (Nun ja, die Design Thinker unter den Lesern dieses Blog würden wahrscheinlich protestieren und sagen, dass für so ein profanes Problem die Design Thinking Zeit zu schade ist.) Wenn die neue Software im Betrieb ist und das Team für die Lösungsentwicklung aufgelöst wurde, dann können die Nutzer die Verbesserungs-Kata einüben, um auch den laufenden Prozess weiter zu verbessern.

Kommentare

Beliebte Posts aus diesem Blog

Microsoft Teams: Die neuen Besprechungsnotizen - Loop-Komponenten

  Haben Sie in letzter Zeit in einer Teams-Besprechung die Notizen geöffnet? Dort sind inzwischen die Loop-Komponenten hinterlegt. Die sind zwar etwas nützlicher als das, was zuvor zur Verfügung stand. Trotzdem ist noch Luft nach oben. Und es gibt sogar einige ernstzunehmende Stolperfallen. Hier ein erster, kritischer Blick auf das was Sie damit tun können. Und auch darauf, was Sie besser sein lassen.

Agile Sternbilder: Die Entdeckung kosmischer Agilitäts-Superkräfte

Hast du dich je gefragt, ob dein Sternzeichen deine Fähigkeiten in einer agilen Arbeitsumgebung beeinflusst? In diesem Blogpost tauchen wir ein in die faszinierende Welt der Astrologie und ihre mögliche Verbindung zu modernen Arbeitsweisen. Entdecke, wie die Sterne deine agilen Stärken prägen könnten. Ob überzeugter Agilist oder neugieriger Sternzeichenliebhaber – dieser Artikel kann dir neue Perspektiven eröffnen und vielleicht sogar dein nächstes Teamprojekt inspirieren!

Den passenden Job finden

Hier teile ich, wie ich daran arbeite, endlich den richtigen Job zu finden. Kleingedrucktes: Dieser Artikel richtet sich (natürlich) an jene, die gerade in der luxuriösen Position sind, dass sie nicht jedes Angebot annehmen müssen. Anstatt von Engagement zu Engagement zu hetzen und frustriert zu sein über Konzernstrukturen, fehlende Ausrichtung und die Erkenntnis, dass in einem selbst beständig die Hintergrundfrage nagt, ob es das ist, womit man seine immer knapper werdende Lebenszeit wirklich verbringen möchte, gibt es manchmal auch die Möglichkeit, die nächste berufliche Station etwas nachhaltiger auszusuchen - auch, um tatsächlich (etwas) mehr beitragen zu können.

Die Microsoft Teams-Not-To-Do-Liste

Viele hoffen, dass es  für die Einrichtung von Microsoft Teams  den Königsweg gibt, den perfekten Plan – doch den gibt es leider (oder glücklicherweise?) nicht. Genauso wenig, wie es jemals einen Masterplan für die Organisation von Gruppenlaufwerken gab, gibt oder je geben wird. Was gut und vernünftig ist hängt von vielen Faktoren und ganz besonders den Unternehmensprozessen ab. Sicher ist nur eines: Von alleine entsteht keine vernünftige Struktur und schon gar keine Ordnung. Dafür braucht es klare Entscheidungen.

Agilität ist tot. Ausgerechnet jetzt?

Agilität wird zurückgefahren, Hierarchien kehren zurück. Doch ist das wirklich der richtige Weg in einer Welt, die immer unberechenbarer wird? Oder erleben wir gerade eine riskante Rolle rückwärts?

Wie beschreibt man einen Workshop für eine Konferenz?

Konferenzen bieten immer ein gutes Forum, um sein Wissen und seine Erfahrungen zu teilen. Was für die Vortragenden selbstverständlich scheint, ist für die Besucher:innen oft unverständlich. Wie können Vortragende ihren Workshop in 2-3 Sätzen beschreiben, damit die Besucher:innen schnell einschätzen können, er sich für sie lohnt?

Gemeinsam eine Anwenderdokumentation erstellen

Unternehmenssoftware ist ein wichtiges Bindeglied zwischen Anwenderinnen und Anwendern, den Unternehmensprozessen und den Ergebnissen. Normalerweise schreibt der Hersteller der Software die Dokumentation für diejenigen, die die Software benutzen. Wenn die Software allerdings stark angepasst wurde, muss die Dokumentation von denen kommen, die die Prozessmaschine am besten verstehen - den Anwenderinnen und Anwendern. Wie könnte man das praktisch machen?

Der Softwareeisberg, die Softwarepyramide - Wie sprechen wir über neue Software?

Software ist aus den Geschäftsprozessen vieler Unternehmen nicht mehr wegzudenken. Sie verwaltet Kunden- und Produktdaten. Sie automatisiert Abläufe und verhindert Fehler. Aber Software veraltet. Was machen wir, wenn wir Unternehmenssoftware erneuern müssen? Von den ersten Konzepten bis zum ersten Release ist es ein weiter Weg, mit vielen Entscheidungen. Wie sprechen wir über diese Entscheidungen?