Cracking the WIP
Limiting work-in-progress can be a bit annoying to start with, but you have to think of the consequences — being confronted with issues when they're small saves you from a much larger pain in the future. Like brushing your teeth, once you get in the habit, it's no big deal.
WIP is like inventory in a warehouse: the more you carry, the further you are from the market and the harder it is to respond to change. Business value is often dramatically affected by time - if your Christmas campaign isn't released until January, you've missed the opportunity. The lead-time on new features can make the difference between dominating the market or constantly playing catch-up.
Without specific policies to limit WIP, people will naturally tend to multi-task. Non-bottlenecks will start new tasks whenever they're waiting for a bottleneck to complete. The effect is a continually growing pile of partially-completed work. Since the bottleneck limits the throughput of the system, the extra WIP doesn't actually result in more throughput; it just pushes up lead-times.
I'm not saying that all multi-tasking should be eliminated. You have to be able to put something on the back-burner every now and then to let the subconscious mind think about it, or ask someone a quick question and expect a quick reply. But uncontrolled multi-tasking can do a lot of damage.
Kanban lets you strike the right balance: limiting the amount of WIP to a point that is comfortable but not out of hand. How tightly you can squeeze the limits depends on the maturity of the team.
To begin with, it can be frustrating to have to wait on the bottleneck before you can continue to the next piece of work, or to have to justify why some piece of work must be expedited. But this frustration is the thing that drives improvement. Issues like these need to be addressed, and Kanban prods you to address them sooner, rather than later when it will really hurt.