The Agile Manifesto has borne not just fruit, but complete orchards and plantations. But as we know, that document intended to be a manifesto for agile software development. Let us examine how that manifesto may be adapted for service management. What would a Manifesto for Service Management Agility be?1
The Manifesto for Agile Software Development consists of four propositions, representing relative values in an agile organization:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
In this article, I will examine the second proposition, proposing an adaptation for the purposes of service management.
Services instead of software
We might be tempted to refer to working services in the place of working software. But what does it mean for a service to be “working”?
On the one hand, a service should deliver some output, used in turn by the consumer of the service to create some value for that consumer. But, for that output to be of any value to the consumer, it is not sufficient for the service to simply “work”, to deliver just some output. It should deliver output that shows awareness of what the consumers are doing, what would be helpful to them and how that output could be used in a practical way. We are speaking of nothing other than output that is fit for purpose and fit for use.
Documentation and configurations
When we speak of documentation in the context of service management, we are really referring to two types of texts. The first is the description of the service itself and how it is supposed to work. This information is encapsulated in the so-called “service design package”. The second is the description of the assets used in the delivery and in the management of the service. This is the information held in a configuration management system. We will come back to this after discussing agility and value.
Agility and value
Service managers who have been indoctrinated with the principles of such frameworks as ISO/IEC 20000, CobiT or ITIL may find it difficult to lower their esteem and the importance of maintaining accurate, complete and timely documentation. After all, it is precisely in this area that many organizations show egregious weaknesses. Difficulties in understanding problems, in resolving incidents, in controlling changes and in fulfilling service requests ensue.
Of course, the manifesto is only talking about relative values. It is not saying that the documentation may simply fall by the wayside. To my understanding, the point of the proposition in a service management context hangs on the distinction between meeting specifications and delivering value.
The heritage of the quality management system movement, as expressed in the ISO 9000 family of management standards (including ISO/IEC 20000), is the belief that quality is an issue of meeting specifications. If you deliver precisely what you agreed to deliver, managing its creation and delivery in precisely the ways that comply with the specifications and the standard, then that delivery is supposed to be of impeccable quality. We see the same phenomenon in the project management world. Many would say that we have correctly managed a project if it is on time, within budget and delivers the specified deliverables.
The great difficulty that the agile movement has identified in these beliefs is that our specifications are often wrong. Or at least, our specifications are often incomplete, out of date or rapidly changing. Rather than simply doing what was agreed, we need to find light-weight means for identifying issues and addressing them rapidly and effectively. The key word here is “light-weight”. After all, most project management frameworks recognize that a project, its scope, its plan, the specifications of its deliverables are all subject to change control. But what happens in practice reveals the ineffectiveness and the inefficiency of such controls. In virtually all the projects I have ever witnessed, the management principles have shown themselves to be useful for reducing project scope (which reduces the planned value), re-planning delivery dates (which reduces cumulative lifetime value), or reducing (or increasing!) project resources (both of which reduce value, due to either lower performance or higher costs). I leave aside the costs in terms of demotivation and stress. So, traditional, non-agile methods are good at reducing value and, at the same time, increasing risk. Certain light-weight methods for managing work, such as kanban, are good at increasing value and reducing risk.
Returning to the relative importance of service value and service documentation, the key point is that it is more important to use the potential value of the service output as the touchstone for how we manage services, rather than the degree to which the service meets its specifications. The classic example of this is the customer who contacts a service desk for support. The service desk agent follows precisely the policies and the procedures that have been established. But, because the particular case raised by the customer includes a number of conditions that were not foreseen in the service specification, the output is of no value to the customer. The result? A service that was “successfully” delivered according to the service designers, but one that failed from the customer’s perspective. Who has not had to submit to such frustration?
Rephrasing the proposition in a Manifesto for Service Management Agility
How would I rephrase the proposition “Working software over comprehensive documentation”? How would it be different in a Manifesto for Service Management Agility? I would say:
Services fit for purpose and for use over meeting specifications
While there is a place for specifying how to deliver a service, the agile manager of services will value more the ability to understand what is important to the customer and to act accordingly. The rare cases where we fail in our service delivery because we have not followed the specification need to be handled, but we don’t want that tail to be wagging the service dog.
The article A Manifesto for Service Management Agility—Part I by Robert S. Falkowitz, including all its contents, is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.
Notes:
1 The subject of agility and IT service management is a crowded field. Many articles have already been published on the subject (see below). My reason for adding to this list yet another discussion is the attempt to reformulate the manifesto itself. There is value in being able to express the concept of service management agility in a few, short propositions.
For example, see also:
https://web.archive.org/web/20210518051222/https://www.itsmacademy.com/content/Agile%20Service%20Management%20Guide%20V1%20031715.pdf
https://blog.itil.org/2014/08/allgemein/what-it-service-management-can-learn-from-the-agile-manifesto-and-vice-versa/
https://www.itsmsolutions.com/newsletters/DITYvol3iss34.htm
https://www.linkedin.com/pulse/20140829131305-61435153-agile-and-itil-a-match-made-in-heaven
https://www.morethanseven.net/2017/01/01/agile-and-it-service-management/
There are many other articles that talk about agility and IT service management without analyzing the specifics of a manifesto.
Robert,
I find your work on the SM manifesto is relevant for the profession. I will spend a few hours these holidays reading and “processing” the 5 posts you have written and i hope I will leave some comments here.
For now, my first thought in this post is just to notice a small change in the perspective you have done: in the Agile manifesto the focus of the sentences is the human behind the development activity. “We” value A over B; but in your rephrasing you adopt the impersonal perspective of the service: “the service fit for purpose over …”
Maybe it’s a little detail but I find the first perspective is calling to action on people and will be more effective.
Finally, a question: have you deliberately avoided the use of the word “value” in the sentence and substituted it by “utility and warranty” ? If so, why?
Your two remarks are of great interest, Antonio. As to the first point, I think you are saying that the summary is missing the equivalent of the preamble to the Manifesto for Agile Software Development, namely:
We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
In my mind, when I wrote, for example, “Emotional intelligence over too detailed processes” I was thinking, “(We as service managers value) emotional intelligence over too detailed processes.”
As to the second point, if I am not mistaken, I have not specifically spoken of “utility and warranty” rather than “value”. Perhaps you are referring to my reference to being fit for purpose and fit for use. Insofar as I make an effort to render the discussion specific to managing services, and anyone experienced in the historical service management frameworks will immediately recognize that we are talking about value, I found this expression to be more to the point. For someone not versed in those frameworks, “value” might be a somewhat vague term that could be interpreted in many ways (see my article https://www.3cs.ch/is_service_value_really_delivered/). Fitness for purpose and for use are generally understood in many realms and so appeals to a broader audience.