Читать книгу: «Kanban»

Vorwort

Kanban ist einerseits schon lange bekannt und liegt dennoch weiterhin mehr im Trend als je zuvor. Wer heutzutage Projekte managt, sich mit dem Thema Projektmanagement oder Changemanagement auseinandersetzt, kommt um neue Methoden, wie man zusammenarbeitet, nicht mehr drum herum. Sei es Scrum als Projekt- und Produktentwicklungsmethode, die seit nunmehr über 20 Jahren in den verschiedensten Bereichen angewandt wird, oder andere Methoden wie Design Thinking, LeanStartup, Leanmanagement oder Kanban. Das Schlagwort für all diese Methoden lautet Agilität.

Das agile oder flexible Arbeiten stellt einen fundamentalen Wandel in der Art, wie wir arbeiten, dar und stellt uns dadurch vor Herausforderungen. Der Taylorismus – also die Idee, dass Aufgaben von oben herab in kleine durchführbare Arbeitsschritte gefasst werden und nur von den Mitarbeitern ausgeführt werden und dies einfach kontrolliert werden kann – kommt in einer modernen Welt immer mehr an seine Grenzen. Das gilt ebenso für das klassische Wasserfallmodell.

Mittlerweile sind sich selbstmanagende Teams eine Selbstverständlichkeit. Der zunehmend dynamische Wandel, die stetig wachsende Globalisierung und auch der immer anspruchsvollere Kunde, der eine maßgeschneiderte Lösung für seine Bedürfnisse verlangt, sorgen dafür, dass man nicht mehr Jahre im Voraus planen kann, sondern sich flexibel auf die Bedürfnisse seiner Kunden einstellen muss, um diese schnell zu bedienen. Um diese Bedürfnisse der Kunden bestens zu befriedigen, müssen diejenigen, die die Fähigkeiten haben, den Service oder das Produkt zu liefern, die Kompetenz oder Fähigkeiten besitzen autonom zu agieren.

Die Kompetenz verlagert sich also heutzutage immer mehr weg vom Manager hin zum Team und zum einzelnen Mitarbeiter, um die besten Produkte oder Services zu liefern.

Kanban wurde 2007 von David J. Anderson entwickelt und erfreut sich neben Scrum als beliebte Alternative, um Produkte zu entwickeln, Services zu optimieren oder um ganze Organisationen dabei zu unterstützen sich kontinuierlich zu verbessern. Dabei reichen die Wurzeln von Kanban zurück bis in die 1950er Jahre bei Toyota. Um das Thema Kanban hat sich eine große Community gebildet.

Es existiert eine Vielzahl an Literatur, Beratern und Experten rund um dieses Thema. Die Essenz von Kanban wird dabei in einem Kanban-Guide herausgegeben, der die wesentlichen Grundideen von Kanban erklärt und darstellt. In unserem Buch möchten wir dir diese Grundideen genauer vorstellen und unsere Erfahrung aus unserer täglich gelebten Beraterpraxis einfließen lassen. Kanban kann sowohl in der agilen Welt als auch in einem klassischen Arbeitsumfeld angewendet werden, um die Organisation kontinuierlich weiterzuentwickeln.

Unsere Erfahrungen und unser Praxiswissen haben den Aufbau und die Struktur dieses Buchs beeinflusst. Wir haben das Buch in folgende Kapitel gegliedert:

Warum ist Kanban erfolgreich?

Die Wurzeln von Kanban

Kanban in der Praxis

Wozu ist Kanban in der Praxis anwendbar?

Das Buch beginnt damit, warum Kanban erfolgreich ist und warum Kanban eine gute Möglichkeit ist, dich bei deiner Arbeit zu unterstützen.

Im zweiten Kapitel geben wir einen Überblick darüber was Kanban ist, welche Prinzipien von Kanban und welche Praktiken es in Kanban gibt.

Das dritte Kapitel erläutert, wie Kanban funktioniert: Wie du die Arbeit visualisierst, die Arbeit limitierst, wie du die Arbeit fließen lässt, welche Meetings es in Kanban gibt und wie du dich inkrementell weiterentwickelst.

Das letzte Kapitel zeigt dir, wie du Kanban in der Praxis anwenden kannst, und gibt dir Ideen an die Hand, wie du deine Arbeit visualisieren kannst. Auch gehen wir kurz auf die Unterschiede und die Gemeinsamkeiten von Scrum und Kanban ein. Zudem zeigen wir dir noch Spiele, mit denen du Kanban greifbarer machen und danach das spielerisch Gelernte in die Praxis umsetzen kannst.

In diesem Buch verzichten wir aus Gründen der besseren Lesbarkeit auf Doppelbezeichnungen und verwenden das generische Maskulinum. Diese Formulierung bezieht sich ausdrücklich auch auf weibliche und anderweitige Geschlechteridentitäten.

Wie du bereits gemerkt hast, duzen wir unsere Leser. Wir sind der Meinung, dass in der aktuellen schnellen Welt, in der wir leben, das „Du“ einfacher zu schreiben und zumindest hier in diesem Buch die richtige Wahl ist.

