Wie Softwareentwicklung im Kanban-Stil uns eine weitere Möglichkeit gibt, das zu liefern, was wir mit den Agilen Werten versprechen

Übersetzung des Artikels Kanban development oversimplified von Jeff Patton, mit freundlicher Genehmigung des Autors. Danke, Jeff!

Deutsche Übersetzung: Matthias Bohlen

Agile Entwicklung ist ein Wertesystem, kein Prozess

Das Agile Manifest ist eine kurze, 4-zeilige Reihe von Sätzen, die angeben, was wichtig ist für die, die Agile Entwicklung praktizieren. Diese Aussagen sind die “Mutter und Apfelkuchen” Anweisungen für Agilisten. Es gibt keine festgelegten, spezifischen Prozesse – allerdings hat sich in den letzten Jahren einiges als gängige Praxis ergeben.

(Weitere Informationen über agile Wertesysteme und Kultur lesen Sie unter Agile ist Kultur, nicht Prozess.)

Gängige Agile Praxis nimmt das Beste vom Buffet

Spezifische Prozesse nennen sich selbst “agil”, wenn sie glauben, das Wertesystem, das zu ihrer Entstehung geführt hat, ein agiles Wertesystem ist. Scrum und Extreme Programming beherrschen derzeit die namens Agilen Prozesse. Weniger bekannt, aber ebenso wichtig, sind die agilen Prozesse Crystal, Dynamic Systems Development Methodology (DSDM), Feature Driven Development (FDD), und wahrscheinlich noch ein paar andere. Jeder dieser Prozesse strickt mehrere wertvolle Verfahren und einen typischen Ablauf zusammen. Wenn Sie alle diese bewährten Praktiken auf einen auf einen Tisch werfen würden, hätten Sie ein ganz schönes Buffet mit sehr guten Praktiken, mit denen Sie Ihren eigenen Prozess zuschneidern können. Und das ist genau das, was die meisten Unternehmen tun.

Es ist üblich, einen Certified Scrum Master-Kurs zu nehmen, in dem Sie die Vor-und Nachteile der Scrum Master Rolle von Grund auf kennenlernen, doch heute lernen Sie nicht nur die Grundlagen von Scrum, alle seine Rollen und den Prozessablauf, sondern viele weitere Verfahren, die nicht im ursprünglichen, von Ken Schwaber und Mike Beedle beschriebenen Prozess enthalten waren. (Ist das Vergoldung oder Evolution?) Es ist üblich, Verfahren für die Verwaltung von Anforderungen mit XP-User Stories einzuführen und Release-Planung im XP-Stil durchzuführen. Es ist üblich, die ursprüngliche Empfehlung von einem Kalendermonat für einen Scrum Sprint (Entwicklungszyklus) auf 2 Wochen zu schrumpfen. Es ist üblich, Schätzungen im XP-Stil zu verwenden. Es ist üblich, einen Sprint mit einer Reflexionssitzung oder Retrospektive zu beenden, die in Ansätzen wie Crystal oder DSDM verwendet wird. Ich persönlich füge Verfahren für das UI-Design und -Testen, Story-Mapping und mehr Strenge in der gesamten Product-Owner/Kunden-Rolle hinzu. Scrum, das einmal einfach war, läuft nun Gefahr, in seiner Verzierungsvielfalt geradezu barock zu werden.

Der typische Agile Prozess von heute, egal, wie Sie ihn nennen, nimmt das Beste aus dem Buffet der agilen Praktiken um einen typischen Prozess mit diesen Eigenschaften zu schaffen:

  1. Projektbedürfnisse und Anforderungen werden als User-Stories ausgedrückt in ein Backlog gebracht, und im Idealfall von Product Owner (in Scrum) oder Kunde (XP) in Zusammenarbeit mit dem Entwicklungs-Team geschrieben. (Manchmal erscheinen sie einfach auf magische Weise.)
  2. Entwickler geben High-Level-Schätzungen ab, die sagen, wie lange User Stories in Anspruch nehmen werden bis sie fertig sind.
  3. Product Owner organisieren User-Stories in inkrementellen Releases, die in der Regel zwischen 6 Wochen und 6 Monaten dauern.
  4. Product Owner wählen die nächsten Stories, jeweils mit dem höchsten Wert zuerst, für jede Entwicklungs-Timebox aus. Die gewählten Stories müssen in die Timebox “passen”, basierend darauf, wie schnell das Team produzieren kann.
  5. Am Ende jeder Entwicklungs-Timebox sollte das Team inkrementell einen Teil des Produktes gebaut haben. Das Team zeigt (stolz) das fertige Produkt dem Product Owner und den anderen Stakeholdern.
  6. Das Team addiert die Schätzungen für die User-Stories, die in der Timebox abgeschlossen wurden. Dies ist die Geschwindigkeit (“velocity” aus XP), die verwendet wird, um die Menge zu schätzen, die in der nächsten Timebox abgeschlossen werden kann
  7. Das Team hält eine Retrospektive, um zu bewerten, wie gut sie gearbeitet haben und welche Veränderungen könnte am Prozess gemacht werden könnten, damit die Dinge noch besser gehen, dann wird der Entwicklungszyklus als Timebox geplant.
  8. Timebox-Entwicklung geht weiter bis zur Freigabe – kurz: “spülen und wiederholen.”

Es gibt noch mehr übliche Praktiken, wie z.B. das tägliche Standup-Meeting, um das Team zu synchronisieren, Burndown-Charts, um den Entwicklungsfortschritt anzuzeigen, doch das soll genügen, um meinen Standpunkt zu zeigen: Der heutige agile Prozess ist ein Mash-Up aus vielen guten Ideen aus einer Vielzahl von Quellen.

