„SCRUM FUNKTIONIERT

NICHT ÜBERALL”

indem man z. B. ein Whiteboard mitHaftnotizen darauf verwendet, und dassman nur dann mit neuen Aufgabenbeginnt, wenn man vorher bestehendeAufgaben erledigt hat. Darüber hinaus gibtes ein Signalsystem, das deutlich macht,wann neue Arbeit gezogen werden darf.

■■? Im Moment reden alle über Scrum.Weltweit gibt es über 61.000 zertifizierteScrum-Master. Beinahe jedes Unternehmenhat bereits Scrum eingeführt oder plant dieEinführung. Warum brauchen wir da nochKanban?

■■! Man kann natürlich nicht abstreiten,dass Scrum außergewöhnlich erfolgreichist. Ich bin mir ganz sicher, dass Scrum einRezept ist, das unter bestimmenUmständen gut funktioniert. Der Kern derScrum-Philosophie besagt, dass Scrumfunktioniert und dass man die Umstände soändern muss, dass sie zu Scrum passen.Scrum gibt einige gute Regeln vor, die dabeihelfen, erfolgreich zu sein. Es gibt Sprintsvon begrenzter Länge – ursprünglich warenes vier Wochen. Zu Beginn eines Sprintstreffen wir dann eine Vereinbarung überden Umfang, füllen also das Backlog fürden Sprint. Dann wird vier Wochen langgearbeitet, und der Kunde darf währenddieser vier Wochen nicht eingreifen. Das istein fantastischer Weg, um Beliebigkeit undVarianzen zu eliminieren. Zusätzlich gibt esMechanismen wie das tägliche Standup-Meeting, in dem das Team zusammen-

Interview mit David Anderson über Kanban, den Erfolg und Misserfolg von Veränderungs -prozessen, über den Sinn und Unsinn von Aufwandsschätzungen und über Retrospektiven.

m e h r z u m t h e m a :www.limitedwipsociety.org/

www.agilemanagement.net

38 39

gefertigten Definition eines Prozessesankommst und den Leuten erzählst, dasssie diesen Prozess nun anwenden sollen unddass sie zum Beispiel ihre Jobbezeichnungändern müssen oder die Art zu arbeiten,dann wehren sie sich. Deshalb ist es besser,evolutionär statt revolutionär vorzugehen.Durch eine ganze Reihe von Ereignissen binich dann zu dem Schluss gelangt, dass einKanban-System eine Möglichkeit darstellt,evolutionär vorzugehen, anstatt eineMethode einfach vorzuschreiben. Und das

hat sich bewahrheitet. Zwischen2004 und 2007 habe ich das mitverschiedenen Teams an unter-schiedlichen Orten ausprobiert,

bis ich sicher war, dass es tatsächlich funk-tioniert. Ich habe dann öffentlich über mei-ne Erfahrungen gesprochen und anderehaben es ebenfalls ausprobiert. Jetzt, zweiJahre später, gibt es eine ganze Reihe vonTeams auf der ganzen Welt, die Kanbananwenden, um Änderungen evolutionär zubewirken, anstatt revolutionär, so wie esdie klassischen agilen Methoden tun.

■■? Können Sie versuchen, Kanban in zweiSätzen zu erklären?

■■! Hinter Kanban steht die sehr einfacheIdee, dass man die Menge an parallelerArbeit (Work-In-Progress) begrenzt, dassman diese begrenzte Arbeit visualisiert,

■■? Hallo David – schön, Sie hier inDeutschland zu haben. Erzählen Sie uns,wie Sie zu Kanban gekommen sind undwomit Sie sich im Moment beschäftigen?