Solltest du Fragen haben, kannst du dich jederzeit gerne an uns wenden!

Dieses Buch sowie seine Aktualität und Weiterentwicklung leben von der Kommunikation mit euch. Deswegen freuen wir uns auf eure Anregungen, Anmerkungen und Verbesserungsvorschläge.

Fabian Kaiser fkaiser@agile-heroes.de

Roman Simschek rsimschek@agile-heroes.de

Wir sind auch telefonisch erreichbar unter 069 242 476 70.

Wir wollen an dieser Stelle Tom Euler danken, der in hervorragender und engagierter Weise uns bei der strukturellen und inhaltlichen Erstellung dieses Buch unterstützt hat. Ohne ihn wäre dieses Buch nicht möglich gewesen.

Herzlichen Dank und viel Erfolg

Roman SimschekFabian Kaiser

Frankfurt, Dezember 2020

Video anschauen: Vorwort

In diesem Video gibt der Autor Roman Simschek eine Einführung und einen Überblick über den Aufbau und die Struktur des Buchs.

http://agile-heroes.de/buch/kanban

Inhaltsübersicht

1Warum ist Kanban so erfolgreich?

2Was ist Kanban?

3Wie funktioniert Kanban?

4Wozu Kanban in der Praxis anwenden?

Glossar: Welche Begriffe sind wichtig?

Lösungen der Übungsfragen

Gute Informationsquellen und Literatur

Index

Inhalt

Vorwort

Abbildungsverzeichnis

1Warum ist Kanban so erfolgreich?

1.1Das Erfolgsgeheimnis von Kanban

1.2Der Unterschied zwischen Wasserfall und agilen Methoden

1.2.1Der Unterschied zwischen Wasserfall und Agile

1.2.2Agiles Projektmanagement mit Kanban

1.2.3Hybrides Projektmanagement

1.2.4Kanban die Ausnahme von der „Regel“?

1.2.5Das agile Manifest als Basis agiler Vorgehensmodelle

1.2.6Die vier Wertepaare des Agilen Manifests

2Was ist Kanban?

2.1Die drei Prinzipien von Kanban

2.2Die sechs Praktiken von Kanban

2.3Die Kanban-Werte

2.4Die drei Kanban-Agenden

2.5Rollen in Kanban

2.5.1Der Service Request Manager

2.5.2Der Service Delivery Manager

3Wie funktioniert Kanban?

3.1Visualisierungen der Arbeit

3.1.1Wie das Board sichtbar machen?

3.2Limitierung von WiP-Limits

3.2.1Wie finde ich heraus, ob mein WiP-Limit zu hoch oder zu niedrig ist?

3.2.2Kein WiP-Limit ist auch keine Lösung

3.2.3Das richtige WiP-Limit finden

3.2.4Verteilung der WiP-Limits

3.2.5Die Silos aufbrechen

3.2.6WiP-Limit auf Personen setzen

3.2.7Aufgaben oder Unteraufgaben limitieren

3.2.8Flow etablieren

3.3Wie sehen die Kanban-Tickets aus?

3.2.9Avatare

3.4Weitere Vorteile von WiP-Limits

3.5Engpässe sichtbar machen und vermeiden

3.6Umgang mit Engpässen

3.7Größe des Backlogs bzw. Input-Queue

3.8Limits für verschiedene Aufgaben

3.9Service-Klassen

3.9.1Die Service-Klasse „Beschleunigt“

3.9.2Die Service-Klasse „Fixtermin“

3.9.3Die Standardklasse

3.9.4Die Service-Klasse „Unbestimmbare Kosten“

3.9.5Kapazitäten von Service-Klassen

3.10Service Level Agreements

3.11Meetings in Kanban

3.11.1Das Daily Standup Meeting

3.11.2Dailys in Kanban

3.11.3Unterschiede zu traditionellen Standup-Meetings in Kanban

3.11.4Queue Replenishment Meeting

3.11.5Release Meeting

3.11.6Operations Review

3.11.7Retrospektive

3.12Verbesserungspotenzial feststellen durch Metriken

3.12.1Cycle Time und Lead Time

3.12.2Wie werden Cycle Time und Lead Time gemessen?

3.12.3Durchsatz

3.12.4Wie wird der Durchsatz gemessen?

3.12.5Blockaden und Probleme messen

3.12.6Das kumulative Flussdiagramm

4Wozu Kanban in der Praxis anwenden?

4.1Anwendungsfelder von Kanban

4.1.1Ideen zur Visualisierung

4.2Kanban-Spiele

Glossar: Welche Begriffe sind wichtig?

Lösungen der Übungsfragen

Gute Informationsquellen und Literatur

Index

Abbildungsverzeichnis

Abb. 1: Was macht Kanban erfolgreich?

Abb. 2: Klassisches Projektmanagement

Abb. 3: Agiles Projektmanagement

Abb. 4: Wertpaare des Agilen Manifests

Abb. 5: Prinzipien des Agilen Manifests

Abb. 6: Die Kanban-Prinzipien

Abb. 7: Die Praktiken von Kanban

Abb. 8: Die Kanban-Werte

