• 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 V

7 November 2017 by Robert Falkowitz 1 Comment

I have written four articles, each analyzing one of the propo­si­tions of the Manifesto for Agile Software Development and proposing a modified ver­sion based on the issues characterizing the management of services. In this article, I ask whether there are values pro­moting agility and specific to the management of services that I have not yet discussed. Does the simple fact that the values for agile software development have been expressed in four propositions mean that the values of service management agility, too, can be ex­pressed in four propositions? Do we need to add any pro­positions?

In performing this exercise, I would like to exclude from con­sideration values that pertain to any type of work at all and values that pertain to agility in general. I would like to focus on the issues more specific to service management (see Fig. 1).

Agile service management as a subset of agile work, a subset of work in general
Fig. 1: The values of service management agility are a subset of agile work values, in turn a subset of the values of any type of work

Software development is a service

We may intuit that the values of agile software development would be similar to the values of service management agility. This is because developing software is a type of service. But software de­ve­lopment is, at best, a subset of services. There are other types of services that do not create goods subsequently transferred to a new owner. Many services transform an object, such as hair cutting or automobile repair. Other services share infor­mation on an ad hoc basis, such as certain aspects of providing customer support. Con­se­quent­ly, we should not be surprised were we to need additional propositions describ­ing the core values of service management agility.

A manifesto is not a complete description

The reader might respond to my previous remark by enthusi­astically saying, “Yes! There is a lot about agility that has not yet been described.” This is undoub­tedly true, but it is the purpose neither of a manifesto nor of this series of articles to provide a complete overview of agility. We are focusing here only on the relative values that guide work­ing in an agile way.

Agility and organizational structure

There has been a lot written about organizational structure and its impact on agility. Or perhaps it is the other way around—the structure of agile organizations tends to evolve in certain directions. I doubt very much, though, that the simple fact of organizing workers in a certain way is likely to make them work with greater agility. At worst, certain organizational types might tend to constrain agility. It should be clear that if you need to pass through three levels of a hierarchy to get anything done, it will be hard for that organization to be agile. But I think this issue is better addressed in terms of decision-making, which I discuss below. An agile organization is not likely to adopt a single struc­ture and assume that that structure is inherently the single most agile one. Rather, it is apt to readjust its structure as conditions change. Further­more, a particu­lar structure that suits an agile organization might not suit another organization. For these reasons, I prefer not to invoke organizational structure in the proposed manifesto.

Agility and communication

Another area of great impor­tance to any organization, whether it intends to be agile or not, is communication. The importance of effective and efficient com­munication cannot be over-estimated. But is good communi­cation to be valued above something else to promote agi­lity? It is very easy to identify communication problems and show how they mitigate against agility. But, from the moment an organi­zation is composed of more than one person, no matter its culture—agile or otherwise—good com­muni­­ca­tion is key to achieving its mission.1 Referring to Fig. 1 above, I would place the ques­tion of communications at the level of all work, rather than specifically referring to ma­nag­ing services. Therefore, I would not add to an agile manifesto any propositions about com­muni­ca­tion, per se.

Agile decision-making

A third realm of great impor­tance to achieving any organi­zation’s mission is decision-making. Who is authorized to make what sort of de­ci­sions? How does it make those decisions? How long does it take to make decisions? How does it assess its own decisions and learn from them?

Much of the discussion in my previous ar­ti­cles intersects with the question of how an org­anization decides. One ex­ample would be the issue of whether it is more important to follow a plan (or process) or to achieve an intended result is directly re­lated to decision-making. There are many others.

Let’s examine a case more closely. A support agent might have been provided with scripts intended to guide every support call. If it becomes apparent during a call that no script adequately res­ponds to the customer’s request, even though the support agent knows what to do, who is allowed to decide to modify or even abandon the scripts, to give them short shrift? If the support agent is required to end the support session and call back later—once authorized to not follow the script—this is not very agile, as well as being frustrating to the customer (which is a much more im­por­tant issue than agilitas gratia agilitatis).

