Tuesday, November 30, 2010

Kanban und Scrum - Teil 1

Wenn man etwas zu Kanban erzählt, kommen immer Fragen wie: "Ist das besser als Scrum?", "Wann verwendet man Kanban, und wann Scrum?" usw. Diese Fragen ergeben genau genommen keinen Sinn, denn Scrum und Kanban sind keine Gegensätze. Henrik Kniberg hat es einmal sehr nett ausgedrückt [1]: Genau so gut könnte man fragen, was besser ist, Messer oder Gabel? Manchnmal braucht man ein Messer, manchmal eine Gabel, manchmal beides, und manchmal etwas ganz Anderes, z.B. einen Löffel.

Scrum ist ein Management-Framework (zumindest lautete so die offizielle Sprachregelung der ScrumAlliance bis zur Einführung des Certified Scrum Developers). D.h. Scrum sagt etwas dazu, welche Rollen man besetzen sollte, welche Artefakte man benötigt, und welche Meetings zu welchen Zeitpunkten durchgeführt werden sollten, um erfolgreich Produkte zu entwickeln. Kanban ist kein Management-Framework, sondern eine Change-Management-Methode. In Kanban geht es darum, den bestehenden Prozess (wie auch immer der aussehen mag) durch Visualisierung, Limitierung und Messungen immer weiter zu verbessern. Es kann durchaus sein, das man Kanban verwendet, um Seine Scrum-Implementierung noch weiter zu verbessern (das nennt sich dann Scrumban [2]). Es kann aber auch sein, dass man Kanban auf einen Wasserfall-ähnlichen Prozess aufsetzt, um ihn in kleinen Schritten immer agiler zu machen

Wenn man genau hinhört, dann wird zwar gefragt, ob Scrum oder Kanban besser sei, aber dahinter steht meistens eine ganz andere Frage: Nämlich die Frage nach dem Sinn und Unsinn von Iterationen. Hierzu macht Scrum ja die klare Aussage, dass es Iterationen (Sprints) fester Länge geben muss - zwei Wochen scheint inzwischen die häufigste Sprintlänge zu sein. Es gibt also alle zwei Wochen ein Priorisierungsmeeting, ein Sprint Review und eine Retrospektive. Kanban sieht keine Iterationen vor - es verbietet sie jedoch auch nicht. David Anderson ampfiehlt immer wieder, auch in Kanban regelmäßige Rhythmen (cadences) zu etablieren. Wie lang diese Rhythmen sind und ob sie miteinander gekoppelt sind, hängt vom jeweiligen Kontext ab, in dem das Team und die Organisation sich befindet. Wenn der Aufwand für ein Release sehr hoch ist, dann ist es vielleicht (zunächt einmal) sinnvoll, nur alle zwei Monate zu releasen und sich immer wieder Gedanken zu machen, wie man die Kosten für das Release (Koordinierungs- und Transaktionskosten) kontinuierlich senken kann, um einmal pro Monat, alle zwei Wochen oder wöchentlich releasen zu können. Wenn aber auf der anderen Seite die Kosten für die Priorisierung neuer Anforderungen sehr gering sind (z.B. weil es bereits regelmäßige Abstimmungsmeetings gibt, in denen die richtigen Leute für die Priorisierung zusammensitzen), dann kann es sehr sinnvoll sein, die Priorisierungen in einem viel kürzeren Takt vorzunehmen. Dann gibt es zwar immer noch nur alle zwei Monate ein neues Release, aber die meisten Anforderungen, die in diesem Release umgesetzt werden, sind wesentlich jünger als zwei Monate. Auch hier gilt wieder: Nur weil etwas im Moment so ist, bedeutet das noch lange nicht, dass es so bleiben muss. Aber der Startpunkt sieht erst einmal genau so aus.