Abb. 9: Die Kanban-Agenden

Abb. 10: Die Kanban-Rollen

Abb. 11: Das Kanban-Board

Abb. 12: Limits setzen durch Avatare und Swimlanes

Abb. 13: Ticket-Design

Abb. 14: Metriken für dieTickets

Abb. 15: Probleme durch Visualisieren erkennen

Abb. 16: Engpässe sichtbar machen

Abb. 17: Umgang mit Engpässen

Abb. 18: Fokus durch WiP-Limits setzen

Abb. 19: Service-Klasse „Beschleunigt“

Abb. 20: Service-Klasse „Fixtermin“.

Abb. 21: Service-Klasse „Standard“

Abb. 22: Service-Klasse „unbestimmbare Kosten“

Abb. 23: Verlauf der Service-Klassen

Abb. 24: Lead und Cycle Time

Abb. 25: Die Durchsatzmessung

Abb. 26: Kumuliertes Flussdiagramm

Abb. 27: Einzelne Arbeitsaufgaben visualisieren

Abb. 28: Mehrere Arbeitsaufgaben visualisieren

Abb. 29: Visualisierung mit WiP-Limits

Abb. 30: Limitierung mit WiP-Limits und Avataren

Abb. 31: Limitierung durch In Arbeit und Fertig

Abb. 32: Externe Arbeit visualisieren

Abb. 33: Wartezeiten visualisieren

Abb. 34: Parallele Arbeiten visualisieren

Abb. 35: Software-Entwicklungsprozess visualisieren

Abb. 36: Tabelle des Münzspiels

1Warum ist Kanban so erfolgreich?

Was macht Kanban so erfolgreich? Beziehungsweise was macht Kanban als Agile Methode so gut, dass man sich damit auseinandersetzen sollte? Die Antwort ist sehr simpel: 1. Kanban ist einfach verständlich, 2. Es folgt sehr wenigen und einfachen Regeln und 3. Sind diese Regeln nicht in Stein gemeißelt.

1.1Das Erfolgsgeheimnis von Kanban
Kanban ist flexibel

Man kann Kanban als Richtlinie oder Richtschnur verstehen, die sich bei der praktischen Umsetzung als sehr nützlich erwiesen haben. Das heißt, wie du die Praktiken für ein Kanban-System umsetzt, liegt ganz bei dir. Wenn du nur wenige Praktiken von Kanban einführst, dann hast du eine leichte Version von Kanban, führst du hingegen alle Praktiken von Kanban ein, hast du eine sehr starke Version. Darüber entscheidest du oder dein Team selber. Es gibt hier keine Vorschriften, ab wann Kanban Kanban ist und wann nicht. Bei anderen Methoden wie z.B. Scrum ist der „Kodex das Gesetz“. So ist im so genannten Scrum Guide genau beschrieben, was Scrum ist und was nicht. Hierbei so konkret zu sein kann auch sehr sinnvoll sein und muss nichts Schlechtes bedeuten. Manchmal jedoch braucht man eher ein „Korsett“, das eben einen festen Rahmen geben kann, dich leitet und dir Orientierung geben kann. Manchmal jedoch brauchst du aber vielleicht ein etwas „weiteres Korsett“.

Wie du aber z.B. die Prinzipien umsetzt, ist dabei dir selbst überlassen. Die Dinge sind nicht in Stein gemeißelt; solltest du merken, dass die Visualisierung deines Systems nicht mehr richtig stimmt und den Prozess nicht in echt abbildet, zögere nicht und passe die Visualisierung an deinen bestehenden Prozess an.

Kanban bedeutet kontinuierliche Verbesserung

Kanban sorgt für kontinuierliche Verbesserung. Kanban hat nicht den Anspruch, dein Unternehmen kurzfristig zu ändern. Dies geschieht in kleinen Schritten. Es geht hier also um einen fortwährenden Prozess der Verbesserung. Dies sorgt dafür, dass du schnell Verbesserung einführen kannst. Der Wandel ist evolutionär und nicht revolutionär.

Kanban ist anpassungsfähig

Kanban ist agil. Du kannst Kanban auf jeder Ebene in deinem Unternehmen einführen. Du brauchst keine weitere Methode, die extra skaliert ist, um auch auf anderen Ebenen zu funktionieren. Dabei heißt das aber nicht, dass Kanban nicht mit anderen Methoden kompatibel ist. Sagen wir, deine Teams benutzen in der Entwicklung Scrum. Sehr gut, mache damit weiter, wenn das deinem Team hilft! Jetzt kannst du z.B. überlegen, ob du auf der Ebene der Abteilung Kanban einführen möchtest, um die Arbeit, die zu den verschiedenen Teams gelangt, besser zu koordinieren. Zusätzlich könntest du auch noch auf der Managementebene Kanban einführen. Kanban bietet hier einen Ansatz, um auf das gesamte Unternehmen angewandt zu werden.

Kanban ist agil

