I have written four articles, each analyzing one of the propositions of the Manifesto for Agile Software Development and proposing a modified version based on the issues characterizing the management of services. In this article, I ask whether there are values promoting agility and specific to the management of services that I have not yet discussed. Does the simple fact that the values for agile software development have been expressed in four propositions mean that the values of service management agility, too, can be expressed in four propositions? Do we need to add any propositions?
In performing this exercise, I would like to exclude from consideration values that pertain to any type of work at all and values that pertain to agility in general. I would like to focus on the issues more specific to service management (see Fig. 1).
Software development is a service
We may intuit that the values of agile software development would be similar to the values of service management agility. This is because developing software is a type of service. But software development is, at best, a subset of services. There are other types of services that do not create goods subsequently transferred to a new owner. Many services transform an object, such as hair cutting or automobile repair. Other services share information on an ad hoc basis, such as certain aspects of providing customer support. Consequently, we should not be surprised were we to need additional propositions describing the core values of service management agility.
A manifesto is not a complete description
Agility and organizational structure
Agility and communication
Another area of great importance to any organization, whether it intends to be agile or not, is communication. The importance of effective and efficient communication cannot be over-estimated. But is good communication to be valued above something else to promote agility? It is very easy to identify communication problems and show how they mitigate against agility. But, from the moment an organization is composed of more than one person, no matter its culture—agile or otherwise—good communication is key to achieving its mission.1 Referring to Fig. 1 above, I would place the question of communications at the level of all work, rather than specifically referring to managing services. Therefore, I would not add to an agile manifesto any propositions about communication, per se.
Agile decision-making
A third realm of great importance to achieving any organization’s mission is decision-making. Who is authorized to make what sort of decisions? How does it make those decisions? How long does it take to make decisions? How does it assess its own decisions and learn from them?
Much of the discussion in my previous articles intersects with the question of how an organization decides. One example would be the issue of whether it is more important to follow a plan (or process) or to achieve an intended result is directly related to decision-making. There are many others.
Let’s examine a case more closely. A support agent might have been provided with scripts intended to guide every support call. If it becomes apparent during a call that no script adequately responds to the customer’s request, even though the support agent knows what to do, who is allowed to decide to modify or even abandon the scripts, to give them short shrift? If the support agent is required to end the support session and call back later—once authorized to not follow the script—this is not very agile, as well as being frustrating to the customer (which is a much more important issue than agilitas gratia agilitatis).
I believe that the issue of decision-making is much more important in many areas of service management than it is in software development. This is because a key moment of truth in services is simultaneous with the performance of the service act, when the provider is interacting with the service consumer (see Fig. 2). In software development, as with other services that create goods, that moment of truth occurs much later than the initial work of creating the software (see Fig. 3). It occurs when the consumer first uses the acquired goods.2 (Please do not misunderstand my meaning: I am not saying that decision-making is unimportant in software development.)
So, instead of beating around the bush, instead of depending on innuendo and inferences from the other agile propositions, I think it is important to articulate the value that decision-making authority should be granted to the roles being played at moments of truth. In the case described above, an agile organization would grant to the support agent the authority to abandon using scripts in a support case, if their use turned out to be counter-productive. This is because only the support agent has the information about the details of the current case.3
Now, if we prefer to push decision-making authority to the place where the information lay, this results in many issues, especially for the organization that seeks to become more agile. But it is not our purpose here to analyze or describe these issues. Instead, we should ask what other values might come into conflict with this one. Let’s look at another concrete example.
A customer calls the service desk of a bank with the complaint that it has been impossible to send emails to the bank since the start of the day. Since the customer can send mail to everyone else, she assumes that the service provider is at fault. Furthermore, the messages are of a highly confidential nature and are time critical.
It turns out that the bank is indeed at fault. It has forgotten to renew a certificate used to encrypt/decrypt email communications. The service desk agent wants to satisfy the customer as rapidly as possible, so he reconfigures the email link so as to allow unencrypted communications until the bank can install a renewed certificate. Not long after unencrypted messaging is enabled, the customer sues the bank for breach of its fiduciary responsibility to maintain the confidentiality of its communications.
The authority to make this difficult decision has been pushed to the person at the front line. The bank has acted agilely and has resolved the incident rapidly. But in retrospect, the decision was not a very good one. The value of the email communications was extremely high and the risk of intercepting the email was consequently very great. Furthermore, the agile method of deciding quickly, getting feedback and adjusting on that basis provided cold comfort to the bank. Its reputation was already besmirched and it risked paying a very hefty fine, in addition to losing at least one customer.
What are the values that come into conflict in this case? The support agent apparently lacked either the information or the skills or the experience required to make a more appropriate decision. Why does this happen? Often, management tries to cut costs by hiring people with the minimum of skills and experience required to do a job, a strategy left over from job specialization and the hierarchization of tasks.
These lower-salaried employees are not expected to make any but the simplest of decisions and those entailing little risk. Furthermore, they are mistreated as disposable resources. Management thinks there is no point in developing them as employees because they will just go elsewhere to work if they gain too many skills. Management believes there is no point in providing more information than necessary, because that information will leave with the employee when he or she finds work elsewhere. In any case, the organization does not share information unless there is a demonstrated need to know it.
So, if an organization is going to distribute decision-making authority, it must also develop the people making those decisions and provide them with the information required by the job. Cutting costs and saving money is something that all organizations value, but the agile organization will value distributed decision-making even more. The assumption is that giving decision-making authority to the people who have the required information will, in fact, cut costs even more than the short-sighted approach of relieving “entry-level” jobs of such authority and introducing multiple layers of validations into work processes. Thus, a fifth proposition in the proposed Manifesto for Service Management Agility would be:
Distributed decision-making authority over immediate reduction in direct costs
While all service providers value being able to reduce costs, the agile service provider will prefer to distribute decision-making throughout the organization, even if that means hiring more skilled, experienced and expensive workers. It assumes that it will end up saving even more money in this way, as well as gaining many other benefits of agility. At the same time, the organization manifests greater respect for its employees and helps them to develop their professionalism.
Other propositions?
I have enlarged the proposed Manifesto for Service Management Agility by adding a fifth proposition. There are perhaps other propositions that might usefully be added. This depends on the experiences of the people who would add them. We have seen that the propositions intersect each other. Using different perspectives on management may thus yield different propositions that nonetheless describe the same phenomena. For example, some people might understand the example I gave above concerning encrypted messaging as an issue of knowledge management, rather than an issue of distributed decision-making.
Going from a proposed manifesto to the manifesto of a movement or a group would required elucidating, debating and agreeing on a list of propositions. I hope this will occur, even if that list will need to evolve…agilely.
The article A Manifesto for Service Management Agility—Part V by Robert S. Falkowitz, including all its contents, is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.
Notes:
1 I would not confuse “good communication” with streaming all information to everyone. Furthermore, while it might be that there is a perceived conflict between communication and information security, I wouldn’t say that agility values open communication over information confidentiality. There are often excesses in both directions that are harmful to the agility of the organization.
2 This is one moment of truth among others in the software development life cycle.
3 This is not entirely true. If the service act is mediated by technology, then that technology may also have many of the details embedded in it. The service consumer, too, has many (if not all) of those details. The impact of customer agility on the success of the overall service is an exceedingly important issue. However, service providers have only limited influence over consumer agility. Three of the four propositions I have already discussed intersect with how providers can encourage consumers to be more agile (##1, 3 and 4). Perhaps we also need to think of a manifesto for agile service consumption.
I would say it’s still a variant of “Individuals and interactions over processes and tools” 🙂
.. although a more specific and important case. Maybe a bit too specific for manifesto level.
Also I think you touched a topic neglected from the Manifesto of Agile Software Development – this is of responsibility. While from the viewpoint of feature delivery “crap in == crap out” is acceptable as it will be improved in next iteration – your example of e-mail handling indicates a different expectation in case of actual service usage. I would think this responsibility topic (i.e. service consumer trusting service provider to cover some of it’s risks because of latter’s special competence) would be of value also for software development..