This is the second 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 third proposition, “Customer collaboration over contract negotiation”. How would a Manifesto for Service Management Agility understand, and possibly reword, that proposition?1 If you wish to jump to my proposed new version before going with me on a journey and its digressions, here it is.
Forms of collaboration
Let’s take the simple example of cutting hair. The barber cannot perform this service without the cooperation of the customer. The customer needs to clarify the parameters of the service being delivered, specifying hair length, style, perhaps coloring or washing. The customer needs to be physically present. The customer must tilt and turn his or her head to allow the hair to be cut effectively. And the customer gives various signals of approval or disapproval that guide the progress of the haircut.
Similarly, a user support service requires the customer to actively participate in the exchanges that help to specify the nature of the support required, perform the diagnosis and even implement the solution. In the most extreme form, the service becomes a self-service, where the customer performs the entire service act.
Although these forms of collaboration during the service act closely resemble the collaboration during software design and building, the key difference is the immediacy of the interaction in a service act, whereas design and building are generally mediated and consist of additional actions by the developer that do not depend on the presence of the consumer. I suppose it is possible for software developers to build their software in the presence of customers and by continually interacting with them. Maybe this would be the most efficient way to build software, if only the customers deigned to be available. Alas, this is hardly the general practice, even among agile software developers.
If I appear to be belaboring the obvious, it is because I am preparing the ground for what follows and the explanation for why I want to change the manifesto’s proposition.
Contract negotiation
Contracts are a good example of the fact that the manifesto does indeed value the items on the right of each proposition. In a commercial relationship governed by legal codes, a contract—be it implied or a signed document—is unavoidable. In fact, the valuing of collaboration over contract negotiation is an example of the issue described in my earlier article on a Manifesto for Service Management Agility. Although a contract might specify many aspects of the commercial relationship, it is not likely to cover all conceivable types of interactions. Thus, as a way of creating value for both partners, collaboration in good faith is to be preferred to wrangling over the interpretation of what the contract might mean.
Although the Manifesto for Agile Software Development may have envisioned contract negotiation in its literal form, when we talk of services we need to think in broader terms, which I will address in the next section.
Contracting for services
There are various forms of contracts, both implied and formalized, between the service provider and the service consumer. If a service is developed in response to a request from a customer, there may be a contract defining the responsibilities of the parties so engaged. Once the service exists, there may be a contract governing the commercial relationship between the provider and the customer. Or there might be a published set of conditions of service that customers accept, tacitly or explicitly. A commercial contract may be accompanied by a service level agreement. All of these contracts may be constrained by rules promulgated by the applicable regulatory authorities.
Negotiating such contracts is itself a co-ordinating activity rather than a transactional activity.1 Negotiation does not, in and of itself, provide any value to either party. Only when the negotiating has ended, the contracts agreed, the payments made and the work started does value start to flow. So, if a service were to have any value today, but its delivery would be delayed until tomorrow because of contract negotiation, it should be asked if the value increase due to negotiation is greater than the value decrease due to delay in receiving the service (see Fig. 3).
As we have seen, if that negotiation establishes the definitions of fitness for use and fitness for purpose, they are likely to be temporary, incomplete and even erroneous, pending future confirmations by the customer that the service is correct. However necessary negotiation might be, the value of the time spent in trying to define fitness is minimized, if that definition is going to change and evolve as work advances. Thus, agility values the collaboration needed to advance the work over an attempt to specify and constrain the result at the start.
Agility recognizes that at the start of any new project, only a small percentage of what is ultimately needed to be known is already believed to be known, a very large percentage is already known to be unknown and to be determined during the project, and yet another large percentage is unknown and only discovered as work advances (see Fig. 4).
Constraining the agile service provider
We have seen that collaboration between the service provider and the service consumer is at the heart of both service design and service provision. It makes little sense to repeat the agile software development manifesto’s proposition, saying that collaboration, which is of the essence in services, is to be valued more than something else. This would be a tautology. Services without collaboration could not exist. Indeed, collaboration is really a form of service. Instead, I believe that the issue of service management agility concerns whether the service provider ever delivers a service other than what it has agreed with the customer. In this sense, the issue impacting the agility of managing services is not the same as the issue of collaboration and software development.
The essence of the service provider-consumer relationship is that the provider performs acts valuable to the consumer that the consumer either does not know how to perform, or lacks the resources to perform, or cannot manage or otherwise has decided not to perform on its own. The provider does this via an offering of services, but also with the transfer of goods to the consumer. In return, the provider receives value, in the form of funding or payment for the services, in the form of increase in skills, knowledge and experience and in the form of enhanced reputation. When in doubt about what service acts to perform, the fundamental guideline should be whether the service act is part of this mutually beneficial exchange. But a service provider can hardly deliver all the services a customer might wish to receive. What constrains the agile service provider?
First of all, the same reasons used by the service consumer for seeking a provider in the first place should also apply to the prospective provider. If that provider lacks the skills or the resources to provide the service, it makes no sense to attempt providing it, even though the consumer might request that service. On the other hand, the service provider might be able to indicate to the consumer another provider who is capable of deliver the requested service.
But what about the case where a service is requested that the provider is fully capable of delivering, but one that has not been negotiated in a contract, one that is neither in any service catalogue nor mentioned in a service level agreement?
The stiff, inflexible, arthritic provider might tersely reply, “We don’t offer that service”. Such an organization might be unwilling to take risks in re-allocating its resources, even for the shortest of terms. It is probably an organization where everyone is constantly busy and where everyone has the belief that they never have any time to do anything other than their prescribed tasks. When such organizations start to lose customers or revenue, they tend to reinforce their existing behaviors, adding more and more controls, trying to maintain market share of an ever-diminishing market.
A more agile provider might respond, “Let’s see what we can do to help you with this request”. It is like a bather at the seaside, cautiously testing the waters. If the temperature is not too cold, she takes another step. If she is not surrounded by medusas, sharks or slimy seaweed, yet another step. And if the bottom starts to fall away, she can always quickly return to shore.
A fully supple provider might respond, “That sounds like a promising area for a new or modified service. Let’s investigate”. Its personnel focus more on delivering value rather than keeping busy. It is willing to take greater risks to better understand what customers really need and how those needs evolve. It is able to nimbly reallocate its resources on a longer term basis, if it turns out that a promising new service has been revealed, just as it is able to quickly step back if the affair turns out to be unpromising.
The agile service consumer
The remarks in this comparison are meant to indicate relativistic trends, only. There is no strict dichotomy or frontier between being agile and being rigid. As the manifesto itself indicates, there are multiple axes for assessing agility and those assessments are along a gradient.
It may turn out that we need to add a new proposition to the Manifesto for Service Management Agility to address the issues raised by consumer agility versus provider agility. I reserve that possibility for a future article.
Rephrasing the proposition for a Manifesto for Service Management Agility
Unlike the case of the software developer, a service provider’s agility is not so much a contrast between its level of collaboration and its contracts. Whether agile or not, some level of collaboration is in the nature of services. Rather, the key issue, when contrasted with contract negotiation, concerns when the provider commits to an engagement with respect to the consumer. At one end of the gradient, commitment to engagements for service acts are made in advance, with no possibility of changing those commitments as part of the service act itself. In such cases, engagement is solely in the domain of contract negotiation, albeit that domain is expanded to include other forms of agreements, both tacit and explicit, between the provider and the consumer.
As we advance through the gradient of agility, the provider progressively delays commitment until the performance of the service act. By delaying this commitment, the provider keeps open more options:
- to find higher levels of value
- to investigate avenues for service delivery that were hitherto unexploited or unknown
- to better manage the flow of its work by delaying engagement to perform work until the last responsible moment
- to take advantage of serendipitous situations
Thus, I would rephrase the proposition in a Manifesto for Service Management Agility as:
Flexible engagement over fixed agreements
The article A Manifesto for Service Management Agility—Part II by Robert S. Falkowitz, including all its contents, is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.
Notes:
1 That is to say, negotiation is a means for organizing and managing (co-ordinating) the “real” work of the service (transacting). Co-ordination might determine and frame the transaction or the service act, but it does not, in and of itself, provide anything of value to a customer. There are many similar terms for this contrast in the types of work. For example, David Marquet refers to “blue work” and “red work”.
Fig. 1: Downloaded from https://timbercreekfarmer.com/chicken-nesting/
Fig. 2: See page for author [CC BY 4.0 (http://creativecommons.org/licenses/by/4.0)], via Wikimedia Commons: https://commons.wikimedia.org/wiki/File:A_barber_cutting_a_man%27s_hair._Watercolour_painting._Wellcome_V0019644ER.jpg
Fig. 5: By Samuel Soundararaj – Own work, CC BY-SA 4.0, https://commons.wikimedia.org/w/index.php?curid=49440796
Julio Jurado says
1 November 2017 at 17:14Very interesting approach about agile manifesto. Please let me know where can I get Part I to get a better picture of your point of view.
Robert Falkowitz says
1 November 2017 at 22:08Thank you for your feedback, Julio. Part I is here: https://www.3cs.ch/manifesto-agile-service-management-1/