Die oben genannten Punkte machen Kanban zu einer sehr guten Agilen Methode. Durch die Flexibilität bei der Einführung von Kanban kannst du die Veränderung langsam einführen, um somit den Widerstand gegen die Veränderung zu minimieren. Gleichzeitig kannst du durch den Fokus auf kontinuierliche Verbesserung immer wieder getroffene Maßnahmen anpassen, verändern oder verwerfen – um so ein bestmögliches Ergebnis zu erreichen. All diese Punkte, warum Kanban funktioniert, macht Kanban als Methode selbst agil.

Abbildung 1: Was macht Kanban erfolgreich?

1.2Der Unterschied zwischen Wasserfall und agilen Methoden

Wenn man von agilem Projektmanagement oder agilen Methoden spricht, kommt man selten daran vorbei, diese mit der klassischen Vorgehensweise zu vergleichen. Letzteres wird oft als Wasserfallmethode bezeichnet. Da Kanban zu den agilen Methoden gehört, erläutern wir ihnen hier einen kurzen Überblick über die grundlegenden Unterschiede in den verschiedenen Vorgehensweisen.

1.2.1Der Unterschied zwischen Wasserfall und Agile

Wir wollen an dieser Stelle kurz die Unterschiede zwischen den beiden Methoden darstellen und auf ihre jeweiligen Vor- und Nachteile eingehen. Aus unserer Sicht ist es, wenn man sich mit Kanban beschäftigt, wichtig zu wissen, welche anderen grundsätzlichen Prinzipien und Methoden des Projektmanagements existieren. So kann man besser verstehen, was der Kern oder auch was das „Evolutionäre“ an Kanban ist. Wichtig ist uns hierbei, keine vergleichende Bewertung der beiden Modelle Wasserfall-Methode und Kanban vorzunehmen. Aus unserer Sicht haben beide Modelle ihre

Daseinsberechtigung. Jedes der beiden Modelle hat seine spezifischen Charakteristika und Einsatzbereiche. Oft ist es so, dass Anhänger von Kanban die Wasserfall-Methode als „alt“ bzw. „überholt“ betrachten.

Dieser Meinung wollen wir uns nicht anschließen. Es handelt sich lediglich um sehr unterschiedliche Ansätze, die jeweils ihre spezifischen Vor- und Nachteile haben. Was also ist der Unterschied zwischen der klassischen Methodik des Projektmanagements und Kanban?

Klassisches Projektmanagement nach der Wasserfall-Methode

Das Projektmanagement nach der Wasserfall-Methode erfolgt in mehreren Phasen. Dies bedeutet, dass ein Projekt in mehrere, sich von den jeweiligen Aufgaben unterscheidenden Phasen unterteilt wird. Hierbei folgt jede Phase auf eine andere, sprich eine Phase beginnt erst dann, wenn die vorherige Phase abgeschlossen ist. Die Planung und inhaltliche Ausgestaltung dieser Phasen erfolgen bereits zu Beginn des Projektes. Phasen werden erst dann gestartet, wenn die vorherige Phase abgenommen und dann abgeschlossen wurde.

Abbildung 2: Klassisches Projektmanagement

Ein weiteres Charakteristikum ist, dass die geplanten Phasen, so wie sie geplant wurden, auch sehr starr durchgeführt werden.

Dies bedeutet auf der einen Seite eine relativ hohe Planungssicherheit, auf der anderen Seite hingegen auch mangelnde Flexibilität. Gerade bei sehr großen, komplexen und umfangreichen Projekten ist es notwendig, diese Planungssicherheit zu haben und entsprechend auch nach der Wasserfall-Methode vorzugehen. Dies ist darin begründet, dass das Projekt einerseits eventuell international über mehrere Länder verteilt ist, und auch verschiedenste fachliche Bereiche im Projekt berücksichtigt werden.

Ein wesentlicher Nachteil der Wasserfall-Methode ist, dass sich Fehler in der Umsetzung im Rahmen des Projektes erst sehr spät in der Projektlaufzeit zeigen. Hier kann es dann durchaus vorkommen, dass im Rahmen der abgelaufenen Projektlaufzeit bereits Budget und Ressourcen investiert wurden, die, wie sich später herausstellt, nicht wirklich zielführend waren. Dieser Kritikpunkt ist auch einer der wesentlichen Treiber, der zu der Entwicklung agiler Methoden im Projektmanagement geführt hat.

Im Kern kann man sagen, dass im klassischen Projektmanagement sehr viel Wert auf Struktur, jedoch weniger Wert auf Flexibilität gelegt wird. Gerade in hierarchischen Unternehmensstrukturen ist es deshalb weiterhin sehr angesagt, Projekte nach klassischen Projektmanagementmethoden zu managen. Agile Methoden wie Kanban legen hingegen weniger Wert auf Struktur und setzen mehr auf Flexibilität.

1.2.2Agiles Projektmanagement mit Kanban