■■! Das ist eine lange Geschichte. DieEvolution von Kanban hat insgesamt zehnJahre gedauert. Zuerst haben wir mit deragilen Methode Feature DrivenDevelopment (FDD) gearbeitet, obwohlwir damals noch gar nicht genau wussten,was agile Methoden sind. UnsereErfahrungen haben wir durchIdeen aus dem LeanManagement und einige Ansätzeaus der Theory of Constraintserweitert. Diese Ideen habe ich in meinemBuch von 2003 veröffentlicht ([And03]).Danach habe ich weiter hinzugelernt. Ichhatte stets mit einem großen Problem zukämpfen: Ich habe FDD zweimal sehrerfolgreich eingeführt. Nach diesem Erfolgwollte ich FDD hoch skalieren auf eineganze Business-Unit. Beide Male, bei denenich das versuchte, gab es großeWiderstände und ich konnte es nicht insti-tutionalisieren. Da habe ich angefangen,darüber nachzudenken, warum Leute nichtdie offensichtlichen Vorteile darin sehen,die richtigen Dinge zu tun. Warum habensie sich gewehrt? Und warum mussten wirso viel kämpfen? Ich bin zu folgendemSchluss gekommen: Wenn du mit einer vor-

i n ter v i ew

Das ungekürzte Interview können Sieim Software Engineering Radio unterwww.se-radio.net hören.

David J. Anderson gilt als Vater des Kanban-

Ansatzes in der Softwareentwicklung. Zusammen

mit Jeff De Luca hat er in den 90er Jahren die agi-

le Methode Feature Driven Development entwi -

ckelt. Sein Fokus liegt heute darauf, Agilität auch in

großen Unternehmen einzuführen, indem er das

CMMI-Modell für organisatorische Reife mit agilen

Ansätzen und Lean verbindet. David Anderson lei-

tet eine Management-Beratung in Seattle.

DAV ID J . ANDERSON

„Es ist besser, evolutionär

statt revolutionär vorzugehen.”

Der SE Radio Podcast ist auf der Suche nach

neuen Teammitgliedern. Deren Aufgabe ist die

Ideenfindung, Planen, Durchführung und das

Schneiden von englischsprachigen Interviews

mit interessanten Menschen aus der Soft -

warebranche. Bei Interesse nehmen Sie bitte

Kontakt auf mit Markus Völter unter

voelter@acm.org.

Software Engineering Radio

sucht neue Mitstreiter.

2/2010

kommt und über seine Arbeit spricht.Dadurch entsteht ein guter Teamgeist undvielleicht auch ein leichter Druck, dass jederEinzelne Verantwortung über-nimmt. Das Team verpflichtetsich zu dem Sprint-Ziel und dannarbeiten alle zusammen, um biszum Ende des Sprints fertig zu werden.Danach wird dem Kunden ein funktionieren-des Produkt-Inkrement vorgestellt, und esgibt eine Retrospektive. Dies alles ist sehrgut! Die Herausforderung dabei liegt imRhythmus: Vielleicht passen vier Wochennicht und zwei Wochen sind besser?

Ich glaube nicht daran, dass Scrum injeder Situation funktioniert. Viele Leutebesuchen Kanban-Schulungen, weil sie inUmgebungen arbeiten, für die Scrum nichtbesonders gut geeignet ist, z. B.Systemadministration und Betrieb. DieVorstellung, Arbeit für zwei oder vierWochen in ein Backlog zu füllen, ist völligbefremdlich für sie. Da, wo Scrum anwend-bar ist, ist es sehr erfolgreich, weil es klareGrenzen setzt und weil die Regeln präzisesind: Unterbrechungen werden verhindert,Menschen können ungestört ihre Arbeit tunund es wird ihnen erlaubt, sich innerhalb derTimebox selbst zu organisieren. DieseRegeln sind gut gewählt und erfolgverspre-chend. Und sie sind einfach und leicht zuverstehen. Wenn man sie in zwei TagenSchulung lernen kann, dann können sienicht so schwierig sein. Scrum ist eine großeVerbesserung gegenüber anderen Ansätzen

im Projektmanagement. Aber Scrum kannnicht jedes Problem lösen. Die Leute immerschärfer zu kritisieren und ihnen vorzuwer-

fen, dass sie Scrum nicht korrektanwenden, ist nicht die richtigeAntwort. Ich denke, man sollteaufgeschlossen gegenüber ande-

ren Ansätzen zu sein.

■■? Sind Scrum und Kanban konkurrieren-de Methoden oder ergänzen sie sich gegen-seitig?

