Kanban does assume a more-or-less linear flow. Most of the time this models software development quiet well: we crate a user story, we code it, we test it, and we deploy it. However, some internal stages are iterative in nature and thus not so obvious. Take this (simplistic) board:
|| Planning || Development || Test || Deploy || Done || || doing | done || doing | done || doing | done || doing | done || || || | || | || | || | || ||
Let's focus on the Planning column. If this is where user stories are developed, clearly some sort of iteration is needed: write story, refine/conversation, improve story, customer feedback, etc ... These stages are not modelled on the board at all.
Let's focus on the Test column. Once a story (or task/whatnot) is being tested: some tests will pass, some will fail. Thus the story needs more work. Should it go back into the develop column? Stay in a special test/development? Should there be Test/Fail and Tests/Pass columns? Over complicating the board is not an optimal solution.
Should you model iterative processes using Kanban?
If so, how? If not, why not?