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.
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:
There are many other articles that talk about agility and IT service management without analyzing the specifics of a manifesto.