■■! Ich sehe sie nicht als konkurrierendeMethoden. Denn Kanban ist gar keineEntwicklungs- oder Projektmanagement-Methode. Im Moment kann man beobach-ten, wie die Scrum-Community eineNeudefinition von Scrum vornimmt. Unddabei gibt es konkurrierende Neu-Definitionen. Wenn man die frühen Bücherüber Scrum liest, ist es im Wesentlichen eineProjekt manage ment-Methode. Tat sächlichfinden sich dort keine Entwicklungs -praktiken. Vielmehr sagen viele Scrum-Leute: Man braucht zusätzlich zu ScrumXP-Techniken, damit man Entwicklungund Projektmanagement zusammen hat.Kanban ist keines von beiden: weder eineEntwicklungs-, noch eine Projektmanage -ment-Methode. Kanban ist eine Ände-rungsmanagement-Methode, eine Art, umÄnderungen herbeizuführen, die zu einemschlanken Unternehmen führen, zu konti-nuierlichen Verbesserungen, zu einer

Kaizen-Kultur. Es ist ein Weg, um inkre-mentelle, evolutionäre Änderungen in einerOrganisation herbeizuführen, anstatt dieArt zu arbeiten zu revolutionieren.

Kanban verwendet man nicht allein.Häufig bekomme ich die Frage gestellt:„Wir stellen ein neues Team zusammen undhaben uns noch nicht für eine Methode ent-schieden. Sollen wir Scrum oder Kanbanverwenden?” Meiner Meinung nach ergibtdiese Frage überhaupt keinen Sinn, dennman kann Kanban nur auf etwas bereitsBestehendes aufsetzen. Das erste Team, mitdem wir Kanban angewendet haben, warein PSP/TSP-Team, das als ausgelagerterLieferant in Indien für Microsoft gearbeitethat. Dort haben wir Kanban aufgesetzt,ohne an diesem Prozess etwas zu ändern.Wir konnten die Produktivität verdreifa-chen und die Durchlaufzeit um 90 % redu-zieren. Das nächste Team, mit dem wirKanban ausprobiert haben, war ein gutesaltes Wasserfall-Team, es hat also mit einerMethode gearbeitet, die aus den 70erJahren stammt. Seitdem habe ich vieleTeams gesehen, die in unterschiedlichenSituationen Kanban eingeführt haben. Undes gibt Teams, die Kanban auf Scrum auf-gesetzt haben. Das Problem dabei ist: Wennman Scrum um Kanban erweitert, verän-dert sich Scrum sehr schnell. Das Teambeginnt Fragen zu stellen: „Warum machenwir zweiwöchige Iterationen?” Kanbanhilft ihnen, Dinge zu entkoppeln: DerInput, also die Priori sierung und diePlanung, ist unabhängig vom Output, alsodem Release-Mechanismus. Ebenso dieDurchlaufzeit. In Scrum sind diese dreiDinge gekoppelt. Wenn man einen Zwei-Wochen-Sprint hat, dann plant man auchalle zwei Wochen. Die Durchlaufzeitbeträgt zwei Wochen und der Release-Zyklus ebenfalls. Für einige Organisa -tionen ist das aber nicht die beste Wahl.Wenn man Kanban einführt, fragt man sichsehr bald, was der richtige Rhythmus ist,und man entkoppelt Input, Durchlaufzeitund Output. Wenn man aber aufhört,gleich lange Sprints durchzuführen, egal obzwei oder vier Wochen, ist es dann nochScrum?

Das ist eine große Herausforderung,denn die Scrum-Community hat hierfürStandards festgelegt. Der Nokia-Test bei-spielsweise überprüft, wie sehr man Scrumeinsetzt. Wenn man diesen Test nichtbesteht, bedeutet das dann, dass man keinScrum einsetzt? Ursprünglich dachte ich,man führt Scrum ein und wird dadurchermutigt, sich immer weiter zu verbessern.

i n ter v i ew

Abb. 1: Kanban-Boards visualisieren den Workflow und machen Flaschenhälse undandere Probleme schnell sichtbar.

„Die Herausforderung

liegt im Rhythmus.”

