People & Process Thoughts

Why Agile ticketing is a productivity hack

It's a shame that so many people think of Agile as Scrum when in fact Scrum is just a tiny implementation of the Agile methodology. The beauty of pure Agile is that you can apply it to anything - software development, marketing, manufacturing, even the handling of inbound support and service desk tickets.

Agile recognises a gap between what people want and their ability to articulate that want. As a result there are often differences between what they desired and the delivered product or service. This difference is usually perceived negatively and there is a cost to bridging the gap between expectation and actuality.

People often don't get this even after it has been explained and blather on about better requirements gathering and other waterfall nonsense. To illustrate the problem I use an example. I ask them to look out of a window, find a car they like and then I offer to build the car for them but they have to tell me what to build. Standing at a flipchart I write down all of the features the car must have – wheels, engine, roof, everything! I have done this numerous times and every single time they forget to tell me to add brakes! The car sets off, goes down a hill and crashes, so now we're into the realm of argument over whose fault it is that such a basic and obvious feature was missed. The answer in Agile, is ‘nobody and everybody', the gap is inevitable, until the car crashed nobody thought to add the brakes even though everybody knew they were essential. What this means in a nutshell is that how Agile is implemented is much less important than recognising what it is meant to solve, which is why so many ‘Agile' teams are about as Agile as a brick.

Here's the agility gap in so many ticketing solutions – the ticketing system is a black hole into which a plaintive appeal is sent and out comes a number (if you're lucky). What's the likelihood of a gap between the problem and the solution in this case? Pretty damn high! When the car crashed the outcome was the obvious cost of the mechanical repair. In real life the cost is far more insidious and sometimes much more damaging. Time is ‘stolen' from all sides, reputations are damaged long into the future as the phrase ‘terrible customer service' gets stuck to your brand like some foul-smelling tar that won't wash off.

Most ticketing solutions try to address this problem by using the ticket as a communication medium and providing a mechanism for dialog, such as email. Ticket goes in; CSR doesn't quite get the problem or wishes to propose a solution so sends back an email. Customer reads email, sends response back etc. This is simple; just about every half decent system will do this and track all communication against the ticket. Incidentally, if your system that doesn't do this, throw it in the bin and go get a life! However, tracking a communication trail like this assumes there are only two stakeholders in the chain. How naive.

I have a problem logging in so I contact my help desk and get jockeyed around 3 or 4 times with FAQ-type solutions. None work and finally my ire is more than the CSR can bear. I get routed through to Tech Support. They see the ticket and wander off to investigate. They find it's a bug and log it into Asana/ Jira/ Gemini/ Pivotal/ Blah… What do I care? Agility just ended here, paradoxically just at the point where the issue finds its way into a supposedly Agile tracking system.

I'm not connected to the entry in the developer's system, in fact ‘customers' are very specifically not welcome in it because devs hate users, the very term ‘user' normally denoting someone to be treated in a derogatory manner as a luddite. Where's the dev's ability to continue the communication with all stakeholders now? How do they manage communication with me, the CSR perhaps, sometimes Management if I've escalated the problem or the issue is tracked by a Service Level Agreement. We're all in the dark while our dev tinkers with the car, ignoring the brake issue.

Agile ticketing exists only if the ticket can be transformed into the task or tasks needed to resolve it, thereby maintaining all the information and keeping the stakeholders connected. To do this the system must be open while still offering the internal team complete control over rights of access and visibility, because they rarely want to wash their linen in public but the public have a right to see that they are doing the washing and where they are with it.

Gemini is a uniquely Agile tool because it lets you do this. Type transformation, the control over Visibility (of fields), the self-identified work distribution of Workspaces and non-programmed Rules and Actions that trigger any kind of notification, mean there is only one version of the truth and nobody who sends a request in ever needs to feel that the number that came back is all they have to show for it.

The effect of this Agility is a quite remarkable increase in efficiency. Workspaces automatically handle RACI assignment as soon as the ticket comes in. Whatever action needs to be taken, simple changes in data values (status, priority, type etc) automatically trigger the movement or transformation of the ticket. A ticket can become a Bug, a Change Request, whatever…, set to capture appropriate data and metadata, possibly even in a different project owned by a different user group or department. All the time, nothing of the original entry is lost, anyone can communicate with any stakeholder (and the system can be set up to do all of this automatically) and all privacy concerns are managed. By accepting the principle of the gap in the first place it is removed and a single workflow in a single system covers it all.

It comes back to the simple truth about Agile – recognise the problem it is meant to solve and solve it, as Gemini does, or you've simply got a clunky old ticketing system and disconnected Issue Tracking that is Agile in name only.