Scrum vs. Kanban: Ziel und Weg
Letztes Wochenende hatte ich eine interessante Diskussion mit Markus Andrezak, Bernd Schiffer und Henning Wolf über Unterschiede und Gemeinsamkeiten von Scrum und Kanban. Tatsächlich finde ich, dass die Unterschiede zwischen Scrum und Kanban verwischen, wenn ein fähiger Coach am Werk ist. Warum sollte man in Scrum nicht auch während eines Sprints releasen? Und warum sollte man in Kanban nicht auch Aufwände schätzen, wenn man so bessere Terminaussagen treffen kann? Und warum sollte man in Scrum kein Kanban-Board haben dürfen? Und häufig legen organisatorische Randbedingungen auch bei Kanban ein Iterationskonzept sehr nah.
Bei der Diskussion haben wir einen Punkt herausgearbeitet, den ich besonders hilfreich für die Differenzierung finde: Scrum hat ein bestimmtes Ideal vor Augen. (Wenn man das erreicht hat, sollte man sich natürlich noch weiterentwickeln.) Aber erstmal hat das Ziel eine klare Form.
Kanban hingegen installiert einen Verbesserungsprozess und lässt offen, wohin genau die Reise geht.
Dadurch ist es sehr einfach, Kanban zu machen. Setzt man auf Scrum, hat man erstmal eine Transitionsphase vor sich – die kann sehr lange dauern und durchaus schwierig sein. (Und so lange macht man eigentlich noch nicht richtig Scrum.) Natürlich kann man während der Transition auch in sehr kleinen Schritten vorgehen und damit eine behutsame Einführung von Scrum erreichen – ähnlich wie bei Kanban.
Auf der anderen Seite kann man mit Scrum etwas tun, was man mit Kanban nicht so gut tun kann: Man kann es als Revolution einführen. Und das kann tatsächlich sinnvoll sein. Ich habe immer wieder mit Unternehmen zu tun, die mit dem Rücken zur Wand stehen. Die brauchen einen schnellen und radikalen Wandel, wenn sie überleben wollen. Mit Kanban ist denen nicht geholfen. Die brauchen keinen Prozess, der sie schrittweise und risikoarm etwas besser macht. Die brauchen etwas, dass sie schnell viel besser macht. Und dafür sind sie bereit, auch die entsprechenden Risiken einzugehen.
2 comments März 4, 2010
Kanban: Definition of Lead Time and Cycle Time
When doing Kanban for software development measuring cycle and lead times is important but often the terms are confused or defined in a fuzzy way. Here is a useful definition from the “Lean and Kanban” blog:
Lead time clock starts when the request is made and ends at delivery. Cycle time clock starts when work begins on the request and ends when the item is ready for delivery. Cycle time is a more mechanical measure of process capability. Lead time is what the customer sees.
Let’s have a closer look and let’s assume we are working with Kanban in a maintenance team. Bugs are reported via tickets in a ticket system like Bugzilla, Jira or Mantis. When the bug is detected a ticket is created and when the bugfix is live, the ticket is closed.
This whole period of time is the lead time.
The lead time is the time and not the effort. You may have a lead time of 100 days and only have to work 1 hour to fix the bug.
Sometime you start working on the bug. The cycle time is the time from the start of the work until the bugfix is live.
Again the cycle time is not the effort. Lead time can’t be shorter than cycle time. Often lead time is a lot longer.
In the context of maintenance there is often a SLA (Service Level Agreement) in place that defines in which time frame you have to fix a bug. Often the SLA defines a resolution time. That is the same as the lead time:
Most SLAs also define a response time. That is the time available until the team has to respond to a new bug ticket: is it really a bug and what is the priority.
With these definitions in place it is obvious that the lead time is what is relevant from the business perspective. The cycle time is what the team can influence by itself by changing its work process. To reduce lead times one can (and should) reduce cycle time. But often the time before the work starts is really long so this wait time should be reduced also.
2 comments März 2, 2010
Kanban: Wer will schon ein Bottleneck sein?
In einem Kanban-Projekt habe ich ein interessantes zwischenmenschliches Problem. In Kanban versuchen wir, sinnvoll mit den Bottlenecks umzugehen, um die Durchlaufzeiten zu reduzieren.
Im Rahmen der Theory of Constraints gibt es sogar ein standardisiertes Verfahren zum Umgang mit Bottlenecks:
- Identify. Identify the bottleneck of the system.
- Exploit. Exploit this bottleneck, making its throughput efficient by changing processes, equipment maintenance procedures, training, policies, etc.
- Subordinate: Subordinate the throughput of all other work centers to this work center.
- Elevate. Invest in this work center to increase its throughput – add equipment, manpower, etc.
- Inertia. Start the process over on the line to determine the new bottleneck.
Das ganze kommt aus einer allgemeinen Systemtheorie und ist natürlich in der Produktion sehr wichtig und auch nützlich. Kanban für die Softwareentwicklung möchte die Theory of Constraints für die Softwareentwicklung auch anwenden. Und da lauert eine Fußangel, die ich auch nicht vorhergesehen habe.
Bei Kanban für die Softwareentwicklung bilden meistens Menschen das Bottleneck. Und wenn wir jetzt beginnen, diese als Bottleneck zu bezeichnen, fühlen sie sich häufig angegriffen. “Ich bin doch kein Bottleneck. Ich tue doch mein Möglichstes.” etc. Auch wenn niemand diese Menschen angreifen wollte, sind sie nun zunächst in einer Verteidigungshaltung. Und das ist die denkbar schlechteste Voraussetzung dafür, mit diesen Menschen Veränderungen im Prozess und in den Arbeitsweisen herbeizuführen.
Ich habe dafür bisher keine Patentlösung. Der erste wichtige Schritt ist sicherlich, sich dieses Problems bewusst zu sein.
Add comment März 1, 2010
Innovation, Festpreise und Verantwortung bei Airbus
Vor kurzem habe ich ein interessantes Interview mit Airbus-Chef Thomas Enders über die Probleme mit dem Airbus A400M gelesen.
Zwei Stellen in dem Interview finde ich besonders interessant:
Frage: “Plädieren Sie für eine neue Preisformel bei Rüstungsaufträgen?”
Enders: “Ich plädiere für mehr Ehrlichkeit und Offenheit von Anfang an. Festpreisverträge machen nur dort Sinn, wo die Entwicklungsrisiken begrenzt sind und die Industrie auf vorhandenen Produkten aufbauen kann. Sie sind nicht vertretbar, wenn es um komplette Neuentwicklungen geht wie bei der A400M. [...]“
Der Mann plädiert für agile Vorgehensweisen, oder? Schön, dass solche Erkenntnisse auch langsam in die Bereiche der V-Modell-Hardliner vordringen.
An anderer Stelle allerdings:
Frage: “2003 hat Airbus vertraglich einen Fixpreis von 20 Mrd. Euro vereinbart. Nun soll das A400M-Programm 32 Mrd. Euro kosten. Warum ist ein unterschriebener Vertrag nicht mehr bindend?”
Enders: “Es ist richtig, dass die Industrie vor sieben Jahren Dinge versprochen hat, die, wie wir heute wissen, nicht realistisch waren. [...]“
Das sieht dann wieder nicht so aus, als meinte er es wirklich ernst. Wer ist denn “die Industrie”? Airbus, oder? Warum sagt er das nicht und übernimmt damit Verantwortung?
Add comment Februar 25, 2010
Kanban ohne Stress?
Ich begleite jetzt schon eine Weile ein Kanban-Team bei einem Kunden und mache dort ganz interessante Erfahrungen.
Eine “Falle” bei Scrum ist das Commitment auf das Sprint-Ziel. Es kann so missverstanden werden, als wäre es eine Garantie des Teams. So passiert es leider immer wieder, dass Teams über einen längeren Zeitraum Überstunden ohne Ende schieben mit den bekannten Ergebnissen: miese Qualität, schlechte Arbeitsmoral, Burnout, etc.
Wenn das Commitment zu solchen Problemen führt, handelt es sich meiner Meinung nach um einen Fehler bei der Scrum-Implementierung. Aber trotzdem tritt dieser Fehler relativ häufig auf.
Kanban hat dieses Problem nicht. Es gibt keine Sprints/Iterationen und auch kein Commitment auf Sprint-Ziele.
Allerdings: Vor kurzem musste ich ein Teammitglied vertreten. Bei dem Kunden gibt es gleich zu Anfang auf dem Kanban-Board eine Spalte, in der die Tickets landen, wenn es einen technischen Lösungsvorschlag der Entwickler gibt. Wenn dieser akzeptiert wird, wird das Ticket in die nächste Spalte verschoben und die Entwicklung kann beginnen.
Ich war nun für die Freigabe der Tickets vorantwortlich und natürlich brauchte ich dafür viel länger als das Teammitglied, das ich vertreten habe. Ich wurde also zum Bottleneck im System. Und da war ich ganz plötzlich doch im Stress. Ich wusste, dass 10 Leute oder mehr ohne Arbeit dastehen, wenn ich nicht möglichst schnell die Tickets freigebe. Und ich würde auch bis spät in die Nacht arbeiten, um meine Teamkollegen mit ausreichend Arbeit zu versorgen.
Ähnlich wie bei den Scrum-Commitments handelt es sich hier um eine fehlerhafte Implementierung von Kanban. Tatsächlich ist die Existenz des Bottlenecks ein organisatorisches Problem. Dass meine Teamkollegen keine Arbeit mehr haben, ist gewollt. Es soll das eigentliche Problem deutlich zeigen und dann sollen wir als Team eine Lösung dafür finden und das Bottleneck beseitigen.
Hier scheint mir kein relevanter Unterschied zwischen Scrum und Kanban zu existieren: Beides kann missverstanden werden und so ein Missverständnis kann in Überlastung einzelner oder aller Teammitglieder enden.
Add comment Februar 23, 2010
Drucken unter Ubuntu mit Turbo-Print
Mit dem Wechsel auf Ubuntu 9.10 sind einige Standard-Pakete weggefallen oder umbenannt worden, die der Canon-Druckertreiber für den Canon MP-620 benötigt. Zumindest direkt nach der Freigabe von 9.10 war von Canon auch noch kein Update des Druckertreibers verfügbar.
Da bin ich auf Turbo-Print gestoßen. Turbo-Print unterstützt alle mögliche Drucker (darunter auch den Canon MP-620) und ist im Gegensatz zu den Canon-Ubuntu-Treibern auch ganz einfach zu installieren.
Einziger Wehrmutstropfen ist, dass Turbo-Print kommerziell ist – knapp 30 EUR ist jetzt aber auch nicht so viel Geld.
Und mit Turbo-Print klappt’s jetzt auch wieder mit dem Drucken.
4 comments Januar 31, 2010
Wieviel Schutz brauchen Entwickler?
Vor ein paar Tagen habe ich mit einem Web-Entwickler gesprochen, den ich sehr schätze – über Java-Script. Wir waren uns schnell einig, dass Java-Script stark unterschätzt wird.
Und dann habe ich ihn etwas ausgefragt, um mich selbst weiterzubilden. Mir ist z.B. notorisch unklar, ob es einen einheitlichen Stand der Kunst zur Definition von Klassen in Java-Script gibt. Und in dieser Diskussion sind wir auch auf private Felder und Methoden in Klassen gekommen. In Java-Script kann man beides machen, es sieht aber nicht so übersichtlich aus.
Daher macht mein Gesprächspartner das gar nicht und markiert Privates einfach mit einem führenden Unterstrich. Und das funktioniert nach seinen Aussagen auch sehr gut. Und zusätzlich muss man sich beim Unittesten nicht damit rumärgern, dass man an irgendwas nicht drankommt.
Und tatsächlich: Wenn ich an 12 Jahre Java-Entwicklung zurückdenke, habe ich kaum von privaten Methoden profitiert. Aber behindert haben sie mich ständig.
Ähnlich verhält es sich mit Konstanten. Klar muss man wissen, was konstant ist. Aber dafür reicht eine Namenskonvention. Hat mich jemals der Compiler darauf hingewiesen, dass ich versuche, eine Konstante zu ändern? Nicht, dass ich mich erinnern könnte.
1 comment Januar 26, 2010
Buchtipp “Clean Code”
Das Buch “Clean Code” von Robert Martin stand schon eine Weile in meinem Bücherregal. Ich habe es solange aufgeschobene, weil ich für mich wenig Neues erwartete. Jetzt bin ich dann endlich dazu gekommen, das Buch zu lesen. Ich hatte vor, es zu überfliegen, weil der Inhalt für mich mit 10 Jahren agiler Programmiererfahrung nicht wirklich neu sein kann.
Wirklich neu war der Inhalt auch nicht, aber aus dem Überfliegen ist auch nichts geworden. Zum einen ist das Buch so kurzweilig geschrieben, dass das Lesen Spaß macht. Zum anderen waren doch einige Abschnitte drin, die mich überrascht und zum Nachdenken angeregt haben.
Die grundsätzliche Argumentation des Buches ist, dass man sich auch um die Kleinigkeiten kümmern muss. Das ist erstmal konträr zu dem, was ich im Studium gelernt habe. Dort war eine Hauptmotivation für Module, dass man in denen das Chaos einsperren kann. Demnach müsste man die Makrostruktur sauber halten und muss sich um die Interna der Module nicht so sehr kümmern. Klang logisch. Aber sowas habe ich in 18 jahren kommerzieller Softwareentwicklung nicht erlebt. Entweder war das System auf jeder Ebene gut strukturiert oder auf jeder Ebene vergurkt. Ich denke, das hängt mit der Einstellung der Entwickler zusammen. Entweder sie interessieren sich für Qualität. Dann tun sie das auf jeder Ebene. Oder sie interessieren sich nicht für Qualität. Dann kümmern sie sich auch nicht um eine vernünftige Makro-Struktur. Robert Martin hat also Recht: Wir müssen uns um sauberen Code auch auf Mikro-Ebene kümmern.
Nur ein Beispiel für die Überraschungen, die das Buch für mich bereit hielt Robert Martin vertritt die Ansicht, dass eine Methode mit einem Parameter schon komplex ist und wenn möglich vermieden werden sollte. Mit 2 oder 3 Parametern wird es demnach noch viel schlimmer. Zuerst habe ich gedacht “naja…”. Aber seine Argumente sind gut und er hat Recht. Viele Parameter sind in sich komplex und deuten häufig darauf hin, dass wir zusätzliche Klassen benötigen oder Methoden in andere Klassen verschoben werden sollten.
Fazit: Aus meiner Sicht ist “Clean Code” ein Must-Have für jeden professionellen Softwareentwickler – egal ob agil oder nicht. Auch alte Hasen werden Nutzen daraus ziehen können.
1 comment Januar 26, 2010
Flow, Pair Programming, Teams und das Unerwartete
Ich bin jetzt endlich dazu gekommen, einen Artikel zu lesen, der schon eine Weile bei mir rumlag: “Promiscuous Pairing and Beginner’s Mind: Embrace Inexperience” (PDF).
Auch wenn der Artikel nicht mehr ganz frisch ist, ist er dennoch sehr erfrischend. Er untersucht die Auswirkungen verschiedener Team-Organisationsformen in agilen Projekten. Zuerst belegt er die Annahme, dass Teams, die sich selbst Tasks nehmen, die effektivste Form der Arbeitsorganisation ist. Gefolgt von Teams, denen die Aufgaben zugewiesen werden, gefolgt von Individuen, die sich die Arbeit selbst nehmen, gefolgt von Individuen, die Arbeit zugewiesen bekommen. Damit ist die klassische Form der Arbeitszuweisung am wenigsten effektiv. Interessanterweise geht FDD mit seinem Class-Ownership-Konzept aber auch in diese (ineffektive) Richtung.
Richtig interessant wird der Artikel aber bei der Frage des Pair-Programming. Die Autoren haben bei sich festgestellt, dass die Enwicklung dann mit Abstand am Effektivsten war, wenn alle 90 (!) Minuten die Pair-Partner getauscht wurden. Bei wachsender Teamgröße (11 Personen) war 120 Minuten die ideale Zeitspanne, bis die Paare wieder wechseln sollten.
Das ist wirklich erstaunlich. Normalerweise geht man davon aus, dass man für hochproduktives Arbeiten im Flow arbeiten muss. Der Flow-Zustand hat aber auch Nachteile: Man braucht lange, um in den Flow-Zustand zu gelangen und wenn man drin ist, ist der Zustand fragil. Durch Unterbrechungen kann er schnell zerstört werden. Nun sagen die Ergebnisse des Papers, dass man auch ohne Flow-Zustand extrem produktiv sein kann – schließlich institutionalisiert das extrem häufige Wechseln des Pair-Partners ja gerade die Unterbrechungen. Dadurch geht man immer wieder mit einer neuen Perspektive an die Aufgabe heran (“Beginners Mind”) und kommt so auf die besten Ideen. Und das ist offenbar sehr produktiv.
Und an dieser Stelle finde ich den Artikel auf einer Meta-Ebene sehr interessant: Die Autoren haben ein “Naturgesetz” in Frage gestellt – nämlich dass hochproduktives Arbeiten nur im Flow möglich ist. Und so konnten sie etwas wirklich Neues entdecken. Respekt!
4 comments Januar 18, 2010
Festpreise, Aufwandsprojekte und dann?
Vor kurzem habe ich hier zu Festpreisen und Aufwandsprojekten geschrieben. Und ich hatte versprochen noch etwas mehr dazu zu schreiben.
Das große Problem an beiden Vertragsformen ist ihre Kostenorientierung. Die Kosten stehen im Vordergrund und damit gehen auch immer alle Diskussionen in Richtung Kostenreduktion.
Ich möchte keine Kostenstelle sein! Ich will Geschäftswert schaffen.
Wie wäre es also zur Abwechslung mal mit wertorientierten Vertragsformen? Warum lassen wir uns als Softwareentwickler nicht prozentual an den Werten beteiligen, die unsere Software für den Auftraggeber schafft?
Dann haben Auftragnehmer und Auftraggeber dasselbe Ziel. Und wenn der Auftragnehmer durch Scrum ganz furchtbar produktiv wird, profitiert er auch davon.
Neu ist die Idee übrigens nicht. Kent Beck hat schon in der zweiten Auflage des XP-Buchs “Pay per Use” gefordert; ein mögliches Vertragsmodell, aber nicht das einzige.
2 comments Januar 15, 2010
