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