Kanban schreibt also keine Iterationen vor, verbietet diese jedoch auch nicht. Deshalb lässt sich Scrum auch als eine spezifische Ausprägung eines Kanban-Systems ansehen (bei dem nämlich die drei genannten Rhythmen in Form von Iterationen gekoppelt sind). Und tatsächlich könnte ich mir vorstellen, dass man mit einem Wasserfall-ähnlichen Entwicklungsprozess startet und ihn mit Kanban kontinuierlich immer weiter anpasst, bis eines Tages Scrum dabei herauskommt (oder etwas sehr Scrum-Ähnliches).
Scrum als Management-Framework steht also nicht im Widerspruch zu Kanban als Change-Management-Methode. In dieser Hinsicht ist die Frage "Scrum oder Kanban" tatsächlich unsinnig. Allerdings führen die meisten Organisationen agile Methoden ja nicht auf der grünen Wiese ein, sondern sie haben bereits einen etablierten Entwicklungsprozess, mit dem sie aber unzufrieden sind. Und sie versprechen sich von Scrum massive Verbesserungen (oft auch den einzigen Ausweg). In diesem Szenario geht es also um Veränderungen, und Scrum ist der Trigger, um diese Veränderungen anzustoßen, bzw. erst einmal das volle Ausmaß der Probleme transparent zu machen. Wenn wir aber von Veränderungen sprechen, dann ist es sinnvoll, sich zu überlegen, ob man diese disruptiv (also revolutionär) oder evolutionär einführen möchte. Scrum steht für den ersten Ansatz, Kanban für den zweiten. Keiner der beiden Ansätze ist per se besser oder schlechter, sondern der Kontext entscheidet. Wenn ein Unternehmen mit dem Rücken zur Wand steht, ist Scrum vielleicht der einizig mögliche Ausweg. Und in dieser Situation sind die Beteiligten häufig auch bereit, schmerzhafte Veränderungen durchzuführen. In anderen Situationen hingegen werden revolutionäre Veränderungen nicht akzeptiert - oder nach ersten Erfolgen bei einzelnen Teams wird die Skalierung durch Vertragsgestaltungen, Prämienmodelle o.ä. ausgebremst. Dann könnte Kanban der bessere Ansatz zur Veränderung sein. Eine Erfolgsgarantie gibt es weder hier noch dort.


P.S. Eigentlich sollten in diesem Post zwei Graphiken zum Zusammenhang zwischen Kanban und Scrum abgebildet sein. Nach einer Dsikussion mit Bernd Schiffer und Stefan Roock (vielen Dank dafür!) bin ich jedoch zu dem Schluss gekommen, dass ich darüber erst noch weiter nachdenken muss und daraus wohl ein eigener Post wird.

Referenzen
[1] Henrik Kniberg und Mattias Skarin (2010): "Kanban and Scrum - Making the Most of Both." Buch bei Amazon oder kostenloser Download
[2] Corey Ladas (2009): "Scrumban - Essays on Kanban Systems for Lean Software Development." Buch bei Amazon

Sunday, November 28, 2010

Lean und Kanban auf den XP Days Germany 2010

