@David a common anti-pattern I see on agile teams is where, because of the pressures of the timeboxed iteration, they defer work that has no obvious immediate value, like refactoring and other technical debt resolution. This work, which as we all know in the medium-long term will help the team increase or at least sustain their pace, is abandonded because of the urgency of meeting the immediate deadline of the end of the sprint. Eventually the team’s pace splutters and chockes as the friction of all that technical debt slows them down.

To me, this is one of the key characteristic differences about using a kanban system: there is nowhere to hide this stuff. Either it is important, in which case you do it now, or you agree it isn’t actually necessary and don’t do it at all. There is no ‘someday / maybe’ list for the team.

As David Anderson says “Kanban still allows for iterations but de-couples prioritisation, delivery and cycle time to vary naturally according to the domain and its intrinsic costs.”