An Introduction To The Agile Service Delivery Methodology
I’ve done some blogging and even put together a webinar on the concept of Agile Service Deliver over the years but never really nailed it down.. I’ve been teaching Agile Service Delivery to my clients who are looking for a best-of breed methodology for their service delivery process. Well it’s time that I started getting it documented, and for several good reasons. First, I need to be able to standardize and systematize the entire approach and process. Second, it’s going to be at the core of the MSP Pro Academy training.
I have actually been developing my methods for service delivery process for more than a decade. It made some of it’s greatest leaps forward when I started working with a real Professional Services Automation (PSA) tool while at KPEnterprises, my brother Karl’s MSP in Sacramento, CA. But I didn’t call it Agile Service Delivery back then becasue I did not yet realize that I was developing something more than jsut a beast practice for my organization. It wasn’t until I became the COO for another MSP in Florida that was struggling that I realized what I had actually developed in my mind as to the service delivery process. To date, I have proved it’s methodology there at that organization and I’ve proven it at organizations around the US and in the UK.
Agile service delivery is the antidote to the current stack and run methods perpetuated by the Service Ticket systems and PSA’s. There are basically two methods out there for running a service desk and both are actually stack and run methods.
One I refer to as stacking dominoes and it means you lay out the technicians day by scheduling them for calls, appointments, or tickets, end to end. The mindset is that they will go mindlessly as told, from one thing to the next and be very productive. We all know how this goes. The minute one thing goes wrong from a simple traffic jam or a client with a priority one issue, the dominoes fall. And when they do, the service coordinator start shuffling and shifting time, and people to remedy the situation. And it cascades!
The other method I call ticket lumping and it happens when we pile tickets onto people with the belief that if every issue belongs to someone then those very responsible people will undoubtedly follow up or through on what they are assigned. The reality is that when Joe realizes he has 75 tickets to his name and he’s about three weeks backlogged he naturally tries to push the problem up ill to the service coordinator or the service manager, expecting them to even the load. If they do respond, it’s to simply lump the tickets onto someone else to lighten Joe’s load. if they don’t respond, Joe will reach out to Carol for help. But Carol will likely say, I have 10 tickets of my own that I cannot even see past, I’m not taking on yours. One way or another the tickets get passed around like the town bicycle while the oldest of then, like in the movie Cocoon, just grow older and never die.
The answer is to adopt the approach that frees up your techs by having them work from a set process that abhors rigid scheduling. Simple best practices such as; we schedule work three days out, and we ask for a window of time to work on the issue (versus set times), we do everything remotely that can be done remotely, etc. Scheduling a tech onsite at a clients office for a half day if there is a lot of work to get through and allowing them to work a set process dictating that we do the one specific thing we were sent here to do first (Priority one issue), then we do what can only be done onsite, etc.
There must be clear assignments for roles and responsibilities including who covers each role and function. Who’s primary on the Help Desk, Field Service, and NOC boards? Stratus’ of Tier 3, 2, 1, and helpdesk/triage. There must be a clearly defined process for Service Coordiantion, Flow of a ticket through the system, flow of a technicians day, and so on.
When the techs are clearly aligned to a board or queue, have strict workflow, and the right guidance, they will burn through tickets much more efficiently. Imagine three hoppers full of properly prioritized issues, Helpdesk, Field Service, and NOC. now imagine a line in front of each hopper of techs. Each grabs the next issue and goes to it, working until fruition or a stop. Then they go back and get the next one in line and so on. It’s a much more just-in-time feeding system. But wait, there’s more! If they are not all so rigidly scheduled or loaded with a backlog of issues, the service coordinator can function like Captain America on the ground calling out strays and guiding techs to the most critical items. at it’s best it is like an ant colony dismantling it’s new found food store to bring it back to the farm. Organized, systematic, and efficient.
Now for the best and most agile component. Any time the service coordinator see a clumping of issues or even a single issue that needs to be addressed, the create a quantum of service delivery (work force energy) called the service sprint. It is a short burst of work to get something accomplished and it may involve a single individual or a team. It may be a single issue or more likely it will be a group of issues. It looks like this; The service coordinator is always sorting the service board in various ways to see where things are getting backed up or heating up. When they see this they identify, for example, a single client that has four old tickets that are all nuisance issues. The service coordinator now actually schedules a tech to focus solely on this group of issues until they are resolved or escalated beyond their skill set. This grouping could also be something like a group of issues that indicate a problem (incident versus problem m break over)
In a nutshell what Aagile Service Delivery intends to do is flip the most conventional methods upside down. You avoid scheduling to allow for agility in operations versus scheduling as a rule and hoping for some time in between to get the little things done. You create these little quantum’s of work effort (service sprints) that keep stray and rogue issues under control.
There is actually much ore to the entire methodology but I do hope I’ve conveyed how Agile Service Delivery can work well enough to at least pique your interest. For if your interest is piqued, we can start talking more about it. And this is the place!