Vom 25.-27.11. fanden wieder die XP Days Germany statt - zum dritten Mal in Hamburg.
Holger Koschek hat schon einen sehr schönen Post mit seinen Eindrücken geschrieben. Deshalb beschränke ich mich hier auf meine Lieblingsthemen: Lean und Kanban.
Im "regulären" Programm Donnerstag und Freitag gab es insgesamt fünf Session zu Lean und Kanban. Den Anfang machte Traian Kaiser, der über Paradigmenwechsel im Projektmanagement auf dem Wege zur Lean Enterprise bei der XING AG sprach. An dieser Session konnte ich leider nicht teilnehmen, weil ich zeitgleich im Nebenraum eine Karata-Kata gelaufen bin (Foto).
Direkt danach führten Markus Andrezak und Stefan Roock ein kleines (sehr amüsantes) Rollenspiel auf, in dem sie gewissermaßen im Zeitraffer darstellten, wie das Portfolio-Management mit Kanban bei mobile.international funktioniert und welche Entwicklungsschritte bis heute durchlaufen wurden. Passende Folien hierzu gibt es auf Slideshare.
Nach dem Mittagessen haben dann Olaf Lewitz, Bernd Schiffer und ich eine Kanban-Einführung gehalten. Olaf hat zu Beginn die Prinzipien von Kanban dargestellt, und danach haben wir mit sechs parallelen Gruppen das Name Game gespielt, in dem man sehr schön die Auswirkungen von Multitasking in einem praktischen Beispiel selbst erleben kann. Die Teilnehmer produzieren Namensschilder - einmal acht Stück parallel, und einmal eins nach dem anderen. Andreas Schliep hat dazu eine sehr interessante Zahl genannt: Nach dem Putnam Model waren die Gruppen im zweiten Durchlauf bis zu 2.000% (!) produktiver als im ersten! Mir hat die Session riesigen Spaß gemacht. Vielen Dank an alle Teilnehmer insbesondere Olaf und Bernd!
Am Nachmittag gab es dann noch zwei Kurzvorträge zum Thema: Markus Andrezak berichtete von seinem Italien-Urlaub und wie eine Pasta-Fabrik ihn dazu brachte zu erkennen, dass die Lead Time nicht immer entscheidend ist. Hier die Folien bei Slideshare. Und hier der passende Blog-Eintrag von Markus dazu. Dann durfte ich in einem Pecha Kucha Justins Reise vom Wasserfall über Scrum zu Kanban nacherzählen.

Fast noch interessanter wurde es dann Samstag beim OpenSpace. Dort wurden gleich drei Sessions zu Kanban angeboten: Eine Einführung von Bernd und mir, eine Diskussion zu Scrum&Kanban und schließlich ein sehr interessanter Perspektivenwechsel darauf, unter welchen Bedingungen Kanban schlecht geeignet sein kann und welche Anzeichen darauf hindeuten, dass man es allenfalls mit einer leeren Kanban-Hülle zu tun hat. Vielen Dank an Jiri Lundak, der diese Session angeboten und moderiert hat. Die Ergebnisse wollen wir als Grundlage verwenden, um einige Antipatterns zu Kanban festzuhalten. Mehr dazu hoffentlich bald.

Die XP Days haben wie immer riesigen Spaß gemacht, ich habe eine Menge gelernt und viele interessante Menschen kennen gelernt! Und es bleibt die schöne Erkenntnis, dass Lean und Kanban ihren Platz in der Agilen Community finden und dazu beitragen, die Agile Gedankenwelt weiterzuentwickeln.

Hier finden sich die Fotos zu den XP Days

Tuesday, November 23, 2010

Die Prinzipien von Kanban

Rund um (Software-)Kanban haben sich inzwischen so viele nützliche Best Practices herausgebildet, dass es gar nicht mehr so einfach ist, einen Schritt zurückzutreten und die grundlegenden Prinzipien zu erkennen.
Wenn ich Kanban erklären, dann beschränke ich mich inzwischen auf drei fundamentale Eigenschaften, die jede Kanban-Implementierung aufweisen muss:
  1. Visualisierung
  2. Limitierung
  3. Kontinuierliche Verbesserung
Dies ist zweifellos stark abstrahiert, aber wenn man diese Punkte ernst nimmt, kommt man sehr, sehr weit.

Visualisierung
Der aktuelle Prozess muss auf einem "Board" visualisiert werden - egal ob Whiteboard, Pinnwand, Fensterscheibe, an der Wand (oder zur Not auch in einem elektronischen Tool). Diese Visualsisierung sollte möglichst einfach, leicht verständlich und vor allem für das gesamte Team (am Besten die gesamte Organisation) gut sichtbar sein. Wenn man 2 Stunden benötigt, um einem neuen Kollegen das Board zu erklären, dann ist es ganz sicher zu kompliziert.
Die zweite wesentliche Form von Visualisierung besteht darin, implizite Regeln explizit zu machen - und auch diese gut sichtbar aufzuhängen (z.B. auf einem Flipchart). Solche Regeln beziehen sich z.B. darauf, wann welche Meetings stattfinden, in welcher Reihenfolge die Aufgaben abgearbeitet werden, wie mit Notfall-Tickets umgegangen wird, welche Termine und Lieferzeiten dem Kunden versprochen wurden usw.
Erfahrungsgemäß bringt die Visualisierung, obwohl sie recht simpel ist, einen riesigen Erkenntnisgewinn und führt für sich schon zu Verbesserungen führen.


