kanban

Kanban, besser gesagt Software Kanban, ist ein Vorgehensmodell zur Softwareentwicklung, das von David Anderson zum ersten mal als Software Kanban beschrieben und entwickelt wurde. Der Fokus bei Kanban (wenn wir von Kanban reden meinen wir hier Software Kanban) liegt darauf die Anzahl paralleler Arbeiten, der Work in Progress (WiP) zu reduzieren und somit schnellere Durchlaufzeiten zu erreichen. Probleme – insbesondere Engpässe – schnell sichtbar zu machen und beseitigen, so dass ein gleichmäßiger Fluss der Arbeit entsteht. Die Überlastung von Mitarbeitern und Teams abbauen was ein gleichmäßig und angenehmes Arbeitstempo bewirkt.

Kanban-Praktiken und Prinzipien¹
Als Kanban-Praktiken bzw. Prinzipien werden sechs Praktiken beschrieben, die Unternehmen in ihre Arbeitsweise integrieren, wenn sie Kanban machen:

Visualisiere den Fluss der Arbeit:
Die Wertschöpfungskette mit ihren verschiedenen Arbeitsschritten (zum Beispiel Anforderungsdefinition, Programmierung, Dokumentation, Test, Inbetriebnahme) wird gut sichtbar für alle Team Beteiligten visualisiert. Dafür wird ein Kanban-Board (in der Regel ein großes Whiteboard) verwendet, auf dem die unterschiedlichen Arbeitsschritte als Spalten dargestellt werden. Die einzelnen konkreten Arbeitsaufgaben werden auf Karteikarten oder Haftnotizen festgehalten und durchwandern mit der Zeit als so genannte Tickets das Kanban-Board von links nach rechts. Wichtig ist, den Workflow, wie er aktuell tatsächlich besteht zu modellieren um diesen dann gegebenenfalls anzupassen und zu verbessern.
Begrenze die Menge angefangener Arbeit:
Die Anzahl der Tickets (Work in Progress – WiP), die gleichzeitig in einer Spalte stehen dürfen, wird limitiert. Wenn beispielsweise in der Programmierung gerade zwei Tickets bearbeitet, und das Limit für diese Station zwei beträgt, darf sie kein drittes Ticket angenommen werden, auch wenn die Anforderungsdefinition ein weiteres bereitstellen könnte. Hierdurch entsteht ein Pull-System, bei dem sich jede Station ihre Arbeit bei der Vorgängerstation abholt, anstatt fertige Arbeit einfach an die nächste Station zu übergeben. Ein Effekt ist, sichtbar zu machen, wo sich Arbeit immer wieder aufstaut sprich es werden Engpässe identifiziert. 
Miss und steuere den Fluss:
Die Mitglieder eines Kanban-Prozesses messen typische Größen wie Längen von Warteschlangen, Zykluszeit und Durchsatz, um festzustellen, wie gut die Arbeit organisiert ist, wo man noch etwas verbessern kann und welche Versprechen man an die Partner geben kann, für die man arbeitet. Dadurch wird die Planung erleichtert und die Verlässlichkeit gesteigert.
Mache die Regeln für den Prozess explizit:
Um sicherzustellen, dass alle Team-Mitglieder den Prozesses kennen, unter welchen Annahmen und Gesetzmäßigkeiten man arbeitet, werden möglichst alle Regeln, die es gibt, explizit gemacht. Dazu gehören z.B. eine Definition des Begriffes ‚fertig‘, ähnlich der Definition of Done in Scrum, Bedeutung der einzelnen Spalten, Antworten auf die Fragen: wer zieht, wann zieht man, wie wählt man das nächste zu ziehende Ticket aus der Menge der vorhandenen Tickets aus, usw.
Fördere Leadership auf allen Ebenen in der Organisation:
Verbesserung kann nur funktionieren, wenn sich alle Ebenen in der Organisation daran beteiligen. Besonders wichtig ist es, dass Mitarbeiter, die direkt die Arbeit verrichten, „Acts of Leadership“ zeigen und konkrete Verbesserungsvorschläge einbringen.
Verwende Modelle, um Chancen für kollaborative Verbesserungen zu erkennen
Modelle sind Vereinfachungen über den Prozess. Ein beliebtes Modell ist z.B. das von Wert, Fluss und Verschwendung aus der „Lean IT“. Andere Modelle basieren auf den Ideen von Deming oder auf der Engpasstheorie, auf systemischem Denken oder auf der Komplexitätstheorie. Modelle können dabei helfen, ein besseres Prozessverständnis zu erreichen und Experimente zu finden, die zu einer Verbesserung des Prozesses führen.

 

