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

7 September 2017 by Robert Falkowitz 4 Comments

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.

Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License 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.

Summary
Manifesto for Service Management Agility—Part I
Article Name
Manifesto for Service Management Agility—Part I
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: Service Management Tagged With: agile, change control, incident, ISO 9000, ISO/IEC 20000, kanban, manifesto, outcome, output, problem, service request, specifications, value

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

Comments

  1. Antonio Valle SalasAntonio Valle Salas says

    19 December 2017 at 08:39

    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?

    Reply
    • Robert FalkowitzRobert Falkowitz says

      19 December 2017 at 09:58

      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.

      Reply

Trackbacks

  1. Manifesto for Agile Service Management—Part II | This view of service management... says:
    14 September 2017 at 11:09

    […] valuing of collaboration over contract nego­ti­ation is an example of the issue described in my earlier article on a Manifesto for Agile Service Management. Although a contract might specify many aspects of the […]

    Reply
  2. Manifesto for Agile Service Management—Part III | This view of service management... says:
    5 October 2017 at 11:36

    […] Development, "Customer collaboration over contract negotiation", which we have discussed in a previous article. We return here once again to the issue of a tautological proposition. For a service, which is an […]

    Reply

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

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

Manage Cookie Consent
We use technologies like cookies to store and/or access device information. Consenting to these technologies will allow us to process data such as browsing behavior or unique IDs on this site. Not consenting or withdrawing consent, may adversely affect certain features and functions.
Functional Always active
The technical storage or access is strictly necessary for the legitimate purpose of enabling the use of a specific service explicitly requested by the subscriber or user, or for the sole purpose of carrying out the transmission of a communication over an electronic communications network.
Preferences
The technical storage or access is necessary for the legitimate purpose of storing preferences that are not requested by the subscriber or user.
Statistics
The technical storage or access that is used exclusively for statistical purposes. The technical storage or access that is used exclusively for anonymous statistical purposes. Without a subpoena, voluntary compliance on the part of your Internet Service Provider, or additional records from a third party, information stored or retrieved for this purpose alone cannot usually be used to identify you.
Marketing
The technical storage or access is required to create user profiles to send advertising, or to track the user on a website or across several websites for similar marketing purposes.
Manage options Manage services Manage vendors Read more about these purposes
View preferences
{title} {title} {title}