I believe that the issue of decision-making is much more important in many areas of service management than it is in software development. This is because a key moment of truth in services is simultaneous with the performance of the service act, when the provider is inter­acting with the service con­sumer (see Fig. 2). In soft­ware deve­lop­ment, as with other services that create goods, that moment of truth occurs much later than the initial work of creating the software (see Fig. 3). It occurs when the con­sumer first uses the acquired goods.2 (Please do not misunderstand my meaning: I am not saying that decision-making is unimportant in software development.)

moments of truth in a service
Fig. 2: Although a service has a design and build phase, as with software, the service provider often participates at the moment of truth, during service delivery.
The moment of truth with software occurs after the work of developing it.
Fig. 3: The main work of software development occurs well before the moment of truth in using the software

So, instead of beating around the bush, instead of depending on innuendo and inferences from the other agile pro­po­si­tions, I think it is important to articulate the value that decision-making authority should be granted to the roles being played at moments of truth. In the case described above, an agile organization would grant to the support agent the authority to abandon using scripts in a support case, if their use turned out to be counter-productive. This is because only the support agent has the information about the details of the current case.3

To be agile, give decision-making authority where the information needed is found.
Fig. 4: At the moment of truth during the service act, there is information needed to make decisions about the course of the service. To be agile, grant decision-making authority to the actors during the service act.

Now, if we prefer to push deci­sion-making authority to the place where the information lay, this results in many issues, especially for the organization that seeks to become more agile. But it is not our purpose here to analyze or describe these issues. Instead, we should ask what other values might come into conflict with this one. Let’s look at another concrete example.

A customer calls the service desk of a bank with the complaint that it has been impossible to send emails to the bank since the start of the day. Since the customer can send mail to ev­eryone else, she assumes that the service provider is at fault. Furthermore, the messages are of a highly confidential nature and are time critical.

It turns out that the bank is indeed at fault. It has forgotten to renew a certificate used to encrypt/decrypt email com­muni­cations. The service desk agent wants to satisfy the customer as rapidly as possible, so he re­con­figures the email link so as to allow unencrypted communi­cations until the bank can install a renewed certificate. Not long after unencrypted messaging is enabled, the customer sues the bank for breach of its fiduciary responsibility to maintain the confidentiality of its com­muni­cations.

The authority to make this difficult decision has been pushed to the person at the front line. The bank has acted agilely and has resolved the incident rapidly. But in re­tro­spect, the decision was not a very good one. The value of the email communications was ex­tremely high and the risk of intercepting the email was consequently very great. Fur­ther­more, the agile method of deciding quickly, getting feed­back and adjusting on that basis provided cold comfort to the bank. Its reputation was already be­smirched and it risked paying a very hefty fine, in addition to losing at least one customer.

What are the values that come into conflict in this case? The support agent apparently lacked either the information or the skills or the experience required to make a more appropriate decision. Why does this happen? Often, management tries to cut costs by hiring people with the minimum of skills and ex­peri­ence required to do a job, a strategy left over from job specialization and the hierarch­ization of tasks.

These lower-salaried employees are not expected to make any but the simplest of decisions and those entailing little risk. Furthermore, they are mis­treated as disposable re­sources. Manage­ment thinks there is no point in developing them as employees because they will just go elsewhere to work if they gain too many skills. Man­age­ment believes there is no point in providing more infor­mation than necessary, because that infor­mation will leave with the employee when he or she finds work elsewhere. In any case, the organization does not share information unless there is a demonstrated need to know it.

decision-making authority vs cost cutting
Fig. 5: Moving decision-making authority to the front line is assumed to be less expensive than direct cost cutting and hierarchical decision-making

