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 proposition? 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
- recognizing when things have not gone according to plan; and
- adjusting one’s actions in function of the new and unplanned circumstances
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 traffic 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 understanding 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 information about alternate routes and about the conditions of those routes. The concept of delaying commitment to the last responsible moment is already well established, especially 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
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 sickness, it might not be a good choice.
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 rigid approach to work. It tries to make decisions as early as possible, rather than as late as possible. And, of course, the situation 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.
A brief digression
- General Dwight D. Eisenhower: Plans are nothing; planning is everything
- Colonel John Boyd: The OODA loop explains supremacy of U.S. pilots during the Korean War, in spite of technically superior MiGs
- Field Marshall Helmuth von Moltke der Ältere: Kein Operationsplan reicht mit einiger Sicherheit über das erste Zusammentreffen mit der feindlichen Hauptmacht hinaus (No plan of operations extends with certainty beyond the first encounter 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 circumstances
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 benefit? My intuition tells me that there are some essential differences that are not yet elucidated. 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 designing, implementing and improving 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 perverted.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 understanding of the service’s value proposition is almost certainly going to change. And there is likely to be a spectrum of customer 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 understanding 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 difference 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 disciplines.
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 Management Agility, I would therefore rephrase the fourth proposition as follows:
Planning for change over following a plan
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.
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. 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 – 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
Leave a Reply