Shift happens: Langsame Veränderung gemeinsamer agiler Praktiken verursacht gemeinsame Probleme

In vielen Organisationen funktioniert dieser Ablauf ziemlich gut. Jedoch gibt es ein paar übliche Komplikationen, die Ärger machen. Die Probleme, die ich herausgefunden habe, scheinen mit Größe zu tun zu haben. Größe ist immer wichtig. (Siehe auch das alte aber immer noch relevante Geheimnis der schrumpfenden Story).

Schrumpfende Stories machen agile Entwicklung leichter

In Organisationen, die agile Entwicklung praktizieren, herrscht ein gewisser Druck, die User Stories zu schrumpfen, sozusagen “kleinere” Geschichten zu erzählen. Es gibt viele gute Gründe dafür.

Es ist viel leichter, eine kleine Story zu schätzen – das kann zu genaueren Schätzungen und besserer Vorhersagbarkeit führen.

Es ist leichter, mit kleinen Stories zu planen. Mit großen Stories – solche, die einen Entwickler Wochen kosten, um sie zu implementieren – mit solchen wird es schwierig, eine Entwicklungs-Timebox zu planen, besonders, wenn diese Timebox selbst nur ein paar Wochen lang ist. Es scheint, als ob nur wenige Stories hineinpassen – und es gibt oft Platz für eine halbe Story – aber: wie baut man eine halbe Story? Stories in kleinere aufzuspalten macht es einfacher, die Timeboxes zu planen.

Schrumpfende Stories machen agile Entwicklung schwieriger

Wenn Sie Stories geschrumpft haben, tauchen neue Probleme auf. User Story Backlogs werden größer und schwieriger zu verwalten. Als Kent Beck in der ersten Auflage von “Extreme Programming Explained” die Praktik des User-Story-Schreibens beschrieben hat, hatte eine User Story noch eine “Schätzung zwischen einer und fünf idealen Programmierwochen”. Heute verlangt eine “best practice” Stories, die man in einigen Tagen oder weniger umsetzen kann – das ist locker ein Fünftel ihrer ursprünglichen Größe. Ursprünglich hatte die anfängliche Liste für ein Projekt vielleicht Dutzende von Stories. Heute kann sie leicht auf hunderte von Stories anwachsen. Priorisieren, verwalten und Planung mit einem solchen Backlog kann eine lästige Erfahrung sein.

Stories zu schrumpfen zwingt zu früherer Ausarbeitung und Entscheidung. Wo Product Owner ihre Stories sonst sehr generell schreiben und über viele Details später nachdenken konnten, zwingt das Herunterbrechen von Stories uns heute dazu, im Planungszyklus viel früher nachzudenken.

Kleine Stories zu verwalten zwingt uns dazu, besser zu verfolgen, wie sie zusammenpassen. Von Product Ownern wird oft verlangt, Stories so weit herunterzubrechen bis eine einzelne Story bedeutungslos wird. Um zu verfolgen, was für Product Owner und andere Stakeholder Bedeutung hat, müssen sie oft größere Items verfolgen wie z.B. Produktfeatures und wie viele Stories dazu beitragen, solch ein Feature zu bauen.

Kurze Timeboxen machen agile Entwicklung leichter

Es geht schneller, wenn man eine kurze Timebox plant. Ursprünglich schlug XP vor, Timeboxes oder Iterationen ca. 2-4 Wochen lang zu machen. Scrum empfahl ursprünglich einen Kalendermonat so dass die Entwicklungs-Timebox sich besser mit den Geschäftsmonaten und Quartalen synchronisieren ließ. Jeder, der schon einmal an einem agilen Planungsmeeting teilgenommen hat, weiß, dass diese oft eine Stunde länger dauern können als man aushalten kann. Kurze Iterationen – sagen wir, eine Woche oder zwei – erlauben es, schneller zu planen. Dieser Tage sind zwei Wochen für eine typische agile Iteration üblich.

Aus einer kurzen Timebox bekommen wir Feedback schneller. Am Ende einer agilen Timebox haben Sie die Chance, sich lauffähige Software anzusehen und Änderungen an Ihrem Produktplan oder Product Backlog zu machen. Wir können auch die Entwicklungsgeschwindigkeit des Teams messen, die “velocity”. Und mittels einer Retrospektive können wir Prozessverbesserungen vorschlagen und umsetzen. Das ist es, was Agile Entwicklung agil macht: häufige Gelegenheit, das Produkt zu evaluieren, die Geschwindigkeit der Entwicklung und den Prozess, den wir benutzen.

Kurze Timeboxen machen agile Entwicklung schwieriger

Kurze Timeboxen “platzen”.

Die Erarbeitung der Story-Details springt aus der Timebox heraus: Während einer idealen agilen Timebox habe wir häufige Diskussionen zwischen Entwicklern, Testern und den Mitgliedern des Product Owner Teams – wie z.B. Business Analysten, Spezialisten für Benutzeroberflächen und Leute vom Fachbereich. Wir machen das, weil wir verstehen wollen, was wir bauen müssen und um zu beschreiben, wie wir validieren wollen, dass eine Story tatsächlich fertig (“done”) ist. Wenn Timeboxen kurz sind, gibt es weniger Zeit für diese Konversation. Es ist üblich, viele von diesen Gesprächen zu Storydetails und Akzeptanzkriterien in die vorhergehende Timebox zu verschieben, so dass wir bereit für die Entwicklung sind, sobald die neue TImebox beginnt. Einige Scrum-Praktiker fangen an, genau zu definieren, was bereit (“ready”) eigentlich heißt – welche Arbeit geleistet werden muss, bevor eine Story in einen Sprint aufgenommen werden kann.

