Agile Service Delivery Defined

Agile Service Delivery releases your service department from the constraints of conventional service delivery and allows your entire team to function with a level of autonomy far superior to those still preached by your PSA solution providers. I have been using the term Agile Service Delivery for years, and I have been coaching other companies in these methods with great success. I realized I should start documenting and defining the methods and principles so that they may be further revised and clarified. I’d like to share with you everything I’ve surmised to this point. My hope is that you can gain from it in some way, and if you’re so interested, may contribute in even some small way. The future is ours to write, and if we’re the authors, let’s get to it.

If you are not familiar with the term Agile, as in Agile Software Development or Agile Project Management, don’t be too concerned. All you need to know is that the intent is to be agile and dynamic where and when possible, versus strict, rigid, and overly process controlled. However, do not think that being agile gets you out of defining and documenting processes and having clearly defined procedures, systems, and methods.

For those who do know or understand Agile, do not be too quick to assume that there has to be a one-to-one relationship of the Agile Manifesto and Principles used in Agile Software Development or Agile Project Management and this new Agile Service Delivery. Everyone who contributes to the definition of Agile Service Delivery gets to define the principles and tenets. So if you have input on something you read here, please be heard by posting a response.

I will lay out the principles I have come up with and organized so far. They are broken into 5 areas: Service Delivery Strategy, Process and Procedure, Communications Protocol, Team Dynamics, and Client Value.

Agile Service Delivery Principles - Incomplete:

Service Delivery Strategy

• Everyone is pre-authorized to apply excellent customer service at any opportunity!
• Transparency - Everything is in our system, all work is performed against a ticket, and everyone has access to every ticket
• Quality at the source -Every ticket is a quality ticket all the time
• Divide and conquer - One issue, one ticket
• We work in real-time – All of the blind processes rely on it
• It’s always okay to just take care of the client on any level
• Rapid, flexible response, focusing on items the client needs most
  
  • SLA and ITIL Catalogue of Services directs this
  • Front end – Users – Tactile – Needs
  • Back end – System – Services – Requirements

Processes and Procedures

• Ownership of process – Everyone helps write the standards and procedures
• Continuous incremental improvement
  
  • Frequent evaluation and feedback
  • Timely adaptation of changes
• Agility in execution and administration of Blind processes for workflows
• Blind processes for Technician work cycles
• Non-rigid tiers defined for escalation

Communications Protocol

• All communication is closed loop
• The scope and depth of communication is proportional to the priority and severity
  
  • It automatically expands and contracts with priority and severity
  • We communicate even when there is nothing to communicate
• Communication leverages today’s technology
  
  • Video will become the norm even with clients
• Short, impromptu ad-hoc meetings with only the people required (Scrum meetings) are recognized as important and are encouraged
• There is a clearly defined process for how to create an interrupt cycle to get time with someone without completely disrupting work
• Short, defined concerted effort campaigns to get stuff done (Sprints) are typically by nature a week in length for our industry, but can be longer or shorter and can be focused on areas of trouble in the overall service system or for a given client.

Note: The terms Scrum and Sprint are not just for development and project. They lend themselves very well to our service delivery system and we will use them.

Team Dynamics

• Mature behavior required on the part of each team member
• Self-managing knowledge workers who are given the autonomy to apply their mastery
• Each team member is:
  
  • On board with the mindset and dedication to the principles
  • Must be a champion of the mindset and principles
  • Must be receptive to what comes their way and what is expected of them
  • Allowed to call anyone on anything as long as it is in a non-blaming way
  • Dynamic (Agile) in their ability to change directions or redirect momentum when required

Client Value

• The client must actively participate in the well-being of their own systems
  
  • Technical Roadmap Meetings
  • Feedback on service delivery levels
  • Timely response to requests from service providers (Techs, Eng’s, SC, SM)
• The client must be willing to communicate according to our protocol
  
  • Closed loop feedback
  • Reasonable expectation in responses and response times
• Primary, Secondary, and Tertiary client technical contact identified and assigned
  
  • Sometimes this is not possible, but we need champions on the inside

The preceding list is nowhere near complete and is sorely lacking in critical points related to true Lean methodology. In the Team Dynamics section, there is mention of mature behavior and self-management as requirements. These are related to the ability to understand risk, need, impact, function, and so many other aspects of any issue or problem. And then there is the recognition of Problem versus Issue which seems to escape even some of the sharpest technicians and engineers. We must address the cultivation of skills and the training of our talent using other tools and methods not directly related to the Agile Service Delivery system, but make no mistake, they must be addressed.

Ideally, in a well-tuned Agile Service Delivery system, you would not need a service coordinator in the more common conventional role. Instead, your service coordinator would be an expeditor, communications facilitator, and ticket tuner, not a Tetris and taskmaster. I have seen it work in several companies I have coached, including one with over 20 technicians and engineers.

In future blogs, I will expand on each of these principle groups and draw the required correlation to Agile principles already in place for project management and software development. I will also delve into the outline of the Core Values that will form the Agile Service Delivery Manifesto, the linchpin component of our system. To seed this, I will start with the following statement that comes to mind every time I begin or attempt to complete a written process:

We build clearly documented processes and procedures as rules and guidelines, but we will be agile in their application and execution when it is of value and benefit to the client and does not go against our principles. There should always be a known process, procedure, or best practice to consider as the default mode, but in the hands-on, day-to-day work, the standard guides the practice and the practice is agile.

As I mentioned previously, this is by no means complete and there is a lot more to build out, but I had to get started on it in order to begin bringing it to fruition. The seed has been planted, it will be fed and watered, and it will grow. Feel free to help out, I welcome all useful input and feedback.

Can you find this on Google?