A question in a recent kanban workshop was how to deal with the fact that some work has different workflow than others
For example:
Features need to go to testing after implementation
Escalation cases without patches need to go to support for returning to the customer after implementation and that’s it
Escalation cases with a code level fix need to go to support and the customer. They also need to go to testing as the code fix will go into the next version
There are a couple of options to handle this situation with Kanban
If the escalation case doesn’t require a code fix its quite clear that you can skip testing and go direct to “Wait to Deploy”. Yes, this means you can skip lanes in the Kanban board.
If a code fix is required, but your policy says that for escalation hot fixes you can manage with developer-based testing, you can skip the same way.
See below for how this might look on a board
In essence, as soon as developers are done with the escalation case, they push it forward. Then, support or deployment teams can pull it from the “Wait to Deploy” queue into Production.
Now comes the question what happens if you did have to fix code, and now want to roll it up onto the next service pack / release. Now it needs to go thru the regular workflow, and be affected by the WIP limits in it. It might look like this:
Case 9017 is there both waiting to be deployed, as well as waiting for testing. The blue card is some sort of “Technical Debt” you are incurring btw (Or Unhedged Call Options as some Agile thought leaders are starting to see this)
In some cases you will want to avoid incurring the debt/risk and you will want to wait for testing before you deploy. I personally feel more comfortable about this option. I would even consider this a smell of bigger underlying issues if you’re willing to skip testing before you deploy to production. Yes, the customer wants a solution fast. But your testing people should be able to move fast as well. If you need testing for your regular work, you probably need testing even more for such sensitive stuff. You can rely on heavy automated testing at the unit and integration level to make sure you are not causing any regression. But exploratory testing by a skilled tester is priceless and fast, and can save you a lot of time, face, and possibly money. I would ask WHY you cannot/wouldn’t do this. I’m guessing it will open up quite an interesting conversation.
What you WILL have to address in this case is how to expedite the escalation case thru the system as fast as possible. Having a class of service that is invulnerable to WIP limits, where the card is handed off interactively person to person without waiting in queues, and where someone in the team or in a supporting function acts as the expediter that follows the card all the way through, can help you achieve your SLAs when the s&*t hits the fan. Just make sure you notice if this becomes the standard way of doing business…
So basically, you can skip lanes if thats the way your process currently works (Remember, Kanban starts with conveying your current process). But pay attention to whether this workflow provides the optimal economic outcome for your system, and be open to adjusting it. Alternatively use classes of service and other policies to help you get the result you want.
Bottom line, its YOUR system. Nobody can tell you how to make it work the best way…