Akzeptanztests springen aus der Timebox heraus: Es ist schwierig, gründliche Akzeptanztests für eine Story mit in derselben Timebox unterzubringen. Also schlüpfen die Akzeptanztests oft in die nachfolgende Timebox. Was natürlich das lästige Problem hervorruft, was mit Bugs zu tun ist, die oft in eine nachfolgende Timebox eingespeist werden.

Das Ergebnis dieser Aktivitäten, die aus der Timebox herausspringen, ist ein Zyklus, der tatsächlich 3-4 mal länger ist als unsere Timebox. Um Arbeit wirklich abzuschließen, brauchen wir eine Timebox, um die Storydetails abzustimmen, eine um sie zu entwickeln, eine um sie gründlich zu testen und (falls es Bugs gibt) möglicherweise eine weitere, um diese zu fixen.

Die Kommunikation lässt nach und Ermüdung setzt ein. Während die Timeboxen schrumpfen, finden sich die Leute im Product Owner Team und die Tester ständig in einem Modus des Bereitmachens für eine nächste Timebox und des Evaluierens der vorherigen. Sie arbeiten mit Überstunden, gehen in eine Menge Besprechungen und scheinen immer weniger Zeit dafür zu haben, den Entwicklern bei der aktuellen Timebox zu helfen. Weil ihr Fokus auf einer zukünftigen oder vergangenen Timebox liegt, erscheinen Fragen zur aktuellen Timebox wie Unterbrechungen. Die Zusammenarbeit lässt nach und Spannungen nehmen zu. Die Arbeitsbelastung ist schwer, sprunghaft, nicht weich oder gleichmäßig.

Lean Thinking anwenden auf Agilität – bricht das die Regeln?

In den letzten paar Jahren hat eine große Zahl von agilen Praktikern begonnen, Gedanken aus dem Lean Manufacturing in ihre agilen Ansätze einzubeziehen. Anfänglich angeführt von Tom & Mary Poppendieck in ihrem Buch Lean Software Development , finden Sie heute weltweit Praktiker, die über schlanke Prozessveränderungen reden und diese auf ihre agilen Ansätze anwenden. In der letzten Zeit habe ich viele Diskussionen über Entwicklung im Kanban-Stil gehört – ein Ansatz, der die primäre Regel der heutigen agilen Praxis durchbricht: die feste Entwicklungs-Timebox. Während viele darüber geschrieben und geredet haben, führte David Anderson frühe Expeditionen in diesen Raum und arbeitet immer noch hart als Vordenker.

Kanban im Lean Manufacturing

Sie werden bemerken, dass viel von der Lean-Terminologie aus Japan kommt, besonders aus dem Toyota Production System.  ”Kan” bedeutet wörtlich übersetzt visuell, und “ban” bedeutet Karte oder Tafel.

Stellen Sie sich, Sie seien auf einer Toyota Produktionsstraße. Sie setzen Türen in Priuses ein. Sie haben einen Stapel von etwa 10 Türen. Während Sie die Türen annieten wird Ihr Stapel von Türen kleiner. Wenn nur noch 5 Türen übrig sind, befindet sich auf der Oberseite der fünften Tür eine Karte – eine Kanban-Karte – die besagt: “Baue 10 Türen”. Naja, vielleicht sagt sie nicht exakt das, dich sie ist eine Aufforderung, exakt 10 weitere Prius-Türen zu bauen.

Sie nehmen die Karte an sich und laufen zu dem Burschen rüber, der die Türen baut. Er hat schon auf Sie gewartet. Er hat andere Dinge getan, um beschäftigt zu sein, während er wartet. Das Wichtigste ist hier: Er hat KEINE Prius-Türen gebaut. Er nimmt Ihre Karte und beginnt erst jetzt, Türen zu bauen.

Sie kehren zurück zu Ihrer Arbeitsstation und einen kurzen Moment bevor Ihr Türenstapel leer ist, kommt der Bursche zurück mit einem Stapel von 10 neuen Türen. Sie wissen, dass zwischen Tür 5 und 6 wieder eine Kanban-Karte eingesteckt ist. Sie haben die Türen genau zum richtigen Zeitpunkt (“just in time”) bekommen. Die ganze Sache funktioniert wie Zauberei. Sie werden sich lediglich wünschen, Sie hätten den Job, Türen zu bauen. Der Bursche da drüben scheint jedenfalls eine Menge freie Zeit zu haben.

Kanban-Karten werden benutzt, um den Lagerbestand, den die Fabrik aufbaut, zu begrenzen. Es tut der Toyota-Fabrik nicht gut, wenn sie Türen schneller baut als sie Autos zusammenbauen kann. Es wäre reine Geldverschwendung durch zu viele ungenutzte Türen und Teile für Türen. Überschüssige, noch laufende Arbeit (“work in progress”) wird im Lean Manufacturing als Verschwendung (“waste”) angesehen. (Es ist möglicherweise auch Verschwendung im Nicht-Lean Manufacturing.) Im obigen, frei erfundenen Beispiel haben Sie niemals mehr als 15 fertige Türen, die herumhängen. (Mudha ist das japanische Wort für Verschwendung. Lernen Sie es, um Ihre Lean-Freunde zu beeindrucken.)

