This is the third part of a series proposing a Manifesto for Service Management Agility. It draws upon the Manifesto for Agile Software Development and proposes a modified version of that manifesto’s propositions, based on the issues characterizing the management of services. In this installation, I will discuss the first proposition, “Individuals and interactions over processes and tools”. How would a Manifesto for Service Management Agility understand, and possibly reword, that proposition? If you wish to jump to the punchline, here it is.
Are tools inherently rigid?
The proposition being examined seems to imply that tools are inherently more rigid than people, or conversely that people can be more agile than tools. Is this so in a service management context?
Thanks to the work of Marshall McLuhan, we have known for more than a half-century about how “electronic” tools mediate between humans and their environment. These tools are veritable extensions of the human body, like a hammer at the end of an arm. Tools transmit the will of the user to the environment, but also shape the user’s view of that environment.
As services are increasingly delivered via technology, and especially information technology, the use of tools to manage those services takes on new importance. Such tools are indispensable as a means of detecting what the technology is doing, or is failing to do, in the course of delivering a service. While a person can easily detect when a web service is far too slow, without the right tools, it is impossible to know if that poor performance is due to overloaded processors, poor database query optimization, insufficient network bandwidth, insufficient memory, and so forth. If agility depends on good assessment of the current situation and understanding the probable paths of evolution of that situation, it is fatuous to say that something else is valued greater than the tools providing that critical data.
So long as our technology lacks the intelligence to interpret the messages detected by monitoring tools (a situation that is rapidly changing), we still depend on people to filter, normalize, correlate, interpret and act upon the detected data. Even so, the contribution by support personnel is not to be valued more than the tools they use; they are equal partners with their tools. The most courteous, pleasant-mannered help desk agent is useless unless he or she has the telemetry needed to diagnose a support issue. Conversely, it is greatly frustrating to report an issue to a service provider and then be told that the problem cannot be reproduced or that all the lights are green, so it can’t be the provider’s fault.
One can even make the case that tools are increasingly tipping the balance in favor of being more valuable and agile than people when it comes to managing services. For many types of support, users often prefer self-service tools to human agents, increasing the agility with which support may be delivered. As service systems become more complex, tools will start to become the only way volumes of data can be correlated and probabilities accurately assessed. As tools increase in logical intelligence today—and perhaps emotional intelligence in the future—they may succeed in making the human support agent redundant, because they may be able to learn more objectively, without being straight-jacketed by previous experience and practices. Finally, automated tools will increasingly detect significant state changes and trends, will automatically adjust systems to reflect probable future needs and will automatically repair themselves when they fail.
A dumb tool is neither agile nor rigid. It might be easier or harder to reconfigure, but it is essentially the extension of its user.1 Tomorrow such dumb tools will be replaced increasingly by intelligent tools that can learn and are, by themselves, agile. The relative contribution of tools to agility will only increase as the tools themselves learn how to learn, bypassing the biases inherent in human training of tools.
In summary, for services that use little or no technology, the issue of valuing people over tools is largely irrelevant. For services that depend on technology, especially as that technology becomes increasing sophisticated and complex, tools are sine qua non for service delivery and support. And we might expect that they will increasingly become the more valued partner in the human-technology system. For these reasons, I would remove the reference to tools in the proposition for service management agility.
Are processes inherently rigid?
The Manifesto for Agile Software Development would have us believe that people and interactions can be more agile than processes.2 Well, this should be obvious, if by “process” we understand “a certain way of doing work”. A process, however we define it, is inevitably a way of constraining what we do. So processes militate against agility. But agility is not the only factor in being able to do work effectively and efficiently. Indeed, for certain types of work we probably do not want to be or need to be very agile. So, an “agile manifesto” needs to describe what we value in order to be agile, so long as we meet the higher level goals of the domain in which we are working. Effectiveness and efficiency should not be sacrificed on the altar of agility. We should not, as the Germans might say, throw out the baby with the bath water, or, as the French might say, throw out the champagne with the cork.
Our question should really be, “What degree of procedural constraint is appropriate to our management of services?” The answer is probably going to be somewhere between, “Work in just any old way that appears to make sense at the time” and “Do work in exactly the way we agreed in advance to do it.” Can we articulate a proposition better than simply saying that people and collaboration are valued more than processes? I think we can do so.
We can attack this question from two directions. From the point of view of people and collaboration, a process is subject to tuning, adaptation and optimization, via experiments testing the structure, the parameters and the controls put on a process. By getting quick feedback from these experiments, processes can be regularly tuned to the current needs. From the point of view of work variability and risk, we should be agile in our selection of the most appropriate way of handling an issue. Sometimes, a very fixed approach is most appropriate. Other times, a flexible, evolutive approach gives better results.
How can the principle of experimentation to tune processes be applied to service management? Let’s cite a simple example. Service providers should recognize that the service requests coming from their customers vary from highly standard requests to completely ad hoc, sui generis requests. In other words, certain types of service requests have a high degree of variability, from one to the next, whereas other types hardly vary. Similarly, the manner of fulfilling the requests can vary from highly standardized responses (see Fig. 2) to responses that can only be discovered as the work advances and may vary from case to case (see Fig. 3). Many types of fulfillment fall between the two, using a series of tried and true patterns of work, but not necessarily in a fixed order or with fixed dependencies. This is the realm of adaptive case management.
In the case of highly standardized requests and fulfillment, agility might detract from overall value, making the results less predictable, both in terms of timing and in quality. So there is need for agility in the qualification of the different types of service requests and how to handle them. Rather than handling all service requests via the same, inflexible, laborious process, we need to quickly recognize which cases benefit from a more agile approach and which cases benefit from a more predictable, deterministic approach (see Fig. 4).
To phrase this differently, a non-agile approach to optimizing processes seeks to reduce the mean cycle time of the process and reduce the standard deviation of cycle times for the process as a whole. It does so by attempting to perfect a single, theoretically, optimal procedure. An agile approach seeks the same result using probabilistic, and evolutive, rather than deterministic, handling of the request.
Individuals or teams?
I don’t know if the authors of the Manifesto for Agile Software Development chose the term “individuals” to express a distinction from teams and organizations, or to emphasize the human aspect of software development, or for yet some other reason. Whatever the case, I am not sure that “individuals” is the most useful way to express the proposition’s contrast in a service management context.
While it might be true that some service providers consist of single individuals who deliver and manage services, I think the vast majority of providers are composed of multiple individuals organized into teams. Much of the problem of rigidity versus agility is derived from the mental models, controls and structures introduced into organizations for the very reason that they do need many people and many teams to do their work.
That being said, no proposition in the Manifesto for Agile Software Development directly addresses the issues of working as individuals versus working as teams. I will come back to some of these complementary issues in a future article. For the time being, I prefer to eliminate the reference to “individuals” in an agile proposition, given that the term might be misleading if taken at face value.4
Interactions versus processes
In the discussion above I emphasize the role of adaptive case management in the fulfillment of many types of service requests, especially those commonly handled using knowledge work. This same adaptive approach is applicable to many disciplines within service management. Problem management, strategy generation and service design are perhaps the most obvious examples. As this subject has been discussed for many years now and is largely beaten to death, I will not belabor it here.
In addition to the adaptive aspect of work in service management, we also 
need to think about the impact of psychology and human interaction on the success of the process activities. While a process might specify what work you do, how you execute that work has a profound effect on its result. How you do the work is not only a matter of how you interact with your colleagues. It is also a matter of your internal motivations and your psychological state. This is especially true in service delivery, where the interaction between provider and consumer is at the heart of the activity.
I think there are four key aspects of human interaction that facilitate agility: inquisitiveness, respect, trust and empathy. Respect and trust are certainly related. You can hardly respect someone you do not trust, and vice-versa. These, in turn, facilitate empathy, the ability to feel and identify with the emotional state of another person, from the same perspective as that person. Perhaps we are talking of the broader realm of emotional intelligence, although the latter term carries with it a lot of baggage that might not be desirable to carry in this context. Similarly, one might be tempted to speak of mindfulness, although this trait is often considered to refer to self-awareness, more than interactions with others.
How do these traits facilitate agility in work? Inquisitiveness, when used within appropriate bounds, helps maintain a mind open to other possibilities for understanding problems and for effecting work. It is essential to the adaptive approach to case work. Trust and respect allow us to take risks in what we say and do. They help free us from the constraints of the old, tried and “true” ways of doing things (i.e., the process), when it becomes evident that those ways of working are neither pertinent nor effective nor efficient. They allow for the experimentation to tune ways of working, to which I referred above.
Respect and empathy facilitate the alignment of a team on a certain way of doing things. If a team were composed of individuals who do not agree on how to do work and cannot bring themselves to understand or agree with the perspectives of others, then that team will be bogged down in disagreement, rather than quickly and agilely aligning on what to do next.
Inquisitiveness, respect, trust and empathy are operative during the interactions between the provider and the consumer, as well as the interactions among the people working for or with the provider. In the former case, the interactions constitute the collaboration mentioned in the third proposition of the Manifesto for Agile Software Development, “Customer collaboration over contract negotiation”, which we have discussed in a previous article. We return here once again to the issue of a tautological proposition. For a service, which is an interaction, the interaction is, of course, more important than the process. In the context of service management, valuing the interaction is too obvious and too vague to make a manifesto actionable. This is why we had to dig down and be more precise about the particular aspects of service interactions that are to be valued more than the process.
Rephrasing the proposition for a Manifesto for Service Management Agility
Let me summarize then the discussion of the proposition, “Individuals and interactions over processes and tools”.
In a service context, tools, which are essential to the management of the service, are either neutral with respect to agility or even a means for increasing agility. Therefore, reference to tools should be removed for the purposes of our revised proposition.
Since most service providers are composed of more than one individual and organizational agility requires behavior that might be different from the simple sum of personal comportments, I prefer to remove the potentially misleading reference to “individuals” from the proposition.
Processes, by definition, militate against agility. However, when defined at a high level, processes enable the sharing of approaches and the focusing of team effort. The issue is not with processes, per se, but with a futile attempt to define what work to do at too detailed a level, when the nature of the work requires that methods be progressively tuned and adapted as the work itself evolves. As a corollary, however, when work does indeed benefit from strictly following processes, not only is that work done more effectively and efficiently, but more time is freed for the types of work that do benefit from greater agility, making the overall approach to work more agile.
In sum, agility should be applied first in selecting the level of detail needed to effectively and efficiently perform the work, and secondly in performing the work itself, should a strict and detailed process be inappropriate to the nature of the work.
Services are fundamentally interactions, so we gain little by saying that service management should value interactions more than something else. Inquisitiveness, trust, respect and empathy are the aspects of interactions that facilitate agility and thereby facilitate achieving the purposes of our services and their management. For the sake of creating a proposition that is easy to remember and articulate, I summarize these aspects as “emotional intelligence”. However, that term is used with great reserve, because some aspects of it are ambiguous, easily misunderstood and controversial.
For the purposes of a Manifesto for Service Management Agility, I would therefore rephrase the first proposition as follows:
Emotional intelligence over too detailed processes
The article A Manifesto for Service Management Agility—Part III by Robert S. Falkowitz, including all its contents, is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.
Notes:
1 I note, for example, Conway’s Law, which relates the structure of a software application to the communication structure of the organization building it. That being said, the issue of organizational structure and agility is not directly addressed in the Manifesto for Agile Software Development. I will address corollary propositions in a future article.
2 I am interpreting what that manifesto has said. Perhaps the manifesto means to say that a system valuing people and interactions more than processes and tools is more agile than a system that values processes and tools more than people and interactions. But I am not sure that this interpretation would yield a different result from one that holds people and interactions to be more agile than processes and tools.
3 It is useful to contrast rigid, physical tools, such as a drill, with software tools. A drill is optimized for making holes, but nothing else. If you try to turn a drill into a saw, you end up with an extremely ineffective and inefficient tool. As the saying goes, to a carpenter with a hammer, the whole world looks like a nail. But the rigidity is in the carpenter, not in the hammer. Software, especially software built using microservices, is far more agile in terms of the effort required to shape it to perform a different task
4 When I discount the role of individuals in favor of teams, I am referring only to the context of executing processes. When a process is executed by a team, or by several teams, many issues of agility exist. In the cases where an entire process is executed by a single individual, many of those agility issues become moot. Individuals are nevertheless of critical importance to the agility of service management. They are the locus of the inquisitiveness, trust, respect and empathy that I discuss below. Thanks to James Finister for pointing out the need to make this clarification.
Fig. 1: By Johnburns007 at en.wikipedia, CC BY-SA 3.0, https://commons.wikimedia.org/w/index.php?curid=2681931
Fig. 5: Mongoose and cobra – source unknown
Fig. 6: By European People’s Party – EPP Summit,Brussels; June 2015, CC BY 2.0, https://commons.wikimedia.org/w/index.php?curid=42028459
[…] Emotional intelligence over too detailed processes […]