Elsewhere, I have proposed a Manifesto for Service Management Agility, describing what agility in managing services would be. Kanban is well known as a method for agile management. So let me put these two concepts together. How does Kanban support service management agility? How can agile service managers make good use of Kanban?
A Manifesto for Service Management Agility
Agile practitioners usually think of agility in terms of the Manifesto for Agile Software Development. But surely each work discipline has particularities that distinguish it from software development. Let’s try to understand in more detail agility in the management of services.
Let’s start by comparing the agile software development manifesto to the proposed manifesto for service management agility:
|Agile Software Development||Service Management Agility|
|Individuals and interactions over processes and tools||Emotional intelligence over detailed processes|
|Working software over comprehensive documentation||Services fit for purpose and for use over meeting specifications|
|Customer collaboration over contract negotiation||Flexible engagement over fixed agreements|
|Responding to change over following a plan||Planning for change over following a plan|
|Distributed decision-making authority over immediate reduction in direct costs|
How does Kanban support each of these five propositions? I will examine the first three propositions in this article and complete the analysis in a future article.
Emotional intelligence over detailed processes
In “traditional” service management frameworks, heavy emphasis is placed on defining management processes and assigning unambiguous responsibilities for each process role. These frameworks are implicitly Tayloristic in nature. They assume that a given type of work can be optimized using a single process. They assume that the process actors can perfect the execution of their tasks, as defined by the process.
When it comes to managing services, the reality is quite different. With a few exceptions, most service work is highly variable. In most cases, it is not possible to perform work, in the same way, each time, due to variations in the timing and cadence of work, the availability of resources and the nature of the services themselves.
How are the various service management disciplines highly variable? Variability should be obvious with such disciplines as problem management. Every problem is itself somewhat different.
Customers make service requests, each of which tends to have its own characteristics. That being said, some service requests can be standardized and even automated, but these are the exceptions that prove the rule.
The situation is similar with changes. With the exception of standard changes, no two service changes are alike. And so on for virtually all the service management disciplines.
Let me contrast now the rigid, Tayloristic approach with an agile approach using Kanban. I once had a client that had defined 87 distinct processes to be used in the context of managing the end user’s workplace.
Unfortunately, even that high level of complexity and detail did not cover 100% of the management cases. Furthermore, it was completely unrealistic to imagine that the responsible personnel would learn and apply all 87 processes. Finally, the maintenance of those 87 documents was a valueless burden.
So here was a case where an organization tried to define every aspect of managing services, down to the most insignificant details. But those 87 processes were far too numerous and far too detailed.
It turns out that all the work could be performed by an intelligent application of four distinct work patterns.
This far simpler approach required the various specialists to collaborate in a flexible way. It also required the specialists to remain sensitive to the particular situation and needs of the customers.
In short, the more emotional intelligence the specialists could show, the quicker could they adapt to the needs of a specific case, the faster could they resolve the case successfully and the greater the satisfaction of the customer with the services delivered.
Kanban is well-suited to supporting this agile approach capitalizing on emotional intelligence. First, Kanban generally uses very simple value streams. In contrast, traditional service management tends to use detailed and inflexible processes. Such processes focus on the technical accomplishment of tasks rather than on the maximizing the value that customers can obtain from the work.
Furthermore, Kanban provides a framework for identifying the particular cases where work is blocked and where agile collaboration is of particular importance in unblocking the work and advancing cheerfully to resolution.
Good emotional intelligence increases the ability of team members to identify blocking issues that a colleague might hesitate to articulate.
Emotional intelligence is manifested in the readiness of team members to act to unblock work. In addition, it helps to maintain the energy levels and clarity of vision that encourages a team to deliver with celerity its output to the customers.
Services fit for purpose and for use over meeting specifications
Stating that a service is fit for purpose and fit for use has a particular connotation in the service management world. Being fit for purpose means that the service either:
- creates output that enhances the customer’s performance; or
- enables the relaxation of constraints on the customer.
Being fit for use means the service has attributes appropriate for the targeted service consumers, such as its level of availability, its capacity, its security and so forth. A customer can obtain value from a service because it is both fit for purpose and fit for use.
A service provider attempts to specify service offerings that match the needs of the customers they target. But, given the high degree of variability of those needs and of the contexts in which services are requested, it is highly unlikely that the service specifications can describe all possible cases.
So what should a service provider do? Should it refuse requests for service that do not match the exact specifications of the offering or should it attempt to provide services that help customers obtain the value they seek, even if that means adapting the way in which the service is being provided?
There is no single answer to that question. Each service provider will have their own strategies. However, the agile service provider will value understanding the customer’s goals in using the service over providing exactly the service defined, neither more nor less.
As a result, the agile service manager is more concerned with making a given service act fit for purpose and for use, rather than simply relying on execution according to the defined process.
Once again, Kanban meshes well with this agile approach. We already saw in the previous proposition that we do not expect to use a Kanban board with dozens (or even hundreds!) of distinct value streams.
We expect, instead, that the main phases of work will be defined on the board with a level of detail that might depend on the degree to which the work is obvious, complicated, complex or chaotic (as defined in the Cynefin framework).
Using a Kanban board helps to emphasize the need to do work that provides value for the service consumer. This is in striking contrast to the detailed workflow tools that characterize traditional service management or business process management.
By structuring work around a high-level value stream, kanban gives the service provider the flexibility to adapt work to make the service fit for the customer’s specific and highly variable purpose and use.
In short, the question for the rigid practitioner using traditional tools is “Am I performing the prescribed task according to the prescribed service levels?”. The question for the agile service manager using Kanban is “Am I helping the flow of work advance towards delivering the output that provides value to our customers?”
Flexible engagement over fixed agreements
In a service management context using traditional tools, work is pushed from task to task based on a set of agreements. So-called “best service management practice” puts heavy pressure on service providers to negotiate service level agreements with their customers. The internal relations among service provider teams are governed by a set of “operational level agreements.” Finally, legal contracts govern the performance of third-party suppliers and their obligations to the service provider.
It is almost impossible to ensure the overall coherence of such agreements when it comes to meeting customer expectations.
Even worse, “best practice” advises that work should be prioritized based on two factors: the impact on the customers of the events being managed and the urgency with which that work shall be done.
In most cases that I have ever seen, priority is determined by nice looking, symmetric matrices of impact and urgency, rather than via any real attempt to manage the risks of work and its value to customers. Here is a typical example of task priority, based on impact and urgency:
In many cases, organizations relate task priority to service levels, in particular, to a predefined lead time for a task. The result of such an approach based on fixed agreements is that work is pushed, ordered and measured based on its conformity with somewhat arbitrarily defined priorities, rather than based on how soon the customer can obtain value from the work.
“Flexible engagement” refers to the concept in Kanban where a team engages to execute work based on its capacity to perform, rather than based on pre-negotiated agreements. Thus, work is pulled by a team according to its WIP limits and according to the class of service of the work.
How does this differ from the “best practice” approach? First of all, the importance of the impact of work on customers is minimized, because work items are defined so as to be small and incremental. Few individual work items (except the resolution of certain incidents) are likely to be high-impact items.
Secondly, Kanban emphasizes the overall value of work to customers. Now, there is nothing in traditional service management that prevents this type of work assessment.
But in practice, organizations rely on vague proxy metrics for value, rather than focusing on the value itself. Thus, tasks that impact 100 workers are considered to have a higher impact than tasks that impact only a handful of workers. Maybe yes, maybe no.
Finally, traditional practices ignore the idea of class of service. For example, a work item might be in a fixed date class, where the deadline is relatively far in the future but the value of the work for the customer might be very high.
According to the Kanban rules of engagement, such work might be deliberately put off in favor of lower value work items that might be of the intangible or the standard class.
In short, Kanban foresees a set of principles used to prioritize work and decide when to engage in its performance. These principles should be applied in an agile way, rather than pushing work based on a set of priorities defined in a complex system of agreements.
(End of part 1 of 2 parts. To be continued.)
About the author
Robert Falkowitz is a professional Lean coach, developer of Kanban foundation courses, and a certified service management consultant.