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

27 October 2017 by Robert Falkowitz Leave a Comment

Also I shall untangle by what power
The steersman Nature guides the sun’s courses,
And the meanderings of the moon…
lest we should think
They roll along by any plan of gods.
—Lucretius, De rerum naturæ V1

This is the fourth 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 fourth proposition, “Responding to change over following a plan”. How would a Manifesto for Service Management Agility understand, and possibly reword, that pro­position? If you wish to jump to the conclusion, here it is.

Responding and foreseeing


Dude: Say, I hear you’re driving to the west coast.

Downeaster: Aaayup
Dude: Which route are you taking?
Downeaster: Ooh, through Worcester

Everyone would probably agree that these two capabilities:
  • recognizing when things have not gone according to plan; and
  • adjusting one’s actions in function of the new and unplanned circumstances
are at the core of agility. But if we know full well that those cir­cumstances are likely to change, no matter what we might have planned, shouldn’t we em­bed agility in our planning, in addition to reacting to un­planned change? Let’s use an ex­tended analogy to examine planning for agility.
Traffic jam at the entry to the St. Gottard tunnel
Fig. 1: A traffic jam at the entry to a tunnel under the Swiss Alps
Suppose I wish to travel by auto­mobile from Geneva, Switzerland to Milan, Italy.2 A look at the map shows that the fastest route is via the tunnel under Mont Blanc. There are other options, such as going over the Grand Saint Bernard pass, or the Sim­plon Pass, or even going all the way to Ticino and then heading south to Milan (see Fig. 2). Other routes, such as via the Petit Saint Bernard, are conceivable, but let’s keep the list of possibilities manageable.3
route options for travel from Geneva to Milan
Fig. 2: There are many possible routes from Geneva to Milan

Suppose I decide to go via Mont Blanc, potentially the fastest route by far, but when I arrive in the valley of Chamonix, I find that traffic is backed up (see Fig. 1). Is there snow on the approach route? Was there an accident in the tunnel? Or maybe it is a holiday weekend, when such traf­fic jams are common.

At this point, I have two possibilities. Either I wait out the traffic jam and arrive in Italy—perhaps many hours later than expected—or I turn around and take another route through the Alps.

But here’s a key issue. When traffic becomes jammed up, how do I know at that moment whether the blockage is just ahead and traffic will flow again in just a few minutes, or if it will take hours for the problem to sort itself out, or if the tunnel will be closed for several years (as happened in 1999)?

Because I cannot know the answer immediately, I need to have an un­der­standing of three things, to which I will return later in this article:

  • the risk and impact of not arriving in Milan when expected
  • what makes a route fit for my purpose
  • the last possible moment to decide if I should take an alternate route, if I hope to arrive by a certain time.4

According to the Manifesto for Agile Software Development, I would, at the very least, consider taking an alternate route, rather than simply waiting for hours (but who really knows?) to get through the jam.

I suggest that my agility would be enhanced if I were to consider this possibility before committing myself to the Mont Blanc route. If I were to use the Grand Saint Bernard, I could either take the tunnel there or, if the tunnel were blocked up, take the small route that goes over the pass. If I were to go to the Simplon, I could either follow the road over the pass or I could put my car on a train and go through the tunnel. And in Ticino, there are many small crossings from Switzerland to Italy, in addition to the main highway.

The point is that by planning to take a route that provides alternates, by finding a set of routes that allows me to delay commitment to a single route, I increase the possibility of agile action. The agility of that action is increased if I plan in advance by gathering infor­mation about alternate routes and about the conditions of those routes. The concept of delaying commitment to the last responsible moment is already well established, es­pe­ci­ally in the context of managing the flow of work. Thus, it is not specific to the delivery or the management of services.

Agility is thus enhanced by planning for multiple options and by delaying commitment to one option as much as possible (see Fig. 3).5

Possible points of decisions on the routes from Geneva to Milan
Fig. 3: Points where decisions may need to be taken depending on the options, risks, goals and conditions.

When are the last responsible moments for making decisions when planning the route from Geneva to Milan? How long can we put off making a commitment to a certain route? Suppose it takes 4 hours, under the best possible conditions, to drive via the Mont Blanc tunnel. If I wait until 4 hours before my target arrival time to decide on the route, I have effectively reduced my options for arriving on time. I can succeed only via Mont Blanc.

If the next potential option is via the Grand Saint Bernard tunnel, which might take 5.5 hours under optimal conditions, then I need to decide at least 5.5 hours before I want to arrive. And so on.

But I don’t want to decide too soon, either. If I make a plan a week in advance, I will know very little about whether a route is covered with snow or poses some other difficulty. The longer I wait to decide, the more information I will have about the probable traffic conditions. So deciding at the last responsible moment is a trade-off between having a maximum of information to support the decision, on the one hand, and keeping options open, on the other hand.