Limitierung
In einem Kanban-System ist die Menge an begonnener Arbeit stets begrenzt. In der Regel bezieht sich diese Limitierung nicht nur auf das Gesamtsystem, sonder auch auf die einzelnen Prozessschritte (Entwicklung, Test usw.)
Untrennbar verbunden mit der Limitierung ist das Pull-Prinzip: Nur, wer eine alte Aufgabe erledigt hat, zieht sich eine neue Aufgabe aus der Spalte links von ihm und beginnt mit dieser. Aufgaben werden stets selbstständig gezogen, nicht von Vorgesetzten zugewiesen. Damit wird deutlich, warum es nicht ganz einfach ist, ein echtes Pull-System zu etablieren, denn es gehört viel Vertrauen dazu! Denn die Vorgesetzen müssen darauf vertrauen, dass neue Aufgaben auch tatsächlich regelmäßig gezogen werden und die Mitarbeiter nicht stattdessen lieber den ganzen Tag lang Kaffee trinken oder im Internet surfen.


Kontinuierliche Verbesserung (Kaizen)
Egal wie gut unser initiales Kanban-System auch sein mag, es muss immer weiter verbessert werden. Sobald wir aufhären, uns zu verbessern, machen wir auch kein Kanban mehr! Diese Verbesserug kann in sehr kleinen Schritten vorgehen, aber sie muss vorhanden sein. Und die Verbesserungs-Maßnahmen sollten vom Team ausgehen. Wenn aus dem Team keine Verbesserungsvorschläge mehr kommen, ist dies ein sicheres Zeichen dafür, dass etwas mit dem Prozess im Argen liegt. Für kontinuierliche Verbesserung ist es unabdingbar, dass sich das Team regelmäßig ausreichend Zeit nimmt, um über den Prozess und die Zusammenarbeit zu reflektieren (z.B. in Retrospektiven). Und es ist sehr nützlich, ständig einfache Messungen durchzuführen (z.B. Durchlaufzeiten, Termintreue, Fehlerrate usw.), anhand derer man Verbesserungsmaßnahmen besprechen kann.
Die kontinuierliche Verbesserung ist zweifellos der wichtigste Punkt unter den dreien - und leider derjenige, der oft nicht richtig Ernst genommen wird. Hierin sehe ich tatsächlich eine Gefahr: Wenn der Prozess visualisiert und die Arbeit limitiert wird, dann sieht es von außen nach einem Kanban-System aus. Und dann ist es sehr einfach, es beim Status Quo zu belassen. Aber dann fehlt ein wichtiger Feiler von Kanban!


Literatur und Links

Monday, November 22, 2010

Was ist noch mal dieses Lean?