Durch die Nutzung von Kanban-Karten haben wir das Limit auf 15 gesetzt. Kanban funktioniert also ein bisschen wie eine Währung. Genau wie es in einem System nur eine feste Geldmenge gibt, die durch den Gelddruck begrenzt wird, so gibt es auch nur einen festen Lagerbestand, der durch die Kanban-Karten begrenzt wird. Eine simple Art und Weise, die Dinge zu managen, finden Sie nicht? Corey Ladas erklärt das gut in seinem Scrumban-Artikel und Buch.

Kanban-Entwicklung begrenzt Dinge in Arbeit

Die Kanban-Denkweise in der Softwareentwicklung versucht, etwas ähnliches zu tun. Wir wollen, dass nur so viele Dinge in Arbeit sind wie nötig sind, um den Durchsatz des Teams zu unterstützen. Die Kanban-Denkweise, wenn man sie auf die agile Entwicklung anwendet, fegt vieles von dem hinaus, was die Agilen bisher als notwendige Praktiken betrachten.

In der Kanban-Entwicklung…

  • ist Timebox-Entwicklung “out”
  • sind Stories größer und es gibt weniger
  • ist Schätzen von Aufwänden optional oder völlig “out”
  • wird die Geschwindigkeit als Messgröße durch die Zykluszeit ersetzt

Inzwischen sollten Sie soweit sein, sich ein bisschen am Kopf zu kratzen. Was bleibt denn überhaupt vom agilen Vorgehen noch übrig, wenn wir Timeboxes loswerden, die Bedeutung von Stories verändern und aufhören, die Geschwindigkeit zu messen. Und: Was haben Autotüren und Kanban-Karten mit Softwareentwicklung zu tun?

Hängen Sie bitte nicht am Prozess! Denken Sie daran, agile Entwicklung ist kein Prozess.

Kanban-Entwicklung, auf den Punkt gebracht

Bei der Kanban-Entwicklung dreht sich alles um eine sichtbare Tafel, um die Dinge, die in Arbeit sind, zu verwalten. (Nicht überraschend, da Kanban visuelles Bord bedeutet). Es ist bei agilen Teams üblich, die Stories der aktuellen Timebox auf einer Tafel (Brett) zu halten, mit Spalten für die Zustände, durch die die Stories hindurchgehen wie z.B. “Entwicklung” oder “Akzeptanztest”. Das Kanban-Brett ist ähnlich – mit ein wenig mehr Regeln.

Die Grundidee: Stories starten links und sausen über das Brett nach rechts, durch die Entwicklungsphasen, durch die sie hindurch müssen, um als fertig (“done”) zu gelten. Fertige Stories, die zur Produktion freigegeben werden können, stapeln sich am Ende. Und, weil dies ein Kanban-Brett ist und wir die Zahl der Dinge in Arbeit begrenzen wollen, begrenzen wir einfach die Zahl der Stories auf dem Brett. Die Zahlen am unteren Rand begrenzen die Zahl der Stories, die an jeder Station erlaubt sind.

Dieses Beispiel-Kanbanbrett wurde mit Hilfe von Stickern, Whiteboard-Stiften und blauem Doppel-Klebeband (Malerband) realisiert.

Das Kanban-Brett von links nach rechts

1. Ziele

Ganz weit links auf dem Brett gibt es eine Spalte “Goals”. Hier finden wir die großen Ziele des Produktes – die großen Dinge, die wir vorantreiben und die uns dazu bringen, Software zu schreiben, die diese Ziele erreicht. Sie links am Brett zu halten sorgt dafür, dass alle am selben Strang ziehen – fokussiert auf die Erreichung dieser Ziele. Diese Idee habe ich von Arlo Belshee gestohlen, der herausfand, dass die Stories nicht so stark “herumtanzen”, wenn man Ziele links platziert. Herumtanzen findet statt, wenn sich die Priorität sehr oft ändert.

2. Story-Warteschlange

Die nächste Spalte enthält die Stories, die darauf warten, gestartet zu werden. Es ist eine Warteschlange, weil die Stories “Schlange stehen” – die Story ganz oben wird die erste sein, deren Entwicklung gestartet wird. Nach dem Start verlässt sie die Warteschlange und alle anderen rücken einen Platz auf.

3. Story-Prozessschritte

Direkt rechts neben der Story-Warteschlange ist eine Anzahl von Spalten mit den Prozessschritten, durch die eine Story gehen muss, um als fertig (“done”) zu gelten.

Die erste Spalte wird oft zur Ausarbeitung der Story genutzt. In den Entwicklungsteams bei Yahoo wird sie UED genannt, für “user experience design”. Wenn sich eine Story hier befindet, wird das UI prototypisch entwickelt oder ausreichend beschrieben so dass die Entwicklung weitergehen kann. Sie könnten auch eine Spalte haben, in der Business-Analysten Zeit verbringen, um technische Details niederzuschreiben, die von den Entwicklern verstanden werden müssen um Code zu schreiben.

Die nächste Spalte wird meist für die Entwicklung benutzt. Und, die Spalte danach für den Akzeptanztest.

Diese Spalten sind nicht gesetzt. Sie sollten mit Ihrem Team diskutieren, was die Phasen sind, durch die die Stories bis zur Fertigstellung hindurchgehen. Manche Organisationen werden Spalten zum Schreiben von Dokumentation benutzen, oder zur Einarbeitung von Kundendienst-Mitarbeitern, die ein Feature in der Produktion unterstützen müssen.