Furthermore, it depends on the nature of my goals and the degree of risk I am willing to take. If I am traveling to Milan for pleasure, it might make little difference if I arrive 2-3 hours later than desired. If I have a business meeting, then the risk of delay becomes much less acceptable. Thus, risk also influences the options available to me and the latest time to commit to a route.

Finally, the conditions of the route may also influence the possible options and thus the timing for decisions. I once drove to Milan via the Centovalli, a region that takes forever to drive though, on a narrow road that twists and turns without cease (see Fig. 4). It is much prettier than the Po valley, but if your passengers are prone to car sick­ness, it might not be a good choice.

A sinuous route in the Centovalli
Fig. 4: A sinuous route in the Centovalli

Some readers might think that our modern telemetry is all we need to resolve such dilemmas and to make the appropriate compromises. They might believe that by consulting the tools that tell us the current state of traffic, we can decide on the best route even before we leave home. But this reasoning is anything but agile. It uses the available data to reinforce a deterministic and ri­gid approach to work. It tries to make decisions as early as pos­sible, rather than as late as possible. And, of course, the situ­ation at the entry to a tunnel might change radically between the time I start the trip and the time I arrive at the tunnel. So, telemetry and recent history are useful inputs to planning in an agile way and should indeed be used. But they are no better than a detailed project plan if we use that data in a pig-headed way.

factors influencing commit time
Fig. 5: Factors influencing the time to commit. NB: This diagram is not exactly a timeline.

A brief digression

It is with consternation that I note the tendency in contem­porary literature to discuss agility and planning in terms of military strategy and tactics:
  • General Dwight D. Eisenhower: Plans are no­thing; planning is everything
  • Colonel John Boyd: The OODA loop explains sup­remacy of U.S. pilots during the Korean War, in spite of technically superior MiGs
  • Field Marshall Helmuth von Moltke der Ältere: Kein Op­erationsplan reicht mit einiger Sicherheit über das erste Zu­sammentreffen mit der feind­lichen Hauptmacht hinaus (No plan of operations extends with certainty beyond the first en­counter with the enemy’s main strength)
  • General Sun Tzu: Do not repeat the tactics which have gained you one victory, but let your methods be regulated by the infinite variety of cir­cum­stances
John Boyd
Fig. 6: John Boyd
Sun Tzu
Fig. 7: Sun Tzu
General Dwight D. Eisenhower
Fig. 8: Dwight Eisenhower
Helmuth von Moltke der Ältere
Fig. 9: Helmuth von Moltke

Isn’t it odd that we take an activity that we want to perform as little as possible and to be as dangerous as possible, and use it as a model for activities that we want to perform as much as possible and for our mutual be­ne­fit? My intuition tells me that there are some essential dif­ferences that are not yet elu­cidated. A subject to which I might return in the future…

Planning in service management

If we agree that there is value in planning to be agile, what is the situation in service management? Planning is present in service strategy, service design, service transition, service operation and continual service improvement. We see there strategic plans and roadmaps; project plans for de­signing, implementing and im­proving services; and processes for operating those services once in production.

For most of these plans, there is little difference between agility in software development and agility in service management. That being said, I believe that certain software developers exhibit greater maturity in their agile efforts than is the case for most service designers. It is common to see software that is highly configurable and can be used by many different customers in many different ways. Services, however, to the extent that they are not being delivered via software, tend not to have such flexibility built into their designs. These services may be agile, but only to the extent that the people performing the services make them agile. And this occurs, precisely as per the manifesto’s proposition, because they prefer to react to the unpredictable changes during the service act, rather than strictly follow the plan for delivering the service.

Agile service designs

So what would an agile service design be? If we agree that the design of a service includes plans for delivering and managing that service, how can we build agility into those plans, rather than simply depending on people to ignore the plan and play things by ear during the service acts, should the plan not be working? As with the rest of the Agile Manifesto, agility in that design would be a question of relative values, rather than absolute dos and don’ts.

An agile service design would make it clear that the service’s value proposition, its purpose and its goals are to be valued more than the processes used to deliver and manage the service. That the metrics used should reflect those goals, more than being proxy metrics whose measurements are easily per­ver­ted.6 An agile service design will recognize that the most efficient and effective ways of performing the service act will probably evolve over time. Thus, it should not over-specify how to perform those acts. Indeed, the under­standing of the service’s value proposition is almost certainly going to change. And there is like­ly to be a spectrum of cus­tomer personæ, each of which has a somewhat different reason for wanting to use the service. Even though the service provider should try to understand those reasons from the start, it should recognize that the under­standing of those reasons is likely to be refined, based on the practical experience of delivering the service.

Regarding the fitness for purpose of the service, there is little difference between agile service design and agile software development. I see little purpose of restating the principles of agility in this vast domain.7