Agiles Projektmanagement setzt im Wesentlichen auf kurze und regelmäßige Entwicklungszyklen. So kann auf Veränderungen, insbesondere auch bezüglich der Anforderungen, die der Kunde an das Endprodukt stellt, schnell reagiert werden. Zudem kann schnell und kurzfristig angepasst werden. Hierdurch kann auch Marktfeedback schnell umgesetzt werden. Um dies in Kanban zu erreichen, setzt man den Fokus auf einen stetigen Arbeitsfluss. Welche Arbeitsaufgaben dabei umgesetzt werden wird im Replenishment-Meeting besprochen. Um schnell auf Veränderung – egal welcher Art – reagieren zu können ist Kommunikation innerhalb der Teams eine notwendige Voraussetzung. Dabei sollte der Austausch zwischen den Teammitgliedern und anderen Personen (Kunde, Stakeholder etc.) regelmäßig stattfinden. Dabei sollte die Kommunikation persönlich, direkt, interaktiv und regelmäßig auf Probleme, Engpässe, Blockaden oder Herausforderung eingehen, um diese zu lösen.

Das Hauptaugenmerk liegt hierbei also weniger in der Dokumentation als vielmehr in der schnellen Reaktion auf die Veränderungen. Agilität bzw. der Einsatz von Kanban bedeuten demnach, weniger Wert auf Strukturen zu legen, sondern mehr Flexibilität in einem Projekt zuzulassen. Dabei liegt die Annahme zu Grunde, dass das Projektteam soweit befähigt und motiviert ist, dass es mit dieser Flexibilität sehr gut umgehen kann und trotz Flexibilität des Projektziels beziehungsweise nicht aus den Augen verliert.

Abbildung 3: Agiles Projektmanagement

Agiles Projektmanagement ist wenig hierarchisch und setzt darauf, dass Teams sich selbst organisieren und selbst am besten wissen, wie die vorgegebenen Projektziele erreicht werden. Die vorstehende Abbildung zeigt einen typischen Aufbau eines agilen Projekts. Dabei wird hier das Produkt inkrementell, das bedeutet schrittweise und aufeinander aufbauend geliefert.

1.2.3Hybrides Projektmanagement

Gibt es auch Zwischenformen zwischen Klassischem Projektmanagement und Agilem Projektmanagement? Die Antwort ist ein klares Ja. Man nennt dies Hybrides Projektmanagement. Beim Hybriden Projektmanagement geht man davon aus, dass sowohl im agilen Ansatz des Projektmanagements als auch im klassischen Modell (Wasserfall-Methode) Aspekte vorhanden sind, die das Managen eines Projektes erfolgreich machen. Insofern bedient man sich beim Hybriden Projektmanagement Elementen aus beiden Methoden – quasi das Beste aus beiden Welten.

Ein typisches agiles Element, das gerne in diesen Projekten umgesetzt wird, ist das Daily Standup in Kanban, aber auch in anderen Methoden (Scrum, XP) wird dieses Event verwendet. Seltener ist es der Fall, dass in agilen Projekten Elemente aus dem Klassischen Projektmanagement eingesetzt werden.

Halten wir also fest: Hybrides Projektmanagement ist eine Mischform aus klassischen und agilem Projektmanagement. Es ist der Versuch, das Beste aus beiden Welten in einer Methode zu vereinen. Wir sehen, dass dies sehr oft in der Praxis angewandt wird. Oft auch mit Erfolg. Wie man beide Ansätze kombiniert, hängt dabei von der Art des Projekts, aber auch von seiner Projektphase ab.

1.2.4Kanban: die Ausnahme von der „Regel“?

Da Kanban den Fokus auf eine flussbasierte Arbeit legt und den bereits bestehenden Prozess respektiert und akzeptiert bietet diese Methode den Vorteil, dass es sich sowohl in bereits bestehende Vorgehensmodelle wie etwa das klassische Projektmanagement, aber auch in agilen Kontexten integrieren und einsetzen lässt. Dies bietet den Vorteil, dass du zum Beispiel nicht „revolutionäre Veränderung“ durchführen musst, sondern eher „evolutionär“ und inkrementell vorgehen kannst. So verbessert sich der Prozess über die Zeit stetig. Natürlich ist diese Sichtweise eher theoretisch, denn wenn man noch nie mit WiP-Limits gearbeitet hat, ist die Einführung von WiP-Limits ebenfalls „revolutionär“. Kanban ist hier also etwas Besonderes, da es sich sowohl in der neuen agilen aber auch in der herkömmlichen, klassischen Welt bewegen und erfolgreich sein kann.

1.2.5Das agile Manifest als Basis agiler Vorgehensmodelle

Wer sich mit Agilem Projektmanagement beschäftigt, hat sicherlich schon vom „Agilen Manifest“ gehört. Dieses ist der gemeinsame Nenner, auf den sich verschiedenste Vertreter von Softwareentwicklungsmethoden im Jahre 2001 geeinigt haben. Insgesamt 17 von ihnen haben hierin ihre gemeinsame Vorstellung bezüglich agiler Softwareentwicklung zusammengetragen. U.a. auch die Begründer von Scrum, Jeff Sutherland und Ken Schwaber, aber auch der Begründer von Extreme Programming (XP) Kent Beck. Das Agile Manifest umfasst insgesamt vier sich gegenseitig gegenübergestellte Wertepaare und zwölf einzelne Prinzipien.

1.2.6Die vier Wertepaare des Agilen Manifests