Dies sind auch keine Stellenbeschreibungen. Obwohl es sein kann, dass die Stellenbeschreibungen verschiedener Leute sich auf verschiedene Spalten beziehen, fokussieren Sie auf die Story und auf das, was sie braucht, um zu reifen. Beispiel: Wenn Ihre Organisation keine Business-Analysten oder GUI-Experten hat, benutzen Sie die erste Spalte für die Stelle in der Story-Ausarbeitung, in der sich Entwickler zusammensetzen und mit der Fachseite reden, um Akzeptanztests für die Story zu beschreiben – beschreiben Sie, was “fertig” bedeutet. Es ist generell eine schlechte Idee, mit dem Codeschreiben (der nächsten Phase) anzufangen, wenn Sie nicht wissen, wie Sie herausfinden können, dass Sie fertig sind.

Jede Prozessschritt-Spalte ist in zwei Teile aufgeteilt: Der obere wird für die Stories benutzt, die in dieser Phase gerade in Arbeit sind. Der untere Teil ist der Puffer. Wenn die Arbeit für diese Phase der Story beendet ist, wandert sie von “in Arbeit” auf den “Puffer”, wo sie darauf wartet, in die nächste Phase gezogen zu werden. Der letzte Prozessschritt hat keinen Puffer – weil die Story fertig ist, wenn jene Phase beendet ist. Wenn wir Begrenzungen für die Zahl der Dinge in Arbeit einführen, setzen wir eine Gesamtzahl für diesen Prozessschritt fest, die sowohl “in Arbeit” als auch den “Puffer” für diesen Schritt beinhaltet.

4. Fertig

When die Story die “Done”-Spalte erreicht, ist sie bereit, wirklich bereit zum Einsatz in der Produktion.

Stories müssen minimal marktfähige Features sein

Der Ausdruck minimal marktfähiges Feature (“minimal marketable feature”, MMF) wurde erstmals in dem Buch Software by Numbers benutzt. Dieses Buch legt die Betonung auf die kleinste Menge an Arbeit, die man in Produktion freigeben könnte und die trotzdem einen Wert für die sich ergebenden Kunden oder Benutzer haben würde.

Um marktfähig zu sein, muss das Feature groß genug sein, um nützlich zu sein – vielleicht größer als die Teenie-Stories, die nur ein paar Tage brauchen, um gebaut zu werden und die heutzutage als “best practice” in der agilen Entwicklung gelten. Ein MMF kann Wochen zum Bauen brauchen. Aber das Wichtige ist nicht, wie lange es zum Bauen braucht, sondern dass es verständlich und wertvoll für diejenigen ist, die es bekommen. Um ein MMF zu identifizieren, stellen einige Leute die Frage “Würde ich es in dem Produkt-Blog meiner Firma ankündigen?” Wenn es zu klein ist, um erwähnt zu werden, dann ist es kein MMF.

Dies ist ein wichtiger Teil der Kanban-Entwicklung, bei der der Fokus auf dem wachsenden Wert liegt, der aus dem Entwicklungsprozess freigesetzt wird. Jedes freigegebene Ding muss in sich selbst wervoll sein.

Ein Limit für die Zahl der Dinge in Arbeit setzen

Um “lean” zu sein, begrenzen wir die Zahl der Stories, die wir auf dem Brett erlauben. Eine übliche Formel ist: Zähle alle Mitglieder des Teams in allen Rollen zusammen und teile durch zwei. Alle Rollen beinhaltet Entwickler, Analysten, GUI-Designer, Tester, Betriebsleute – jeder, der direkt verantwortlich dafür ist, Features auf den Markt zu kriegen. Beispiel: Wenn das Team 20 Mitglieder hat, limitieren wir die Zahl der MMF-Stories “in Arbeit” auf dem Brett auf 10.

Nun müssen wir Limits für jede Spalte setzen.

Für die “Stories”-Warteschlange – da, wo die Stories geduldig Schlange stehen, bevor sie in den Prozess gehen, setzen Sie das Limit auf etwa die Hälfte des Limits für “in Arbeit”. Beispiel: Wenn das “in Arbeit”-Limit 10 ist, begrenzen Sie die Warteschlange auf 5.

Für die Limits der Story-Prozessschritte ist das Limit oft die Hälfte der Zahl der Leute, die an dieser Entwicklungsphase arbeiten können. Beispiel: Wenn Sie 6 Entwickler haben, können Sie die Spalte “Entwicklung” auf 3 begrenzen.

Nun, das wird Entwickler dazu bringen, an Stories gemeinsam zu arbeiten. Ich finde, dass das in der Praxis nicht immer für alle Teams funktioniert – also sehe ich öfters Limits, die gleich der Zahl der Entwickler sind (zumindest derjenigen, die diesen Prozessschritt ausführen können) oder oft 1.5 mal so viel wie Leute in einer Rolle. Natürlich wird die Zahl der Dinge in Arbeit ansteigen, wenn Sie das tun – und wie Sie möglicherweise erwarten, werden die Dinge länger brauchen, um fertig zu werden.

Wenn Sie die Limits für jeden “in Arbeit”-Slot auf dem Brett zusammenzählen, dann sollte sich wieder Ihr am Anfang gesetztes Limit für “in Arbeit” für das gesamte Brett ergeben. Es kann sein, das Sie an den Limits für jeden Prozessschrit etwas rütteln müssen, damit sie wirklich gut funktionieren. Oder, Sie können das Gesamtlimit für “in Arbeit” anheben – das ist ein bisschen wie mehr Geld drucken, wenn es Ihnen ausgeht.

In dem Beispiel-Kanban-Brett sind die “Kanbans” tatsächlich die blauen Klebeband-Linien, die die Stellen markieren, an denen Sticky Notes gesetzt werden dürfen. Jede Bandlinie in den Bereichen “in Arbeit” und “Puffer” repräsentiert ein Ding, das in Arbeit sein darf. Sie können denselben Effekt erreichen, indem Sie das Limit einfach über die Spalte schreiben.