Lean hat jeder schon mal gehört. Und alle finden es irgendwie cool. Aber was genau Lean eigentlich ist, kann kaum jemand sagen. Das liegt allerdings nicht daran, dass die Leute zu blöd wären, um Lean zu verstehen. Vielmehr bin ich inzwischen überzeugt davon, dass es das eine Lean gar nicht gibt. Denn es werden unterschiedliche Vorstellungen und Konzepte unter der Bezeichung Lean zusammengefasst. Das reicht dann von der Kostenreduktion um jeden Preis über Einfachheit bis hin zur recht jungen Community der Lean Startups. Ich kann mich noch dunkel daran erinnern, dass wir das Thema Lean Production in der Oberstufe behandelt haben. Das Einzige, was daraus bei mir hängen geblieben ist: Durch die Just-in-Time-Produktion haben die Automobilhersteller ihre Lager auf die Straße verlegt. Also kann Lean offenbar auch bedeuten, die Kosten, die bei der eigenen Verbesserung entstehen, auf die Allgemeinheit abzuwälzen;-) 
Was ist Lean also: Eine Produktionsmethode? Eine Managementphilosophie? Oder doch nur ein (nicht mehr ganz so) neues Schlagwort, unter dem uns alte Kamellen als tolle Neuerungen verkauft werden sollen? Sicherlich ist überall etwas Wahres dran. Für mich liegt der Kern jedoch in etwas Anderem: Lean ist eine Blickweise, bei der konsequent die Perspektive des Kunden eingenommen wird! In Lean geht es darum, möglichst häufig möglichst viel Wert für den Kunden auszuliefern. Alles, was diesem Wert abträglich ist, sollte reduziert oder abgeschafft werden. Und wir wollen uns immer weiter verbessern. Punkt. So einfach ist die Sache. Dies ist der Kern von Lean. 
Worin dieser Wert besteht (und wer der Kunde ist), wird je nach Kontext variieren: Es kann sich ebenso um Geld handeln wie um Wissen, Zeit, Sicherheit oder vielleicht auch Spaß. Dieser Wert lässt sich oft nicht eindeutig quantifizieren, aber es muss ihn geben. Andenfalls sollte man sich ernsthaft fragen, womit man eigentlich seine Zeit verbringt, wenn dabei nichts herauskommt, was für irgend jemanden von Wert ist.
Nimmt man diese Sichtweise ein, dann ist Lean keineswegs auf die Geschäftswelt beschränkt, sondern lässt sich auch auf die Freizeit anwenden. Dann kann ich auch mein eigener "Kunde" sein, und der "Wert" z.B. eines Spaziergangs besteht in meiner Erholung. Aus einer Lean-Perspektive heraus könnte ich mich dann fragen, wie ich mich möglichst oft möglichst vollständig erholen kann. Vielleicht ist die lange Fahrt ans  Meer ein Hindernis für mich, und ich sollte mal nach einer netten Strecke in meiner Umgebung suchen? Oder ich brauche eine winddichte Jacke, damit ich mich auch im Herbst aus dem Haus traue? 
Wenn Lean aber tatsächlich so einfach ist, was hat es dann mit den vielen Schlagworten auf sich, die überall herumgeistern: Defer Commitments, Pull, Optimize the Whole, Build Quality in, Limit Work to Capacity und viele weitere? Hierbei handelt sich sich um Prinzipien, die sich als nützlich herausgestellt haben, um Strukturen und Prozesse in Richtung Lean zu verändern. Sie alle haben ihren festen Platz im Lean-Universum - aber keines dieser Prinzipien an sich macht Lean aus. Sie alle spielen eine "dienende Rolle" bei der Fokussierung auf den Wert für den Kunden. Und wenn wir uns in einer komplexen Domäne wie der Softwareentwicklung bewegen, ist es ja tatsächlich gar nicht so einfach zu entscheiden, wie genau so eine Fokussierung denn nun aussehen soll. Da sind solche Prinzipien dann sehr nützlich.
Unterhalb dieser Prinzipien wird es dann noch einmal konkreter, wenn wir uns die Praktiken ansehen, die allgemein hin als Lean angesehn werden: Stop the Line und Root Cause Analysis wären solche Praktiken. Und viele der agilen Managementtechniken und der Entwicklungspraktiken, die aus XP bekannt sind, ebenfalls. Doch dazu mehr in einem späteren Post.

Friday, November 19, 2010

Kontakt und Impressum

Arne Roock
arne (dot) roock (at) emailica (dot) de
Profil bei Xing 
Twitter: @arneroock

Inhaltlich Verantwortlicher

Inhaltlich Verantwortlicher gemäß § 6 MDStV: Arne Roock

Haftungshinweis

Trotz sorgfältiger inhaltlicher Kontrolle übernehme ich keine Haftung für die Inhalte externer Links. Für den Inhalt der verlinkten Seiten sind ausschließlich deren Betreiber verantwortlich.