more effective, then tunes and adjusts its behaviour accordingly). This is an opportunity for self-improvement that is in line with CSI and is equally valuable in order to look objectively at the way the organisation or the team is working to provide services, learn from issues that have been encountered and improve in the future.
Simplicity and Efficiency The final aspects of Agile to consider in the light of Service Management are simplicity and efficiency( Agile Principles: Simplicity- the art of maximizing the amount of work not done- is essential; Working services are the primary measure of progress). Agile inherited its attitude here from Lean, which stresses as one of its focus points the removal of muda or“ waste.” Waste is defined as anything that does not contribute to creating value.
With services, the most direct way to simplicity and efficiency is standardisation: standardisation of services, standardisation of service management, standardisation of tools, and so forth.
Standardisation of services leads to simplicity in their operation: rather than having to manage more or less customised services for each customer, you can manage the same services in the same way for each and every customer. The problem is that some customers cannot live with purely standard services and need some level of customisation. Standardisation can then go into two directions: either standardise the core service and leave add-on services up to the wish of the customers- this will at least make managing the core service easier, but requires custom management for the add-ons; or develop an extensive service that includes most if not all of the add-ons that customers may wish for – this standardises the management of the full service, even if customers don’ t make use of the add-on services. In fact, the latter option is against Agile principles of developing minimum viable services, as there will eventually be a lot of customers that don’ t use all aspects of a service. Hence, waste exists in having to support service aspects that are not used. Standardisation of a service therefore only goes so far as a well-established core service. Add-ons will be custom and will have to be so at a cost.
Standardisation of service management is important in any case: for the efficient operation of services, all service management processes must be as simple and straightforward as possible. People need to work with the processes and can do without an overly cumbersome approval hierarchy, infrequent CAB meetings, inefficient communication structures, user-unfriendly tooling and a lack of continual improvement process. The aim is, as the Lean philosophy states, to“ achieve flow in the value stream”: remove all unnecessary tollgates and obstacles in the process and make resources available to provide services in the most efficient way possible [ 6 ].
This all only happens with appropriate management support. Management needs to actively support an efficient service provisioning environment and obtain buy-in from other stakeholders as well, to support an efficient environment. This is why ISO 20000 focuses all the way in the beginning of the standard on management responsibility.
16 itSMFI Forum Focus— June 2017
The Role of Documentation A persistent myth about Agile is that its methodologies would prohibit the use of any documentation. Not only is this not true( Agile Manifesto: Working services over comprehensive documentation, not instead of documentation), it is also bad practice( See [ 5 ] for extensive criticism on deferring documentation in the context of software development). Coming from the software world, Agile tries to reduce overhead that is little to do with the final product and does not add value, such as extensive project plans, detailed requirement documents that are obsolete as soon as written and other non-core documentation. The focus is on creating a working application, as that is what provides value to the customer.
In the services world, this is somewhat different. The nature of services is by definition intangible and therefore needs more description than a software product in order for the customer and end users to know what they are buying. Furthermore, safeguards for the correct functioning of the service need to be agreed and documented in the form of Service-Level Agreements( SLAs) and performance targets may need to be determined in the form of KPIs. The question is, how much documentation is really needed and how extensive does it need to be?
ISO 20000 has been called an exercise in documentation rather than proper guidance on the creation of an efficient Service Management System. The current version( 2011) of the standard does require the service provider to document a fair number of policies, processes and provide proof of compliance in the form of records. This is, however, the nature of a standard that organisations can certify against. The primary aim of ISO 20000 is, however, not to bog down the organisation in bureaucracy, but to provide a framework to work more efficiently, providing services by requiring a( limited) number of service management elements to be put into place. Any documentation needed for e. g. an audit should be living documentation anyhow, as it is to be regularly updated based on the evolving nature of the services provided. Note, by the way, that the new version of ISO 20000-1( expected to be published in 2018) will be lighter on documentation demands.
Back to the question: how much documentation is appropriate? I would say that in the context of services, we need the following customer-facing documentation in a lean fashion:
• A Service Catalogue to show customers what services they can buy;
• High-level Service Descriptions that clarify what business benefits a service can provide to customers( rather than exhaustive technical descriptions);
• Agreed KPIs and SLAs( if contractually required).
In terms of internal documentation, the following would be required:
• An overall Service Architecture, describing the overall aim, context and structure of the service. This is an architecture rather than a low-level design, so does not contain exhaustive technical details;
• Specific customer service details should be contained in a Configuration Management Database( CMDB) or Service Knowledge Management System( SKMS). This should also contain completed user stories, if services are being developed iteratively based on evolving customer requirements;
• The( electronic) Service Backlog or other means to convey the status of user stories that have been requested by the customer or the service owner.
Summary and Conclusion
The preceding description of where Agile may have a positive impact on services and service management has uncovered aspects that are worth looking at and aspects that are more difficult