Going fast without a fast-lane or an expedite lane

Does an expedite lane make you faster? And if so, why not put everything in the expedite lane?
Well, for an expedite lane to work several things have come together – Work In Progress Limits (WIP-Limits) and explicit policies, just to name the two most important ones.

When should we implement a "fast-lane" and what does "fast-lane" or "expedite-lane" really mean?

People have started to use expedite lanes in Kanban-Systems quite a while ago to handle the fact that no rule is ever without exception. If a Kanban system’s WIP-Limits do not allow for any more work to be started, there occasionally can be exceptions to the rule – production issues, "boss-tickets" and the like. To avoid having individually negotiated policies per ticket (which would rather invalidate the whole "make process policies explicit" idea) one way is to have an open discussion about handling exceptions and the rules governing those exceptions. For example: an exception like "We allow one ticket at a time to exceed the WIP-Limit of the system, but it still counts as WIP for other tickets" would be expressed by having a separate lane for exactly this ticket. Obviously this only makes sense, once we have WIP-Limits (that’s what the word kanban in the term “Kanban System” refers to) in place.
("In place" means that the limits are not only written down, but actually honored.)

What should we do if there are no WIP limits (yet)?

So what to do if you don't have WIP-limits in place and still want to negotiate some kind of special treatment for some tickets? Let's assume we want to make tickets visible that are of a higher priority than others or that are in a volatile state because of environmental issues? (As it was in the case in question: Developers already started while the ticket is still in the discovery Kanban)

Clearly in this case an "expedite" lane would not really give the same leverage it would do on a Kanban board with WIP-limits. Still I would consider those tickets to be of a different class of service which could – depending on the maturity level of the system – call for a separate swim lane or just for a different color coding of those tickets.

The other idea that might be spurred is to use a special work item type to achieve the same result. From a practical point of view this would taint statistics and metrics since there is no different way of handling those tickets. Therefore it might actually harm the system and make its future evolution more difficult.

Most importantly I would explicitly mark those tickets blocked – with a dedicated blocker type – that have to wait while these high-priority tickets are handled. And I would run statistics on those blockers afterwards. And publish those statistics!

Without giving the false pretense of having a high maturity Kanban system with an expedite lane this approach allows for explicit negotiation of the policies for this class of service that can be changed and re-negotiated over time.

And you can always move forward to a real Kanban system (one that has WIP-Limits) later.

So, how are you going to speed up