Das Leben einer MMF-Story auf dem Kanban-Brett

Diese Geschichte beginnt mit einer Warteschlange von MMFs, die links auf dem Kanban-Brett geduldig warten. Sie sitzen neben den Zielen an der linken Kante, so dass jeder sehen kann, dass diese MMFs dem Produkt helfen werden, diese Ziele zu erreichen.

Ein UI-Designer und ein Business-Analyst arbeiten als Paar, sie ziehen eine Story aus der Warteschlange und rücken die anderen in der Schlange auf. Sie setzen die Story in ihre “Ausarbeitung in Arbeit”-Spalte. Sie stellen die notwendigen Stakeholder fest und führen die notwendigen Gespräche um zu beschreiben, wann die Story als akzeptiert gelten wird. Sie treffen sich auch mit den Entwicklern, um sicherzustellen, dass die Akzeptanzkriterien dort auch verstanden werden und vollständig genug sind, um weiterzumachen. Alle stimmen zu: Ja, sie sind es.

Der Business-Analyst sagt: “Ich schiebe es also in den Puffer”. “Nicht nötig”, sagt der Entwickler, mein Slot für ‘in Arbeit’ ist leer, also ziehe ich sie direkt dorthin und fange an.”

Ein Kanban-System zu benutzen, bedeutet nicht, dass wir einem Wasserfallprozess folgen. Nur weil wir einen schrittweisen Prozess von links nach rechts aufgezeichnet sehen, glauben viele fälschlicherweise, dass die Leute sich nicht mehr kollaborativ verhalten werden.

Beachten Sie, wie die BAs und die UI-Designer mit den Stakeholdern und den Entwicklern zusammengearbeitet haben. Sie waren dafür verantwortlich, die Arbeit in dem Slot zu tun. Aber, das hieß nicht, dass sie nicht mit anderen in den anderen Rollen zusammenarbeiteten. In einer gesunden Kanban-Praxis werden Sie sehen, dass es viel Zusammenarbeit über einen Schritt hinaus gibt.

Während wir weiter an der Story arbeiten, sehen wir sie sich über das Brett von links nach rechts bewegen, weil diejenigen, die an einer bestimmten Phase im Lebenszyklus der Story arbeiten, die Arbeit tun, die nötig ist, um die Story weiterzubewegen. Sie sind vorsichtig, nicht irgendwas “über den Zaun” zu werfen. Sie wissen, wenn sie etwas in ihren Puffer schieben, was nicht wirklich bereit ist, werden diejenigen, die für die nächste Phase verantwortlich sind, es nicht hereinziehen – sie werden es zurückweisen. Das macht Zusammenarbeit und Kommunikation essenziell.

Es ist OK, wenn ein Ding sich auf dem Kanban-Brett zurückbewegt, wenn jemand an einer flussaufwärts gelegenen Arbeitsstation noch einmal etwas nacharbeiten muss, um die Qualität zu verbessern.

Die Zeit vergeht. Stories werden ausgearbeitet, in die Entwicklung bewegt, dann in den Test.

Aber, plötzlich entsteht eine “Falte”.

Heute haben Entwickler eine Story fertiggestellt und als sie zum Kanban-Brett gehen, um sie aus der Entwicklung hinauszuschieben, stellen sie fest: Ihr einziger Pufferplatz ist voll – und die “Test in Arbeit”-Spalte ist bis zu ihrem Limit gefüllt. Was jetzt?

Die Entwickler sprechen mit den Testern. “Wir kommen kaum noch mit, hier! Es wird morgen früh werden, bevor wir einige von diesen Stories hinausschieben können.” “Hmm”, sagt ein Entwickler, “können wir beim Testen helfen?” “Natürlich könnt Ihr!”, sagt der Tester. “Mit Eurer Hilfe kriegen wir diese hier sauber raus bis zum Ende des Tages.” Der Tester grinst: “Ich möchte nur nicht, dass Ihr die Stories validiert, die Ihr selbst implementiert habt.”

Limits zeigen Engpässe auf

Wenn eine Spalte auf dem Kanban-Brett voll ist, wissen wir, dass jene Gruppe ihre Kapazitätsgrenze erreicht hat. Wir wissen auch, dass wenn das dauernd passiert, wahrscheinlich der Engpass in diesem Schritt ist.

Wenn wir ein Kanban-System benutzen, lernen wir ziemlich schnell, was die Fertigstellung der Stories verlangsamt und wir können Schritte zur Performanceverbesserung einleiten, genau an der Stelle, wo es drauf ankommt. Woanders etwas zu verbessern wird nicht den Durchsatz nicht steigern helfen. Tatsächlich, wenn Leute flussaufwärts in ihrem normalen Trott weiterarbeiten, werden die Leute flussabwärts immer weiter ins Hintertreffen geraten.

Letzendlich wollen wir herausfinden, wir wir Entwicklung und Durchsatz weich und gleichmäßig erhalten können – wiederholt auftretende Engpässe zu finden und unsere Arbeitsweise zu verändern oder die Zahl der Leute  in einer bestimmten Rolle, das alles wird helfen, die Engpässe zu beseitigen. Dieses Ausbalancieren von Arbeit ist es, was die Lean-Leute Heijunka nannten, mit dem Ziel, Ungleichmäßigkeit oder Mura zu eliminieren. Mindestens ein Experte, den ich kenne, sagte es sei in Wirklichkeit eine Heijunka-Box, als er ein Kanban-Brett sah – das Ding, das wir aufstellen, um Dinge in Arbeit zu zeigen, mit dem Ziel, auszugleichen. Ich bin kein Experte und möchte mich deshalb nicht zu sehr in der Terminlogie verstricken. All das, was im Lean Manufacturing so strikt definiert ist, wirkt im Bereich der Softwareentwicklung ohnehin oft etwas bemüht.

