• Skip to main content
  • Skip to primary sidebar

This view of service management...

On the origin and the descent of managing services. We put meat on the bones.

  • Kanban Software
  • Services
    • Kanban Software Solutions
    • Consulting & Coaching
    • Training and Seminars
  • Posts
  • Events
    • Events – Agenda View
    • Events – Calendar View
  • Publications
    • Our Publications
    • Notable Publications
    • Quotes
  • About us

A Manifesto for Service Management Agility—Part III

5 October 2017 by Robert Falkowitz 1 Comment

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 pro­position? If you wish to jump to the punchline, here it is.

Are tools inherently rigid?

Tools are not necessarily rigid
Fig. 1: Service management tools are not more rigid than the people using them, even though each tool has limited capabilities. Often, they are equal partners in an activity.

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.

Fig. 4: Request fulfillment as per a standard framework, adapted to improve the coherency of the process.
Fig. 2: A detailed, rigid process may be appropriate in a limited number of cases
agile service request process using OODA
Fig. 3: A flexible, iterative process that is discovered as it advances is more appropriate to much of knowledge work

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.

Agile vs rigid service improvement
Fig. 4: Selecting an agile or a rigid path to service improvement itself requires agility
Let’s take a case to exemplify this. From the perspective of fulfillment, it makes little sense to put in the same hopper of “service request management” the requests to reset a password together with a one-off request to change the access rights of the CEO during a business trip to China. On the one hand, if we were to let every support agent handle the former case however they wish, we are likely to open up the system to social engineering and various other security risks. Thus, while the handling of the request might not be very agile, it might be better, in this case, to be rigid than have to scramble about to clean up the mess after a security incident. Are any exceptions allowed? I would say yes, so long as the person making the exception was also qualified to understand the risks of the exception. On the other hand, the service provider is likely to discover various constraints and requirements as it goes through the process of understanding and fulfilling the changes to access rights during a trip to a place not generally visited. There might be confidentiality issues and levels of threats that are not often encountered elsewhere. You might learn of new or changing regulations only as you progress through the fulfillment of the request. The process model proposed by ITIL® for handling service requests (see Service Operation 2011, p. 90 Fig. 4.6) does not take into account such cases. There might be no request model to apply, which case the diagram does not really handle. Furthermore, many of the decisions in the process flow might need to be made iteratively and in any order, depending on what is discovered during fulfillment.3 In sum, there is benefit to an organization to have shared ways working. We should not dispense completely with processes. However, agility is required in determining the degree of detail to which those processes are defined and the degree to which a fixed order activities should be followed.

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 Provider/consumer interaction is at the heart of servicesneed 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.

visual display of empathy and respect
Fig. 6: Respect and empathy are key factors in service provision

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

Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License 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.

Credits:
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
Summary
Manifesto for Service Management Agility—Part III
Article Name
Manifesto for Service Management Agility—Part III
Description
The Agile Manifesto was originally written for software development. What would a Manifesto for Service Management Agility be?
Author
Robert S. Falkowitz
Publisher Name
Concentric Circle Consulting
Publisher Logo
Concentric Circle Consulting

Filed Under: Agility, Service Management Tagged With: adaptive case management, agile, emotional intelligence, empathy, inquisitiveness, manifesto, manifesto for software development, respect, rigidity, trust

Subscribe to our mailing list

Click here to be the first to learn of our events and publications
  • Email
  • Facebook
  • LinkedIn
  • Phone
  • Twitter
  • xing
  • YouTube

Reader Interactions

Trackbacks

  1. A Manifesto for Service Management Agility—Summary | This view of service management... says:
    24 November 2017 at 10:33

    […] Emotional intelligence over too detailed processes […]

    Reply

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Primary Sidebar

Kanban eLearning

Kanban training online

Recent Posts

  • Verbs, nouns and kanban board structure
  • The role of the problem manager
  • The Three Indicators

Tag Cloud

incident management tools kanban board ITSM histogram Cost of Delay service management tools cause agile context switching change management service request Incident Management ITIL bias manifesto for software development problem process lean management incident knowledge management knowledge work impact kanban training lean process metrics flow efficiency flow automation service manager rigidity manifesto waste resource liquidity priority statistical control chart risk process definition value stream lead time kanban
  • Kanban Software
  • Services
  • Posts
  • Events
  • Publications
  • Subscribe
  • Rights & Duties
  • Personal Data

© 2014–2023 Concentric Circle Consulting · All Rights Reserved.
Concentric Circle Consulting Address
Log in

Manage Cookie Consent
We use technologies like cookies to store and/or access device information. Consenting to these technologies will allow us to process data such as browsing behavior or unique IDs on this site. Not consenting or withdrawing consent, may adversely affect certain features and functions.
Functional Always active
The technical storage or access is strictly necessary for the legitimate purpose of enabling the use of a specific service explicitly requested by the subscriber or user, or for the sole purpose of carrying out the transmission of a communication over an electronic communications network.
Preferences
The technical storage or access is necessary for the legitimate purpose of storing preferences that are not requested by the subscriber or user.
Statistics
The technical storage or access that is used exclusively for statistical purposes. The technical storage or access that is used exclusively for anonymous statistical purposes. Without a subpoena, voluntary compliance on the part of your Internet Service Provider, or additional records from a third party, information stored or retrieved for this purpose alone cannot usually be used to identify you.
Marketing
The technical storage or access is required to create user profiles to send advertising, or to track the user on a website or across several websites for similar marketing purposes.
Manage options Manage services Manage vendors Read more about these purposes
View preferences
{title} {title} {title}