Die Wertepaare des agilen Manifests stellen jeweils zwei Wertepaare gegenüber. Letztlich schätzen die Verfasser des Agilen Manifests alle diese Values als wichtig ein. Jedoch werden die Values auf der linken Seite der Grafik wichtiger als die auf der rechten Seite eingeschätzt. Es ist demnach eine unterschiedliche Gewichtung vorhanden.

Individuen und Interaktionen über Prozesse und Werkzeuge

Oft wird in Projekten versucht, Kommunikation oder Fortschritt-Tracking anhand von Tools oder Prozessen zu implementieren. Man versucht also Kommunikation zu organisieren oder auch Prozesse im Projekt zu standardisieren. Dies geschieht mit dem Hintergedanken, dass, wenn alles eindeutig mit Prozessen definiert ist und die richtigen Tools eingesetzt werden, das Projekt erfolgreich sein muss. Die Annahme ist: Der Mensch hat sich diesen Prozessen und Tools zu „unterwerfen“ – und wenn er dies tut, dann wird auch das Projekt erfolgreich sein.

Abbildung 4: Wertpaare des Agilen Manifests

Im Gegensatz hierzu geht man im Rahmen des Agilen Manifests davon aus, dass persönliche Kommunikation und Interaktion zwischen Menschen bzw. Projektteammitgliedern immer einer Lösung zuträglich sind. Es werden also weniger ein Tool oder ein Prozess in den Vordergrund gestellt, sondern der Mensch selbst mit seinen ganzen kommunikativen Fähigkeiten und seiner Motivation. Hier geht man davon aus, dass dies ausreicht, um effektiv und erfolgreich in der Projektarbeit zu sein.

Funktionierende Software über umfassender Dokumentation

Letztlich fasst dieses Wertepaar zusammen, dass es darum geht, ein funktionierendes Produkt bzw. eine funktionierende Software zu entwickeln. Oft wird im Projekt insbesondere in der Fachkonzeption viel Wert auf Dokumentation gelegt. Es werden sehr viele Dokumente – wie beispielsweise Fachkonzepte, Fachspezifikationen etc. – produziert, die letztlich nur indirekt benötigt werden oder final auch nicht in das Endprodukt eingehen. Das Agile Manifest stellt mit diesem Wertepaar sicher, dass es letztlich nicht um Zwischenberichte, sondern rein um das Endprodukt geht. Alles andere ist zwar schönes Beiwerk, jedoch nicht primäres Projektziel bzw. Hauptendprodukt des Projektes. Insofern wird hierauf so viel wie möglich verzichtet.

Kooperation mit dem Kunden über Vertragsverhandlungen

Oft ist es im Rahmen von IT-Projekten so, dass alle Leistungen, die in ein Produkt oder eine Software einfließen müssen, auch vertraglich festgehalten werden. Es geht hierbei auch viel Zeit in die Verhandlung und beispielsweise das nachgelagerte Servicelevel und Servicemanagement. Oft wird gerade bei Dienstleisterbeziehungen mehr darüber diskutiert, welche Leistungen und Produkteigenschaften in einem Vertrag festgehalten werden und welche nicht. Gerade in Projekten der App- und Softwareentwicklung fließt oft viel Zeit in vertragliche und rechtliche Diskussionen, anstatt einfach weiter am Produkt zu arbeiten. Das Agile Manifest löst sich von dieser sehr vertraglichen und rechtlichen Sicht und fokussiert sich auf die Produktentwicklung und der Bereitstellung von Dienstleistungen. Es stellt damit auch den Kunden in den Mittelpunkt. Das oberste Ziel ist, auf pragmatische Weise Lösungen mit dem Kunden zu erarbeiten. Der Maßstab ist absolute Kundenzufriedenheit. Diese wird als höher und wichtiger angesehen als rechtliche Verträge bzw. Vertragsverhandlungen.

Reaktion auf Veränderung über Planerfüllung

Planung ist ein essenzieller Bestandteil des klassischen Projektmanagements. Es wird viel Zeit mit Projektplanung verbracht, und damit die genaue Erfüllung dieser Pläne. Diese Sicht ist, wenn man die agile „Brille“ aufzieht, sehr starr. Im Rahmen von agilen Projekten stehen die kurzfristige Anpassung und Adaption auf sich verändernde Rahmenbedingungen absolut im Vordergrund. Flexibel zu reagieren hat absoluten Vorrang vor Planerfüllung. Deswegen werden insbesondere in Kanban auch keine detaillierten Projektpläne für die gesamte Projektlaufzeit erstellt.

Die 12 Prinzipien des Agilen Manifests

Die 12 Prinzipien im Agilen Manifest konkretisieren die Botschaften aus den vier Wertepaaren. Die in der Grafik dargestellten Prinzipien wurden dem Agilen Manifest entnommen und so dargestellt, wie du diese auch im Netz finden kannst. Wir wollen die Prinzipien an dieser Stelle unkommentiert lassen. Sie stehen so, wie sie formuliert sind, für sich und bedürfen aus unserer Sicht keiner weiteren Konkretisierung oder Interpretation.