So, if an organization is going to distribute decision-making au­thor­ity, it must also develop the people making those decisions and provide them with the information required by the job. Cutting costs and saving money is something that all organi­zations value, but the agile organization will value distr­ibuted decision-making even more. The assumption is that giving decision-making aut­hor­ity to the people who have the required information will, in fact, cut costs even more than the short-sighted approach of re­liev­ing “entry-level” jobs of such authority and introducing mul­tiple layers of validations into work processes. Thus, a fifth proposition in the proposed Manifesto for Service Management Agility would be:

Distributed decision-making authority over immediate re­duc­tion in direct costs

While all service providers value being able to reduce costs, the agile service provider will prefer to distribute decision-making throughout the organization, even if that means hiring more skilled, experienced and ex­pen­sive workers. It assumes that it will end up saving even more money in this way, as well as gaining many other benefits of agility. At the same time, the organization manifests greater respect for its employees and helps them to develop their professionalism.

Other propositions?

I have enlarged the proposed Manifesto for Service Management Agility by adding a fifth proposition. There are perhaps other propositions that might usefully be added. This depends on the experiences of the people who would add them. We have seen that the propositions intersect each other. Using different perspectives on ma­nage­ment may thus yield different propositions that none­theless describe the same phenomena. For example, some people might understand the example I gave above concerning encrypted messaging as an issue of knowledge management, rather than an issue of distributed decision-making.

Going from a proposed manifesto to the manifesto of a movement or a group would required elucidating, debating and agree­ing on a list of propositions. I hope this will occur, even if that list will need to evolve…agilely.

Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License The article A Manifesto for Service Management Agility—Part V by Robert S. Falkowitz, including all its contents, is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.

Notes:

1 I would not confuse “good communication” with streaming all information to everyone. Furthermore, while it might be that there is a perceived conflict between communication and information security, I wouldn’t say that agility values open communication over information confidentiality. There are often excesses in both directions that are harmful to the agility of the organization.

2 This is one moment of truth among others in the software development life cycle.

3 This is not entirely true. If the service act is mediated by technology, then that technology may also have many of the details embedded in it. The service consumer, too, has many (if not all) of those details. The impact of customer agility on the success of the overall service is an exceedingly important issue. However, service providers have only limited influence over consumer agility. Three of the four propositions I have already discussed intersect with how providers can encourage consumers to be more agile (##1, 3 and 4). Perhaps we also need to think of a manifesto for agile service consumption.

Summary
A Manifesto for Service Management Agility—Part V
Article Name
A Manifesto for Service Management Agility—Part V
Description
In our proposed Manifesto for Service Management Agility, should we add any other propositions to the four revised propositions that were based on the Manifesto for Agile Software Development?
Author
Robert S. Falkowitz
Publisher Name
Concentric Circle Consulting
Publisher Logo
Concentric Circle Consulting

Filed Under: Agility, Service Management Tagged With: agile manifesto, communications, decision making, manifesto, manifesto for software development, organizational structure

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

Comments

  1. Martin PetderMartin Petder says

    13 November 2017 at 17:39

    I would say it’s still a variant of “Individuals and interactions over processes and tools” 🙂
    .. although a more specific and important case. Maybe a bit too specific for manifesto level.
    Also I think you touched a topic neglected from the Manifesto of Agile Software Development – this is of responsibility. While from the viewpoint of feature delivery “crap in == crap out” is acceptable as it will be improved in next iteration – your example of e-mail handling indicates a different expectation in case of actual service usage. I would think this responsibility topic (i.e. service consumer trusting service provider to cover some of it’s risks because of latter’s special competence) would be of value also for software development..

    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

service management tools problem manifesto flow impact waste Cost of Delay lead time knowledge work Incident Management flow efficiency knowledge management automation service request process incident kanban training resource liquidity process definition change management histogram context switching ITSM lean service manager priority value stream incident management tools bias statistical control chart manifesto for software development process metrics kanban ITIL lean management agile rigidity cause risk kanban board
  • 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

This site uses cookies . You accept those cookies when you continue to use this site. Cookie policyAllow cookiesNo 3rd party non-functional cookiesCookie policy
You can revoke your consent any time using the Revoke consent button.Change cookie settings