My understanding is that blocked items should be treated as any other items currently inside your workflow. Your workflow has an entry point and a exit point and you need to keep things flowing between these points and it's best if the rate of output is on average the same as the rate of input. In other words, you should not start new work unless you finish old work first.
So, on that idea, when something gets blocked you have to focus your efforts on getting it unblocked because it otherwise gets stuck into your system and no longer flows. You can't - without an analysis - just dump it in some "Blocked" area and take on new work because now your inputs will be larger than your outputs. More work enters your process than it leaves. Things need to exit at the same rate than how they entered, on average, and not accumulate within your process.
That's ideally though. In real life you might not have control over things. If something gets blocked and you can't do anything about it because it's some external entity that needs to handle it, then you need to do something with the blocked item because you can't just have it sitting there.
With proper WIP limits you might afford to keep one or two blocked items in your workflow but that will reduce throughput as new work can't be started when new capacity is available because of the WIP limits. So what's the knee-jerk reaction now? You increase WIP limits because you actually have capacity and want to reflect that, and you want to take on new work while something is blocked. It makes sense. But what if you do not have anything blocked in your system at some point? Your WIP limit now is above your capacity because you work on everything instead of just on some items while waiting for others to be unblocked by somebody else. So increasing WIP limits might solve the context of blocked things inside the system but it increases work in progress in normal working situations, thus reducing throughput (as Little's law shows).
So I would now mess with the WIP limits. I would keep the blocked tickets in the board to visualize things (which is the other main principle of Kanban, besides limiting WIP) and reason about them and experiment with things:
- Maybe there is one or two things blocked at some point and I can live with that.
- Or maybe I see that things start to pile up and don't exit the system as fast as I want them to, at which point maybe I might consider changing my pull policies. Seems from your example that the blockage is caused by external dependencies only. In that case maybe I add a new step in my workflow to analyze things for dependencies and I decide not to pull them if the dependencies are not resolved first. Obviously this is again the ideal case. In real situations maybe I still need to prioritize this potentially blocker over other work.
- Then perhaps I could split the work in two parts, one is the dependency and one is work I can do without depending on others. Move my half through the system now and deal with the other half when the dependency is resolved.
So it's a matter of trade-offs basically, but trade-offs that I think should be decided based on information gathered from monitoring your flow efficiency and not by trying to apriori think of something to deal with blockages.
As for your last point, you can move things back in Kanban, that's not forbidden. If it's a good idea though is another matter. Going back to the examples I mentioned previously, maybe it's OK to move things back for blocked stuff, but on the other hand maybe it would be better not to pull that kind of work into your work in progress in the first place. So that's an inspection point in itself, which might trigger another trade-off decision.
