Also a Kanban team uses regular improvement events (Kaizen events) and a takt.
Malte Foegen

Kaizen Event? Never heard that term before. Kaizen means Continuous Improvement (flow), not batched improvement (timebox).

Sure, a team perhaps needs to step aside and do a retrospective (or however you name that discussion) to see and decide on improvements. But where’s the additional value in doing that timeboxed?

I’ve also never heard of something like a takt in Kanban —it’s quite the opposite; the 3rd Kanban Practice explicitly says: manage flow (speed and smoothness of movement as David Anderson wrote back in 2010).

Neither Kanban Principles nor Practices enforce any kind of timebox. Of course, a team may benefit from regular, scheduled improvement meetings — better scheduled, than never — but any kind of improvement adds value or eliminates waste as soon as it’s implemented. So, why wait until the end of a timebox?

As you wrote in your blog, every activity has a start and an end. But in a complex domain (see: Cynefin) the duration from start until end cannot be predicted since you are confronted with unknown unknowns. In that case, how can you define the size of a takt (upfront)?

I’m no Scrum Expert, but digging the Scrum Guide for empirical process control — another term you mentioned —I found: transparency, inspection, and adaptation. A timebox may help with all three — but I cannot find any prescription in there to use timeboxes and those three pillars can be achieved without them.

So, sorry, but…I’m still not convinced. :-)

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.