¹ an der Beschreibung von Software Kanban in Wikipedia angelehnt.

9 Gedanken zu „kanban

    1. You always have to remmeber with Cope that he likes making big broad statements that grab the imagination. Who could forget Abstraction is Evil or UML set the industry back 10 years. Usually there is some truth behind the headline.For me one of the strengths of Scrum has been that it is relatively well defined. While agile has come to mean just about anything you want it to it is quite clear what Scrum is, and is not.While Scrum and Kanban may have similar roots and underpinning theory they are different. To say Kanban is a renaming of Scrum shows a mis-understanding of Scrum, Kanban or both.Try this: apply Bas Vodde’s Nokia test to a Kanban team- No iterations in pure Kanban, that fails part one- No concept of a product owner or backlog in Kanban, they may exist but they are not mandated (as they are in Scrum)- No estimation in pure Kanban- No burndown charts, cumulative flow yes, burndown noFinally disruption: heck yes, Kanban teams I’ve seen are disrupted all the time. Scrum seeks to create undistributed times, that concept seems lacking in Kanban.Of course between Pure Scrum and Pure Kanban there are a lot of variations and this is probably the space Cope is thinking of.

    2. I don’t think the movement to Kanban folwlos from a misunderstanding of Scrum, but I do think it possible that because Scrum’s inflexible framework brutally reveals organizational dysfunction that people reel from it and seek ways to circumnavigate the problems. Throwing out fixed time-boxing, or replacing it with flexible timeboxing aka cadence, may be one of those ways to recover from the reeling.The mess of software organizations is massive and terrible. Sometimes it is too much to handle. It is natural human reaction to want to put the worst problems aside in order to deal with the immediate (and often easier ones). Whether this is a good approach is yet to be figured out. My guess is that it isn’t. Bury something deep enough and it is hard to find it again when you do feel ready to dig it up. Earth shifts. And deeply buried things tend to rot.

    1. I don’t like guesses It might mean . Everything that inceldus people (like software dev. process) can be misunderstood, compromised, misinterpreted and rejected.Sometimes there is no good reason to defend Scrum (or to defend Kanban). Sometimes it is just a fear. Someone who knows Scrum may fear Kanban. It is all about human nature. Many people don’t like to be pushed out of comfort zone and learn new things. It is no surprise to me that CST will defend Scrum. He may feel that Kanban pushes him out of business and pushes him to learn something new to be in charge.It happens with everything. Scrum is not a silver bullet. Everything in software dev. is SO context dependent. Kanban has its place. And I don’t care about terms at all.Kanban did bring something new, new angle at least + some cool tools. There is no need to fight against it. Learn it. Try it. Understand it. Adopt it. Mix it in when required based on context. Win the game.

  1. here, I think you would be better off deiiscbrng your actual practice what you do, when and where it works, and why it works. I don’t think the branding helps. This will add to the broad pool of Generic Agile knowledge. The best practitioners don’t follow a brand, they pick and choose ingredients from where ever and apply them as applicable. I don’t see that changing.As for Lean. It seems to be all things to all men On a more concrete level, we can study Lean product development and Lean Manufacturing. We have known about these things for a long time now, and have borrowed from them much in the past, but it should be needless to say that neither of these things are Agile. Agile goes beyond questions of efficiency and addresses the effectiveness of teams in an unordered, complex and changing world.Of course re-stating Agile using new Lean language may better help some understand it. But we should be sure to re-state rather then replace , otherwise we will merely be turning the clock back and going over old ground.I’d rather move things forward I sense you do too.Paul.

  2. Hello, the contents existing at this site are in fact remarkable for people knowledge, well, keep up the nice work fellows.
    Keep in contact.
    I was searching in Stuttgart and found this.

  3. I don’t consider Kanban being a renlaebilg of Scrum.I do have a minor issue, though, with renlaebilg Kanban as a software development methodology I sometimes wonder if David Anderson regrets calling his Corbis stuff a Kanban system for software engineering because we (the community) shortened it to just Kanban and that name stuck. Anyway, I digress.On a more serious tone, I also have an issue with teams adopting Kanban for the wrong reasons, i.e. because another methodology revealed a dysfunction, it started to hurt, and Kanban offered a quick fix. Statements like, in this Kanban thing we don’t have to estimate , or, if we do Kanban then nobody needs to become a generalist and all that feature team crap goes away. Hearing people say things like this (and being somewhat serious while saying that) makes me a sad panda. There’s great value and a powerful improvement mechanism behind the (unfortunately named) method we call Kanban.Finally, I’m always happy to see discussions about Scrum and Kanban, their different approaches and fundamentals, without unnecessary and unproductive FUD and expletives.Thanks, Karl, for blogging this.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.