Grund, warum das gut ist, ist, dass sichunterschiedliche Projekte so gegenseitigbefruchten können. So werden organisato-rische Entwicklung und organisatorischeReife gefördert. Ich glaube, das ist derGrund, warum man bei vielen Kanban-Teams beschleunigte Entwicklung feststel-len kann. Aber ich habe auch schonKanban-Teams gesehen, die Retrospektivenauf Projekt- oder Iterationsebene durchfüh-ren. Wenn sie ein Release hinter sich haben,in dem etwas schief ging, analysieren sie,was da schief gelaufen ist und wie sie das inZukunft verhindern können.

Im Internet schildern Leute, dass ihrTeam aufgehört hat, Retrospektiven durch-zuführen. Sie machen zwar nochOperations Reviews aber keine Retro -spektiven mehr. Wenn man dann analysiert,warum das so ist, findet man heraus, dasssich viele Aktivitäten aus der Retrospektivein das tägliche Standup-Meeting verlagerthaben. Weil sie jeden Tag über Pro -zessverbesserung reden, brauchen sie esnicht mehr am Ende jeder Iteration zu tun.Man macht es täglich und nicht alle zweiWochen oder einmal im Monat. Sehr guteKanban-Teams, die eine wirkliche Kaizen-Kultur entwickelt haben, also einen konti-nuierlichen Verbesserungsprozess, führenjeden Tag Retrospektiven durch. Der Wertvon Retrospektiven wird in Kanban alsoreduziert, weil sie ersetzt werden durch eineKombination aus täglichen Standup-Meetings und Operations Reviews.

■■? Ein anderer interessanter Punkt beziehtsich auf die Schätzungen. Stimmt es, dass inKanban komplett auf Schätzungen verzich-tet wird?

■■! Das ist eine gute Frage, denn in den erstenBeispielen haben wir tatsächlich nichtgeschätzt. Es hat sich herausgestellt, dassSchätzungen optionalsind. Wenn du schätzenmöchtest, dann tu es!Oft schätzen Leute, umein Lieferdatum zu versprechen, auf das sichdann Leute verlassen. Aber nicht jedeTätigkeit, die man verrichtet, braucht ein har-tes Lieferdatum. Immer wieder höre ich:„Wenn keine Ver pflichtungen bezüglich desLieferdatums eingegangen werden, kann manauch niemanden verantwortlich machen.”Meine Einstellung dazu ist: Man setzt einkünstliches Ziel und zwingt das Team dann,es auch zu erreichen. Das führt häufig zu

40 41

warum konnten sie die Builds nicht zumLaufen bringen?” „Weil sie kein funktio-nierendes Konfigurationsmanagement hat-ten.” Das sind also die Kernfähigkeiten, dienötig sind, damit Kanban funktioniert.

■■? Viele sagen, dass Retrospektiven dasHerzstück agiler Vorgehensweisen darstel-len. Gibt es auch in Kanban Retro -spektiven?

■■! Man kann nichts lernen, solange mansich nicht die Zeit nimmt, um anzuhaltenund zu reflektieren. In Kanban ermutige ichdie Teams dazu, auf einer mehr organisato-rischen Ebene zu reflektieren. Ich nenne dasOperations Reviews. Das ist nicht neu – ichhabe dieses Konzept nicht erfunden. Worinsich Operations Reviews und typische agileRetrospektiven unterscheiden, ist der Gradder Objektivität. Für ein OperationsReview benötigt man in der RegelManager, die Daten mitbringen: Daten, diesich auf den Workflow beziehen, dieFehlerraten, die Durchlaufzeiten usw. DieseDaten werden dann bei den OperationsReviews vorgestellt. Hier sieht man sichbeispielsweise „Cumulative Flow Dia -grams” an oder die Anzahl geblockterTasks. Dies sind alles harte Fakten, objekti-ve Daten. Agile Retrospektiven sind vielsubjektiver. Wie ging es uns beim letztenSprint? Was gefiel uns? Was gefiel unsnicht? Was wollen wir wieder so machen?Was wollen wir anders machen? Das sindtypische Fragen. Bei erfahreneren Teamswerden auch die Retrospektiven immerobjektiver. Aber mit Kanban-Teams versu-che ich, diese Objektivität von Anfang anzu etablieren. Und hier sind wir auch wie-der beim Entkopplungsthema: AgileMetho den koppeln Retrospektiven anReleases. Wenn man also zweiwöchigeIterationen hat, führt man auch alle zweiWochen eine Retrospektive durch. Daskann in Ordnung sein. Aber was ist, wennman sich nur einmal im Monat zusammen-setzen möchte? Oder jede Woche? Oder inirgendeinem anderen Rhythmus? Ich arbei-te darauf hin, dass die Teams ihren eigenenRhythmus für ihre Operations Reviewssuchen, dass dieser Rhythmus entkoppeltist vom Release- und Planungsrhythmusund dass diese Meetings auf einer organisa-torischen Ebene stattfinden. Es geht nichtum die Ebene einzelner Projekte. Holt diegesamte Abteilung zusammen, alle sollengemeinsam an den Reports arbeiten! Der