Beschleunigen Sie auf der Überholspur

Es gibt immer dringende Feature-Anforderungen oder Probleme in der Produktion, die sofort behandelt werden müssen. Über der Story-Warteschlange und den Prozesschritt-Slots befindet sich ein “Überholspur”-Slot. Die Zeile mit den Überholspur-Slots bildet eine “Autobahn” am oberen Rand des Kanban-Bretts. Wenn ein Ding hier in diesen Autobahn-Slot platziert wird, wird es sofort zur höchsten Priorität für das Team. Es wird aus diesem Slot gezogen und so bald wie möglich durch die Story-Prozessschritte bewegt, noch vor allen anderen Sachen, die noch in Arbeit sind.

Messen Sie die Performance durch die Zykluszeit

Es ist in der agilen Entwicklung üblich, die “velocity” zu messen, und zwar als Summe der Schätzungen der fertiggestellten Stories in einer Entwicklungs-Timebox. Da es in Kanban jedoch keine solche Entwicklungs-Timebox gibt, messen wir Story für Story, wie lange sie zur Fertigstellung gebraucht hat – die “Zykluszeit” der Story.

  1. Wenn eine Story in die Warteschlange kommt, schreiben Sie darauf das Eintrittsdatum.
  2. Wenn die Story in den ersten Prozessschritt kommt, schreiben Sie den Tag auf, an dem sie gestartet wurde.
  3. Dann endlich, wenn sie die letzte “Fertig”-Spalte am Ende des Bretts erreicht, schreiben Sie auf die Storykarte den Tag der Fertigstellung.

Jetzt haben Sie die Zahlen, die Sie benötigen, um die Zykluszeit zu berechnen.

Die Differenz zwischen Eintrittsdatum und Fertigstellungsdatum ist die Zykluszeit, die auch die Wartezeit in der Warteschlange mit enthält. Um die Zykluszeit für neue Stories zu schätzen, nehmen Sie die durchschnittliche Zykluszeit der fertiggestellten Stories.

Berechnen Sie auch die Zeit zwischen “gestartet” und “fertig”, das ist die Arbeits-Zykluszeit. Diese wird zwar auch die Zeit enthalten, während der die Story untätig in den Puffern sitzt – aber das ist es, was Zykluszeit heißt. Wenn Sie feststellen, dass relativ triviale Stückchen Arbeit eine Zykluszeit von zwei Wochen haben, dann sollte Ihnen das etwas sagen.

Wenn Sie jemals in Disneyland für “Piraten der Karibik” Schlange gestanden haben, erinnern Sie sich vielleicht an die Zeichen am Wegesrand, die sagen “Ihre Wartezeit von hier aus ist 30 Minuten” – irgendetwas in dieser Art. Nun können Sie Ihre eigenen Wartezeiten an Ihr Kanban-Brett heften. Schreiben Sie an den unteren Rand Ihrer Story-Warteschlange die durchschnittliche Zykluszeit inklusive Wartezeit. Es wird vielleicht heißen “Ihre Wartezeit für eine Story ist hier ungefähr 18 Tage.” Schreiben Sie an den oberen Rand der Warteschlange die durchschnittliche Arbeits-Zykluszeit. Das könnte z.B. so heißen: “Ihre Wartezeit von hier aus ist ungefähr 14 Tage.”

Wer braucht Schätzungen?

Wenn Sie den Fokus darauf legen, wie schnell Sie Funktionalität fertigstellen können, und wenn Sie die Fähigkeit haben, nur das zu messen, dann sind Schätzungen nicht so wichtig. Tatsächlich haben viele, die einen Kanban-Ansatz benutzen, ganz aufgehört zu schätzen. Ja, Story-Größen variieren, doch eine Wartezeit plus oder minus einige Tage angeben zu können, ist für die Belange vieler Organisationen völlig ausreichend.

Einige schätzen immer noch die Stories. In diesem Fall, benutzen Sie die Schätzungen zusammen mit der Zykluszeit. Wir können mit Hilfe eines Spreadsheets die durchschnittliche Zykluszeit für Stories mit einer gegebenen Schätzung ausrechnen. Wenn Sie das tun, überlegen Sie doch, ob Sie nicht ein praktisches Chart neben das Kanban-Brett hängen, auf dem die Schätzungen in der einen Spalte, die Zykluszeiten in der anderen Spalte gezeigt werden. Auf diese Weise beantworten Sie die wirkliche Frage der Stakeholder, wenn sie Schätzungen bekommen: “Und wann kann ich diese Funktionalität in der Software sehen?”

Wenn Ihre Stakeholder sind wie meine, werden sie nicht wissen wollen, wann sie diese Funktonalität bekommen, sondern wann sie all diese Funktionalität bekommen. Wenn ich Stories in ein Spreadsheet schreibe, mit Start- und Enddatum und die Zykluszeit berechne, und wenn ich dann einen beliebigen Zeitraum auswähle – zum Beispiel zwei oder drei Wochen – dann kann ich sehen, wie viele Stories in diesem Zeitraum abgeschlossen wurden. Zum Beispiel: Das Team hat 22 Stories in 3 Wochen abgeschlossen – das sind ungefähr 7,3 Stories pro Woche. Aus einem Backlog von 100 Stories kann ich sinnvoll ableiten, dass es zwischen 13 und 14 Wochen brauchen wird (100/7,3). Das ist das Wetter von gestern für Kanban – zumindest so wie ich es berechne.