Rephrasing the proposition for a Manifesto for Service Management Agility

In summary, I find little dif­ference between the planning done for software development and the planning done for service management. The proposition of the Manifesto for Agile Software Development is largely applicable to service management. The differences that exist are more a question of the maturity of the practitioner organizations rather than being inherent in the dis­ciplines.

However, we can go one step farther than simply responding to change, as a way of being agile. We can plan for the variability that characterizes most knowledge work, making it easier to agilely respond to change, while lowering the risks of that variability.

Thus, for the purposes of a Manifesto for Service Ma­nagement Agility, I would therefore re­phrase the fourth proposition as follows:

Planning for change over following a plan

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

Notes:

1 Translated by William Ellery Leonard, published by MIT.

2 This example was inspired by a live presentation by Gojko Adzic. Unfortunately, I cannot recover a precise reference to the video of that presentation.

3 The issue of multiple routes got me to thinking about Richard Feynman’s path integral formulation, the analysis of how to predict the probability that a quantum particle will interact at a given space-time point (requiring that we know about all possible paths from one quantum interaction to another). The number of parallels between quantum theory and contemporary management theory seem to indicate a shared philosophical underpinning.

4  The concept of the last responsible moment has been much discussed in the literature on agility. Some have pointed out that it is not practical guidance, given that we can hardly know when that moment might be. Others consider that choosing the moment is a matter of probabilistic management. We can choose the “right” moment to commit ourselves if we have data about what has happened in the past and if we make an assumption about the level of risk acceptable to us. Given the complexity of acquiring the data and performing the required Monte Carlo simulations to analyze it, we are once again in a position of increasing our agility by preparing in advance, as well as in reacting to unplanned events.

5  Agile planning should make clear assumptions about the risks of each option and treat options as serious possibilities. I would distinguish this type of agility from the practice of building business cases based on “high”, “low” and “probable” assumptions. In my experience, this practice is rarely serious, because the high and low possibilities are not treated as real options. They are not actionable. They are just bad (or good) luck. Agility demands that we manage by something other than luck.

6 Examples of this issue are legion. I am talking about such metrics as the mean duration of a support call. Support agents will do what is necessary to meet the target statistic, at the expense of providing good service. Aside from the fact that mean duration is a meaningless statistic unless we also understand the probability distribution of call durations, we need to value other metrics even more. Thus, we should try to measure whether the support call ended in achieving the goals and if the customer is satisfied.

7  However, agility in software development goes hand in hand with the creation of innovative services based on that software. In the broader realm of service management, many services are not intended to be innovative at all. They might represent the tablestakes required for a provider to be able to compete in a given market space. Or the service might be a bundled must-have utility service, as per the Kano model. I do not mean to say that such services cannot be innovative. Rather, it might be necessary to design and offer certain services even if the provider does not compete on the basis of innovation. For example, an automotive mechanic might feel it necessary to offer a tire changing service in order to attract and keep customers expecting a single provider to cover all aspects of automotive maintenance and repair. However, that mechanic might have no competitive advantage over a provider specializing in tires.

Credits:
Fig. 1: By Haya831 – Own work, CC BY-SA 3.0, https://commons.wikimedia.org/w/index.php?curid=16655230
Fig. 2: © Michelin, downloaded from https://www.viamichelin.com/
Fig. 3: © Michelin, downloaded from https://www.viamichelin.com/
Fig. 4: By Creator:Werner Friedli – E-Pics Bildarchiv online https://doi.org/10.3932/ethz-a-000357887ETH-BIBLIOTHEK, This image is from the collection of the ETH-Bibliothek and has been published on Wikimedia Commons as part of a cooperation with Wikimedia CH. Corrections and additional information are welcome., CC BY-SA 4.0, https://commons.wikimedia.org/w/index.php?curid=59871098
Fig. 6: By Source, Fair use, https://en.wikipedia.org/w/index.php?curid=3723941
Fig. 7: By Unknown – 清宫殿藏画本. 北京: 故宫博物馆出版社. 1994., Public Domain, https://commons.wikimedia.org/w/index.php?curid=57088337
Fig. 8: By Unknown – https://web.archive.org/web/20111119004534/http://www.history.navy.mil/photos/images/ac10000/ap16071.jpg, Public Domain, https://commons.wikimedia.org/w/index.php?curid=272646
Fig. 9: By Kunstverlag der Photographischen Gesellschaft Berlin – Albumin-Foto, Public Domain, https://commons.wikimedia.org/w/index.php?curid=6081849
Summary
Manifesto for Service Management Agility—Part IV
Article Name
Manifesto for Service Management Agility—Part IV
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: agile, agile planning, Eisenhower, John Boyd, manifesto, manifesto for software development, OODA, planning, rigidity, service design, Sun Tzu, von Moltke

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

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

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