Bei­de sind agi­le Metho­den, aber mit unter­schied­li­chem Fokus. Scrum ist ein Frame­work für die Ent­wick­lung kom­ple­xer Pro­duk­te und arbei­tet in fes­ten, zeit­lich begrenz­ten Zyklen (Sprints). Es schreibt fes­te Rol­len und Events vor. Kan­ban ist eine Metho­de zur Opti­mie­rung des Arbeits­flus­ses. Es ist nicht an fes­te Zyklen gebun­den und schreibt kei­ne Rol­len vor. Kan­ban ist evo­lu­tio­när, d.h. man star­tet mit dem bestehen­den Pro­zess und ver­bes­sert ihn schritt­wei­se. Ver­ein­facht gesagt: Scrum ist oft gut für “neu­es bau­en”, Kan­ban ist exzel­lent für “bestehen­des mana­gen und ver­bes­sern”.

Nein, abso­lut nicht. Kan­ban ist uni­ver­sell ein­setz­bar, da es sich auf die Visua­li­sie­rung und Opti­mie­rung von Arbeits­pro­zes­sen kon­zen­triert. Wir haben Kan­ban erfolg­reich in den ver­schie­dens­ten Teams in Ber­lin imple­men­tiert: im Mar­ke­ting (zur Steue­rung von Kam­pa­gnen), in HR-Abtei­lun­gen (für den Recrui­ting-Pro­zess), im Ver­trieb (zur Ver­fol­gung von Leads) und natür­lich im IT-Sup­port und in der Soft­ware-War­tung. Über­all dort, wo Arbeit als ein Fluss von Auf­ga­ben ver­stan­den wer­den kann, ist Kan­ban eine Berei­che­rung.

WIP steht für Work in Pro­gress, also die Anzahl der Auf­ga­ben, an denen gleich­zei­tig gear­bei­tet wird. Ein WIP-Limit ist eine Ober­gren­ze für die­se Anzahl pro Pro­zess­schritt (Spal­te auf dem Board). Die­se Begren­zung ist das Herz­stück von Kan­ban. Sie ver­hin­dert, dass sich das Team mit zu vie­len Auf­ga­ben gleich­zei­tig ver­zet­telt (schäd­li­ches Mul­ti­tas­king). Das hat zwei magi­sche Effek­te: Ers­tens wer­den die ein­zel­nen Auf­ga­ben viel schnel­ler fer­tig, weil der Fokus höher ist. Zwei­tens wer­den Eng­päs­se im Pro­zess sofort sicht­bar: Wenn eine Spal­te ihr WIP-Limit erreicht hat, darf kei­ne neue Arbeit hin­ein­ge­zo­gen wer­den, bevor nicht eine Auf­ga­be die Spal­te ver­lässt. Das Team ist gezwun­gen, sich um die Besei­ti­gung des Eng­pas­ses zu küm­mern.