Over the past few months I have analyzed the propositions of the Manifesto for Agile Software Development in the context of the issues specific to service management. On this basis, I have proposed revised propositions intended to address the question of agility in service management and have added a fifth proposition. These new propositions constitute a proposed Manifesto for Service Management Agility.
Agile Software Development
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
Service Management Agility
Emotional intelligence over too detailed processes
Services fit for purpose and for use over meeting specifications
Flexible engagement over fixed agreements
Planning for change over following a plan
Distributed decision-making authority over immediate reduction in direct costs
Agile Software Development
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
Service Management Agility
Emotional intelligence over too detailed processes
Services fit for purpose and for use over meeting specifications
Flexible engagement over fixed agreements
Planning for change over following a plan
Distributed decision-making authority over immediate reduction in direct costs
Of what use is such a manifesto?
Why bother? Agility is an old story already, even if many organizations remain sclerotic. I have several reasons for wanting to reinvigorate the subject, even if I am not teaching old dogs any new tricks.
Agility is not a goal in and of itself. It is merely a means for achieving the goals of good management of services. First and foremost, a clearly articulated manifesto would support achieving those goals.
The whole purpose of a manifesto is obviously to make manifest certain ideas, beliefs, values and information. This has been true for the Communist Manifesto, the Futurist Manifesto (however obscure its language might be) and the Manifesto for Agile Software Development. The problem is that terms tend to gain new layers of meaning and lose original meanings very rapidly. For example, a very large number of people really mean “scrum” when they say “agile”. Although such hijacking of terms is inevitable, we try to maintain a semantic center by clearly defining concepts in a manifesto.
It is unlikely that most service management practitioners will read extensively about agility. Nor are they likely to undergo any specific training in an agile method. But, if there is a very short list of easily learned principles, it could help guide those practitioners in making decisions that support the goals of agility.
Any approach to agility must be…well…agile. This means that the principles and values that support the goals facilitated by agility will themselves need to evolve. That evolution may be eased if a set of talking points has first been articulated. Where are the issues in service management that are particularly influenced by agility?
Is this manifesto useful outside of service management?
I won’t pretend to know the answer to this question. That’s up to the practitioners in other domains to decide. My series of articles analyzing the Manifesto for Agile Software Development was not at all meant to be a critique of agility in software development. That domain has its own issues, addressed by its own manifesto. That being said, agility in work in general—and especially in knowledge work—is probably manifested in very similar ways, no matter what the specific domain of the work.
How do the propositions fit together?
Many of the propositions are obviously talking about the same issues, but taken from different perspectives. They are closely related and reinforce each other. I have cross-referenced in the detailed analyses the points where these relationships are most pertinent. Rather than being an orthogonal taxonomy, the propositions are more like a pentahedron or a pentagonal hosohedron, representing five facets of a single whole.
In addition, my particular choice of wording has been strongly influenced by the principles articulated in the lean and kanban world. Anyone familiar with David Anderson’s foundational principles and core properties of “Kanban” will readily recognize how they have influenced me. But more important than that intellectual debt is the demonstration of the close fit between kanban and good service management. In other words, if you agree that agility is a good means for helping to achieve the goals of your services, then you might be asking yourself, “How can we be agile in our day to day work?” Kanban is an excellent way of operating your services to implement your agile approach.
What's next?
I welcome the collaboration of anyone who shares my belief that there is value in articulating and agreeing on such a manifesto. All the propositions can certainly be improved. You may get in touch with me via the form below.
The article A Manifesto for Service Management Agility—Summary by Robert S. Falkowitz, including all its contents, is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.
These have been an enjoyable read, and provide some good ideas for improving how we deliver services and interact with our customers.
Overall, you could summarize this into “Flexibility over Rigidity,” or “Adaptability over Conformity.”
Processes are still important, and in many ways critical, to success. But people have to be allowed to respond to a given situation that falls outside the scope of the process definition.
Well, its both, don’t you think?