Und wenn man sich verbessert, sollte mansich ändern. Ein gutes Scrum-Team solltenach einem Jahr etwas tun, was einzigartigauf der Welt ist, aber nicht mehr unbedingtwie Scrum aussehen muss. Man kannsehen, wie die Scrum-Community mit demWiderspruch kämpft: Wie kann man sichimmer weiter verbessern, wenn man bewei-sen muss, dass man Scrum macht, so wie esein Test vorschreibt? Es gibt also Teams,die Kanban auf Scrum aufgesetzt haben.Tatsächlich hat mein Freund Corey Ladasein ganzes Buch über das Thema geschrie-ben ([Lad09]).

■■? Ebenso wie Scrum ist Kanban eher einManagement-Framework, das keine Ent -wicklungstechniken vorgibt. Gibt esbestimmte Entwicklungstechniken, die Siefür Kanban-Systeme empfehlen?

■■! Wenn man Kanban verwendet, umSoftware zu entwickeln, benötigt man dieFähigkeit, Releases zu erstellen. Das bedeu-tet, dass man sein Konfigurationsmanage -ment beherrschen muss. Man mussAnforderungen identifizieren und trackenkönnen. Man muss die Versionskontrolleim Griff haben und verschiedene Branchesmanagen können. Man muss Branches ver-nünftig in Einklang bringen können undman muss in der Lage sein, Releases so zuorganisieren, dass wirklich nur diegewünschten Features ins nächste Releasekommen und nicht aus Versehen auch dieunfertigen Features. Konfigura tions -management ist also eine Kern fähigkeit, dieman braucht, damit Kanban funktioniert.Man muss aber kein Meister auf diesemGebiet sein. Ich glaube, dass die meistenagilen Teams, die XP einsetzen, dieseFähigkeit bereits besitzen. Sie wissen, wieman User-Storys trackt, wie manVersionskontrolle handhabt, wie man mitBranches umgeht, wie man kontinuierlicheIntegration einsetzt und wie man lauffähigeReleases erstellt. Das sind also notwendigeFähigkeiten, aber sie sind nicht ungewöhn-lich. Ich habe Leute sagen hören: „Wirhaben ein Team, das sehr schlecht in derSoftwareentwicklung war. Dann haben wirKanban eingeführt und das Team warimmer noch schlecht.” Als ich fragte,warum sie so schlecht waren, kam alsAntwort: „Sie konnten keine vernünftigenReleases erstellen.” „Und warum nicht?”„Weil sie nicht in der Lage waren, dieBuilds zum Laufen zu bringen.” „Und

i n ter v i ew

„Sehr gute Kanban-Teams führen

täglich Retrospektiven durch.”

2/2010

Heldentum. In der Prozessverbesserung undin der Qualitätssicherung gibt es vieleHinweise auf diese Konstellation: Wenn manein Ziel setzt und erwartet, dassdieses auch erreicht wird, reagie-ren die Leute darauf mitHeldentum. Aber wer sich hel-denhaft benimmt, hört auf, sich zu verbes-sern. Deshalb lautet ein Ratschlag vonGoldratt (vgl. [Gol02]) und einer ganzenReihe anderer moderner Vordenker, dass manauf solche Ziele verzichten soll. Ich habe denEindruck, dass Schätzungen zu Deadlinesführen und zu Verpflichtungen, die dysfunk-tional und nicht erstrebenswert sind.