Wenn ich weiß, dass während der drei Wochen 5 Entwickler je 15 Tage gearbeitet haben, dann sind das 75 Entwicklertage. Dieses Wissen hilft mir, die durchschnittliche Zahl von Entwicklertagen pro Story zu berechnen: 3,4 (75/22) – was gefährlich nahe an Pi liegt – das macht mich glauben, dass es stimmen muss. :-) Diese Zahl (3,4) ist es, die von den XP-Praktikern als load factor bezeichnet wird.

Evaluationszyklen, nicht Entwicklungs-Timeboxen

Sie werden immer noch einen “Herzschlag” eines regelmäßigen Zyklusses bei einem Team entdecken, das ein Kanban-Brett benutzt – zumindest, wenn die Leute Agilität richtig umsetzen, dann sollten Sie das entdecken können. Der einzige Unterschied ist, dass die Zyklen nicht mehr benutzt werden, um zu planen und sich auf Stories zu verpflichten.

Synchronisieren Sie das Team jeden Tag

Das tägliche Standup-Meeting oder Daily Scrum-Meeting findet wie üblich statt, doch nun findet es vor dem Kanban-Brett statt. Anstelle des regulären Meeting-Rituals der Abfrage aller Personen, was jeder gestern getan hat und was er heute tun wird, dreht sich die Diskussion jetzt eher um das Kanban-Brett und was wohl wahrscheinlich heute darauf kommt oder herunter kommt, wo der “dickste Verkehr” herrscht und was wir tun können, um Engpässe zu beseitigen.

Reflektieren Sie alle paar Wochen

Alle paar Wochen hält das Team immer noch eine Retrospektive, um den Prozess, dem es folgt, zu betrachten, Erfolge zu besprechen und Möglichkeiten, ihn zu verbessern.

Demonstrieren Sie Ihre Arbeit alle paar Wochen

Um die Arbeit den Stakeholdern außerhalb des Teams zu zeigen wird eine regelmäßige Produktdemonstration angesetzt. Sie zeigt das Produkt und dient dazu, Feedback von den Stakeholdern einzuholen.

Zurück zu den agilen Idealen

Das ist die Motivation die, die agile Entwicklung mit dem Kanban-Ansatz praktizieren. Das Agile Manifest hat die Dinge beschrieben, auf die agile Praktiker Wert legen, es schreibt aber nicht vor, dass Timebox-Entwicklung der Weg dahin sein muss.

Lean-Praktiken helfen dem Team, den Durchsatz zu steigern. Sie bringen Entwickler nicht dazu, schneller zu tippen, sondern sie lenken die Aufmerksamkeit auf Engpässe, die die Arbeit verlangsamen. Sie helfen Ihnen, die Engpässe zu sehen und schneller auf sie zu reagieren. Ein Kanban-Brett lässt Sie die Dinge, die in Arbeit sind, leichter visualisieren, über verschiedene Rollen hinweg. Das Brett lässt Sie auch sehen, wenn jemand sich zu viel Arbeit auf einmal vornimmt.

Ein Taskboard wie es üblicherweise in agilen Ansätzen benutzt wird, kann Ihnen diese Visualisierung auch geben. Doch das Taskboard zu erweitern, um Testen von Entwicklung oder anderen Prozessschritten zu unterscheiden, hilft mir besser zu sehen, wenn sich Dinge irgendwo aufstauen – es hilft mir, Probleme besser zu diagnostizieren. Und, das Setzen harter Limits für Prozessschritte und diese Limits zu respektieren, das hilft mir mit dem Problem auf eine Weise umzugehen, wie es das Fallenlassen eines Stapels voll Stories in einen Sprint oder eine Iteration nicht tat. Aber, vielleicht bin es nur ich, der faul ist und vermeidet, mit ernsthaften Problemen umzugehen. Ich bin sicher, Sie kämen niemals in eine Situation wo Sie und Ihr Team viel fertige Entwicklungsarbeit sich vor dem Test aufstapeln lassen.

Kanban macht kann sich gut bezahlt machen

Idealerweise bewegt das Kanban-Brett die MMFs quer in Richtung Produktion, sobald sie fertiggestellt worden sind. Für Organisationen, die diese hohe Lieferfrequenz ausnutzen können, ist das ein großer finanzieller Vorteil. Die simple Mathematik, die in “Software by Numbers” beschrieben ist, zeigt den immensen Anstieg bei der Return-Rate für das Investment.

Niemand ist so begeistert wie der frisch Konvertierte

Es gibt viele da draußen, die von Kanban begeistert sind. Ich auch. Manchmal nimmt die Begeisterung die Form an, Leuten, die übliche agile Timebox-Entwicklung praktizieren, zu erzählen, dass sie auf dem falschen Dampfer sind. Aber, ich denke, ich bin erfahren genug zu wissen, dass es viele richtige Wege zum Erfolg gibt und jeder, der glaubt, er habe den besten Weg gefunden, wahrscheinlich falsch liegt. Lassen Sie sich von den laut vorgetragenen Meinungen für oder gegen Kanban nicht abhalten, tiefer zu graben und die Ideen dahinter verstehen zu wollen.

Material zum Lesen

Viele Links sind oben schon im Essay enthalten – hier sind noch ein paar, in keiner bestimmten Reihenfolge: