Categorising Workarounds

You've just done a new release. The Sales team find when they take a new customer's details and hit 'save' they don't end up on the place new order page, so they can't make a sale! Which means they can't get commission. Which means they are going to stomp down your door, like now!

Heads are going to roll if the issue isn't resolved but after six hours there's a workaround discovered. Everyone breaths a sigh of relief, if there's a workaround it doesn't have to be fixed anytime soon, right? Maybe, maybe not! Depends on the kind of workaround.

Its worthwhile to categorise the workarounds that need to be played in your business. This helps when it comes to prioritising issues. Here's a few classifications I've used when categorising workarounds.

Normal Manual
The workaround involves little effort. Examples of this could be a datafix or a message replay that requires little investigation. These are ideal candidates for automation. The number of orders, customers affected and length of time taken should be recorded.

Crazy Manual
The workaround is time-consuming and painful. From the the support team's perspective issues with a crazy manual workaround need to be fixed as soon as dev resource can be allocated. If the team are using a task board they should be setting limits on the number of these in play. Details should be recorded as per a normal manual workaround.

Automated
Both the identification of affected orders and the corrective action are scripted and require no manual intervention from the support team.  The more of these in play the flakier the system.

External Action
The onus to take corrective action lies outside the team.

No known workaround
If these are customer-affecting they need to be fixed as soon as possible. 

No workaround needed
There's an issue but we don't need to take corrective action.

If the support team use a task-board as their bug-board (aka The Wall of Lame) the different types of workaround in play should be represented with a different colour of sticker and put on the bug card. This will make it easier to impose limits on the number of workarounds the support team are dealing with. If the task board is full of crazy manual stickers the team is about to implode under the strain. If the board is full of automated stickers the devs know the system isn't as robust as it should be.