Auf der anderen Seite gibt es Situationen,in denen man einen bestimmten Liefertermindefinitiv einhalten muss. Zum Beispiel musseine Investment-Bank eine neueAnforderung umsetzen, weil die Regierungeinige Regeln geändert hat und diese neuenRegeln zum 1. Oktober in Kraft treten.Wenn die Bank die neuen Regeln bis zu die-sem Termin nicht einhält, darf sie bestimm-te Wertpapiere nicht mehr handeln. Das sindsehr hohe Kosten, die da drohen: Wenn mandie Anforderungen nicht erfüllt und dasLieferdatum nicht erreicht, darf man keineWertpapiere mehr handeln. Dann ist ganzklar, dass man sicherstellen muss, das neueFeature pünktlich auszuliefern. Für diesespezielle Anforderung ist es sinnvoll, zuschätzen, wie lange die Umsetzung dauernwird. Wenn wir schätzen, dass dieEntwicklung sechs Wochen dauert und wirdie neue Funktionalität bis zum 1. Oktoberbenötigen, ist es sinnvoll, Anfang August mit

der Entwicklung zu beginnen. Es ist nichtsinnvoll, schon im Mai zu beginnen, dennein früher Start schafft hier absolut keinen

Wert. Aber wenn man zu spät istund erst im November liefert,fährt man große Verluste ein.Kanban sagt, dass man

Schätzungen angemessen nutzen sollte. Manmuss sich Gedanken darüber machen, wannSchätzungen sinnvoll sind, und diese dannintelligent nutzen. Schätzungen sind alsooptional. Anstatt alles zu schätzen, schätzenwir nur die wirklich wichtigen Dinge

■■? Die Grundidee zu Kanban stammt ausder Automobilproduktion, wo wir es mitsich stets wiederholenden, gleichförmigenAbläufen zu tun haben. Softwareprojektehingegen haben ja häufig eher den Charaktereiner Produktentwicklung, also eines sehrkreativen und individuellen Prozesses. IstKanban überhaupt für Softwareprojektegeeignet oder liegen die wahren Stärken vonKanban in den Bereichen Betrieb undSystemadminis tration?

■■! Meistens höre ich diese Frage vonLeuten aus der Produktion, die skeptischsind. Kanban ist jedoch ganz eindeutig fürSoftwareprojekte geeignet! Dort sehen wirviele Leute, die Kanban erfolgreich einset-zen. Aber es taucht eine Reihe interessanterFragen auf: Warum funktioniert es, dadoch die Softwareent wick lung viel mehrVariabilität aufweist als die Produktion?Das führt zu der Frage, wie Kanban aneinen anderen Kontext angepasst wurde,

nämlich an die Softwareentwicklung.Software-Kanban hat zwar mit denselbenPrinzipien wie die Produktion angefangen,aber daraus sind unterschiedlichePraktiken entstanden. Wir haben nicht ver-sucht, die Praktiken aus der Produktion 1:1zu kopieren. In Wahrheit haben wir sie garnicht kopiert, sondern wir haben uns diedahinter liegenden Prinzipien angesehenund diese auf die Softwareentwicklungübertragen, um so unsere eigenen Prak -tiken zu entwickeln. Deshalb kann mannicht wirklich sagen, dass Software-Kanban aus der Produktion entstanden ist.

Mein Ratschlag an alle, die an Kanbaninteressiert sind, lautet: Probiert es aus!Viele Aspekte von Kanban sind zunächstkontraintuitiv. Der einzige Weg, mehr dar-über herauszufinden, ist es auszuprobieren!

■■? Vielen Dank für das Gespräch, David.

Das Gespräch führte Arne Roock.

i n ter v i ew

Literatur

[And03] D. Anderson, Agile Management forSoftware Engineering – Applying the Theory ofConstraints for Business Results, Prentice Hall2003[Gol02] E.M. Goldratt, P. Pyka, Die kritischeKette. Das neue Konzept im Projektmanage -ment, Campus Verlag 2002[Lad09] C. Ladas, Scrumban – Essays onKanban Systems for Lean Software Develop -ment, Bertrams Print on Demand 2009

„Wer sich heldenhaft benimmt,

der hört auf, sich zu verbessern.”