Kundenzufriedenheit

Unsere höchste Priorität ist es, den Kunden durch frühe und kontinuierliche Auslieferung wertvoller Software zufrieden zu stellen.

Anforderungsänderungen als Wettbewerbsvorteil

Heiße Anforderungsänderungen selbst spät in der Entwicklung willkommen! Agile Prozesse nutzen Veränderungen zum Wettbewerbsvorteil des Kunden.

Regelmäßige Auslieferung in kurzen Zeitspannen

Liefere funktionierende Software regelmäßig innerhalb weniger Wochen oder Monate und bevorzuge dabei die kürzere Zeitspanne!

Tägliche Zusammenarbeit im Projekt

Fachexperten und Entwickler müssen während des Projektes täglich zusammenarbeiten.

Teams aus motivierten Individuen

Errichte Projekte rund um motivierte Individuen. Gib ihnen das Umfeld und die Unterstützung, die sie benötigen, und vertraue darauf, dass sie die Aufgabe erledigen!

Kommunikation von Angesicht zu Angesicht

Die effizienteste und effektivste Methode, Informationen an und innerhalb eines Entwicklungsteams zu übermitteln, ist im Gespräch von Angesicht zu Angesicht.

Funktionierende Software

Funktionierende Software ist das wichtigste Fortschrittsmaß.

Nachhaltigkeit

Agile Prozesse fördern nachhaltige Entwicklung. Die Auftraggeber, Entwickler und Benutzer sollten ein gleichmäßiges Tempo auf unbegrenzte Zeit halten können.

Technische Exzellenz

Ständiges Augenmerk auf technische Exzellenz und gutes Design fördert Agilität.

Einfachheit

Einfachheit: die Kunst, die Menge nicht getaner Arbeit zu maximieren, ist essenziell.

Selbstorganisierende Teams

Die besten Architekturen, Anforderungen und Entwürfe entstehen durch selbstorganisierte Teams.

Regelmäßige Reflektion und Anpassung

In regelmäßigen Abständen reflektiert das Team, wie es effektiver werden kann, und passt sein Verhalten entsprechend an.

Abbildung 5: Prinzipien des Agilen Manifests

Übungsfragen

[1]Why is Kanban so flexible?

Kanban prescribes exactly what has to be implemented.

You do not have to implement anything.

You must implement at least several rules.

Kanban does not prescribe what has to be implemented.

[2]How does Kanban work when introducing changes?

Kanban uses a revolutionary approach.

Kanban uses an evolutionary approach.

Kanban uses both of the above.

All of the above answers are incorrect.

[3]What is the advantage of using Kanban?

Kanban focuses on the team.

Kanban is a method used by top management.

Kanban can only be used in software development.

Kanban is scalable and can be applied throughout the organization.

[4]The Agile Manifesto …

Has been developed by various representatives from the software development industry.

Comprises pairs of contrasting values.

Comprises pairs of values, one of which is considered more important than the other.

All of the above answers are correct.

[5]Important pairs of values according to the Agile Manifest are …

Working software.

Individuals and interaction.

Cooperation with the customer.

Reaction to change.

All of the above answers are correct.

[6]How many agile principles are there?

7

14

12

3

[7]What is the first agile principle?

Customer satisfaction.

Daily collaboration.

Teams of motivated individuals.

Sustainability.

[8]Team members should …

Work together on a daily basis.

Be highly motivated.

Communicate face to face.

Answers 2 and 3 are correct.

[9]What is the most important measure of progress?

Sustainability.

Technical excellence.

Simplicity.

Working software.

[10]How should software be delivered according to the Agile Manifesto?

In long intervals.

In short intervals.

Regularly.

Answers 2 and 3 are correct.

[11]How should teams work together?

Self-organized.

Separate from each other.

The work must be specified in detail.

None of the above answers are correct.

[12]Kanban offers the possibility to …

React quickly and flexibly to customer needs.

Incremental further development of existing processes.

Change the organization.

All of the above answers are correct.

[13]Why is Kanban so successful?

Kanban pursues continuous improvement.

Kanban is adaptable.

Kanban is agile.

All of the above answers are correct.

[14]Is Kanban agile?

Kanban is not a classical agile method.

Kanban is agile.

Kanban is a mixture of classical an agile methods.

Kanban is a method to work flow-based.

2Was ist Kanban?

Kanban kommt aus dem Japanischen und bedeutet sinngemäß „Signalkarte“. Der Ursprung von Kanban nach seinen Begründer David J. Anderson liegt in dem Toyota Produktions System, kurz TPS. Das TPS ist auch als Just-in-Time-Produktion bekannt. Es basiert dabei auf einem Pull-System. Dabei richtet sich das System nach der Kundennachfrage. Es wird demnach nicht eine vorgefertigte Menge geliefert wie in einem Push-System. In einem Pull-System ziehen sich die Mitarbeiter die Arbeit, wenn sie über Kapazität verfügen. Diese Methode ist der Ursprung von Lean-Produktion. Dabei ist es das Ziel, Verschwendung zu reduzieren und ohne Mehrkosten mehr Wert für den Kunden zu kreieren. Der Ursprung von Kanban liegt also in der Produktion. David J. Anderson wandelte die Praktiken und Prinzipen des TPS ab, um es in der Softwareentwicklung anzuwenden. Da man in Kanban den derzeitigen Arbeitsfluss sichtbar macht kann es aber auch sehr gut in anderen Bereichen wie Personal oder Marketing usw. angewendet werden.

