Gemeint ist damit eine Unternehmenskultur, die darauf ausgerichtet ist, durch ständige kleine Verbesserungen das Produkt nahezu perfekt zu machen und damit maximale Kundenzufriedenheit zu erzielen, die sich hoffentlich dann auch im Umsatz und Gewinn des Unternehmens bemerkbar macht.

Dazu zählen u.a. ein betriebliches Vorschlagswesen für die Mitarbeiter, ständige Weiterbildungen und ein sinnvolles Qualitätsmanagement.

Alle Aktivitäten innerhalb eines Workflows werden als Spalten in einem sog. Kanban-Board eingetragen. Die einzelnen Aufgaben wandern dann als Tickets von links nach rechts durch das Board, bis sie abgearbeitet sind.

Hierbei wird für jede Aktivität (z.B. Anforderungsaufnahme, Entwicklung, Test, Inbetriebnahme) eine Obergrenze festgelegt für die Anzahl, die sich gleichzeitig in diesem Stadium befinden darf, das sog. WiP-Limit (WiP = Work in Progress).

Hierdurch wird das Pull-Prinzip implementiert, das besagt, dass sich z.B. Entwickler dann eine neue Aufgabe nehmen, wenn sie dazu bereit sind und nicht, wenn die Anforderungen dafür fertig sind. Schwachstellen im Prozess können so entdeckt und behoben werden.

Im Unterschied zu Scrum gibt es keine festen Iterationen, es kann ausgeliefert werden, wann immer es sinnvoll ist. Oft findet man beide Varianten parallel im Projekt: Scrum für die reine Entwicklung (wg. der besseren mittel- und langfristigen Planbarkeit) und Kanban für die Fehlerbehebung und Wartung (wg. der besseren Statuskontrolle und schnellen Liefermöglichkeit).

Im Sprint Review muss der Kunde regelmäßig die bis dahin geleistete Arbeit begutachten und kommentieren, aber auch zwischendurch muss er damit rechnen, dass das Team Fragen geklärt haben möchte. Dies führt auf der einen Seite zu einer besseren Akzeptanz des Produkts, auf der anderen Seite auch zu höherer Qualität.

Der Product Owner ist der Kundenvertreter während der Entwicklung, falls dieser nicht ständig anwesend sein kann. Er hält engen Kontakt zum Kunden und trifft für ihn die täglich anfallenden Entscheidungen.