Kanban wird in vielen verschiedenen Organisationen eingesetzt. Kanban schreibt dir wenig vor, kann aber in den richtigen Händen eine starke Methode sein, um dir oder deiner Organisation zu helfen, erfolgreich zu werden oder erfolgreich zu bleiben. Um eine Grundlage und eine Übersicht zu erhalten, gibt es von David J. Anderson und Andy Carmichael das Buch: „Die Essenz von Kanban kompakt“. Dieses frei zugängliche Buch gibt dir eine grundlegende Einsicht in das Thema Kanban. Viele der Ideen werden dabei vorgestellt, ohne dabei aber direkt in die Tiefe zu gehen. Ziel ist es, dir auf wenigen Seiten zu zeigen, was Kanban ist.

2.1Die drei Prinzipien von Kanban

Abbildung 6: Die Kanban-Prinzipien

Kanban baut auf drei Prinzipien und sechs Praktiken auf. Im Folgenden wollen wir die Prinzipien von Kanban erklären.

1.Das erste Prinzip in Kanban lautet: Start where you are; oder auf deutsch: Starte mit dem, was du hast.

2.Das zweite Prinzip lautet: Verfolge inkrementelle, evolutionäre Veränderung und

3.das dritte Prinzip lautet: Fördere Leadership auf allen Ebenen der Organisation.

Prinzip 1: Start where you are

In Kanban musst du nicht deine gesamte Organisation umstellen. Du musst keine Rollen oder Abteilung verändern und neu zusammenstellen. Kanban berücksichtigt hier die entstandenen Abläufe ihn deinem Unternehmen. Diese haben sich aus einem guten Grund entwickelt. Visualisiere bei Einführung von Kanban einfach deine bestehenden Prozesse, ergänze WiP-Limits und führe Feedback-Loops ein. Und schon kannst du deine bestehenden Prozesse hinterfragen und gegebenenfalls verändern und verbessern.

Prinzip 2: Verfolge inkrementelle, evolutionäre Veränderung

Es geht eben nicht darum, vom Zustand 1 in einen Zustand 2 zu wechseln. Es geht hier darum, sich kontinuierlich immer weiter zu verbessern. Es gibt also keinen perfekten Zielzustand, den du erreichen willst. Es geht immer Schritt für Schritt voran. Der Prozess, den du vielleicht jetzt durch Kanban verbessert hast, kann vielleicht in einem Jahr selbst zu einem großen Problem werden, weil dieser zwar heute passt und dir hilft, aber eben nicht mehr in einem Jahr.

Prinzip 3: Fördere Leadership auf allen Ebenen der Organisation

Der letzte Punkt, fördere Leadership auf allen Ebenen der Organisation, hat das große Ganze im Blick. Nehmen wir an, du hast Kanban in deinem Team eingeführt. Super! Dein Team macht Fortschritte, die Durchlaufzeit sinkt, der Durchsatz des Teams erhöht sich und zusätzlich verbessert sich auch noch die Qualität deiner Produkte. Aber vielleicht kommst du irgendwann an den Punkt, an dem du feststellst, dass es Probleme außerhalb deines Teams gibt. Hier hilft die lokale Verbesserung des Teams nicht, um Fortschritte und kontinuierliche Verbesserung zu erzielen.

Aus diesem Grund musst du den Gedanken der kontinuierlichen Verbesserung unternehmensweit denken, vom einfachen Mitarbeiter bis zum Geschäftsführer über alle Abteilungen und Manager, damit sich dein Unternehmen als gesamte Organisation weiterentwickelt. In Kanban gibt es demnach keine Einzelkämpfer. Kanban gibt es nur im Ganzen. Es ist also kein Einzelsport. In einem Tennismatch gibt es zumindest auf dem Platz nur einen Akteur. In einem Fußballspiel gibt es ein ganzes Team, das zusammenarbeiten muss. Wenn sich hier nur ein einziger Spieler stetig verbessert, wird sich zwar dieses stetig verbessern, aber das hilft dir nichts, weil noch zehn weitere Spieler auf dem Platz stehen. Kontinuierliche Verbesserung sollte als Mindset, also in der ganzen Organisation eingeführt werden und nicht nur partiell.

Dabei geht es in Kanban um die Menschen und nicht die Organisation. Es geht darum die Arbeitskultur zu verbessern, um bessere Kommunikation, um kritisches Denken. Dazu benötigst du Menschen, die den Mut aufbringen, den Finger in die Wunde zu legen.

Video anschauen: Die drei Prinzipien

In diesem Video gibt Autor Roman Simschek einen Überblick über die drei Kanban-Prinzipien und ihre Bedeutung.

http://agile-heroes.de/buch/kanban