Agile Service Management with Scrum€¦ · Agile Service Management with Scrum On the way to a healthy balance between the dynamics of developing and the stability of managing the

Agile Service Management

with Scrum

On the way to a healthy balance between the dynamics of developing and

the stability of managing the information provision

Bart de Best

Edited by Louis van Hemmen

Colophon More information about this and other publications can be obtained from: Leonon Media (0)572 - 851 104 Common questions: [email protected] Sales questions: [email protected] Manuscripts / Authors: [email protected] © 2018 Leonon Media Cover design: Eric Coenders, IanusWeb, Nijmegen Production: Printforce B.V., Alphen aan den Rijn

Title: Agile Service Management with Scrum Sub title: On the way to a healthy balance between the dynamics

of developing and the stability of managing the information provision

Date: 30 January 2018 Authors: Bart de Best Publisher: Leonon Media ISBN13: 978-94-92618-08-5 Edition: First edition, first press 2018 ©2018, Leonon Media Nothing in this publication may be reproduced and / or made public by print, photocopy, microfilm, or any other means without the prior written permission of the publisher. TRADEMARK NOTICES ASL® and BiSL® are registered trademarks of ASL BiSL Foundation. DYA® and TMap NEXT® are registered trademarks of Sogeti Nederland B.V. ITIL® and PRINCE2® are registered trademarks of Axelos Limited.

You must learn from the mistakes of others. You can't possibly live long enough to make

them all yourself.

Sam Levensen

Table of Contents VII

Table of Contents 1 INTRODUCTION..................................................................................................................... 1

1.1 BACKGROUND..................................................................................................................... 1 1.2 OBJECTIVE ......................................................................................................................... 1 1.3 TARGET AUDIENCE ............................................................................................................... 1 1.4 STRUCTURE ........................................................................................................................ 2

1.4.1 Chapter 2, Risks implementing Scrum ........................................................................ 2 1.4.2 Chapter 3, Agile definitions ....................................................................................... 2 1.4.3 Chapter 4, Basis concepts for Agile applications ........................................................ 2 1.4.4 Chapter 5, Organisations adjustment for Scrum ........................................................ 2 1.4.5 Chapter 6, Service management with Scrum.............................................................. 2 1.4.6 Chapter 7, Agile service management processes........................................................ 2 1.4.7 Chapter 8, Agile practical examples ........................................................................... 3 1.4.8 Appendices ............................................................................................................... 3

1.5 READING GUIDELINES ........................................................................................................... 3

2 RISKS IMPLEMENTING SCRUM .............................................................................................. 5 2.1 HISTORY ............................................................................................................................ 5 2.2 REVOLUTION IN THE SERVICE MANAGEMENT WORLD ................................................................... 5 2.3 RISK AREAS ........................................................................................................................ 6

2.3.1 Risk area: Unmanageability ...................................................................................... 6 2.3.2 Risk area: not realizing business case ........................................................................ 6 2.3.3 Risk area: Inadequate integration in complex information systems............................ 7

2.4 SUMMARY ......................................................................................................................... 7

3 AGILE DEFINITIONS ............................................................................................................... 9 3.1 AGILE MANIFESTO ................................................................................................................ 9 3.2 AGILE METHODS ................................................................................................................ 11 3.3 SCRUM............................................................................................................................ 11

3.3.1 The Scrum approach ............................................................................................... 12 3.3.2 The Scrum development process ............................................................................. 12 3.3.3 The Scrum terms ..................................................................................................... 14 3.3.4 Projection on service management terms ................................................................ 16 3.3.5 Difference between Agile en Scrum ......................................................................... 17

3.4 KANBAN .......................................................................................................................... 18 3.4.1 The Kanban approach ............................................................................................. 18 3.4.2 The Kanban process ................................................................................................ 18 3.4.3 The Kanban terms ................................................................................................... 19

3.5 THE DIFFERENCES BETWEEN SCRUM AND KANBAN .................................................................... 20 3.5.1 DevOps ................................................................................................................... 21

4 BASIC CONCEPTS FOR AGILE APPLICATIONS ....................................................................... 23 4.1 HUMAN ASPECTS ............................................................................................................... 23

4.1.1 Caluwé colours ........................................................................................................ 23 4.2 METHOD ASPECTS ............................................................................................................. 24

4.2.1 Route to Value ........................................................................................................ 24 4.2.2 Continuous integration ............................................................................................ 25 4.2.3 Continuous deployment .......................................................................................... 25 4.2.4 Integration tests...................................................................................................... 26 4.2.5 Regression tests ...................................................................................................... 26 4.2.6 Maturity ................................................................................................................. 26

VIII Agile Service Management with Scrum

4.3 MEANS ASPECTS ................................................................................................................29 4.3.1 Single / multi Tenancy .............................................................................................29 4.3.2 Loosely / tightly coupled ..........................................................................................29

5 ORGANISATION ADJUSTMENTS FOR SCRUM ......................................................................31 5.1 SCRUM DOES NOT ALWAYS MAKE SENSE .................................................................................31 5.2 SCRUM'S SCOPE IS LIMITED ..................................................................................................32

5.2.1 User organisation ....................................................................................................33 5.2.2 Information management .......................................................................................33 5.2.3 Application management ........................................................................................33 5.2.4 Infrastructure management ....................................................................................33 5.2.5 Mapping on BiSL, ASL en ITIL ...................................................................................33

5.3 MAPPING ON THE DEMAND / SUPPLY CHAIN ............................................................................34 5.4 SUMMARY .......................................................................................................................36

6 SERVICE MANAGEMENT WITH SCRUM ...............................................................................37 6.1 WHAT IS THE IMPACT OF THE AGILE PRINCIPLES? ......................................................................37 6.2 SERVICE DESK FUNCTION .....................................................................................................39 6.3 OPERATIONS FUNCTION ......................................................................................................40 6.4 SERVICE STRATEGY PROCESSES ..............................................................................................40

6.4.1 Service portfolio management.................................................................................40 6.4.2 Demand Management ............................................................................................42 6.4.3 Financial management for IT services ......................................................................43

6.5 SERVICE DESIGN PROCESSES .................................................................................................44 6.5.1 Service level management .......................................................................................44 6.5.2 Supplier management .............................................................................................47 6.5.3 Information security management ..........................................................................48 6.5.4 Availability management ........................................................................................50 6.5.5 Capacity management ............................................................................................51

6.6 SERVICE TRANSITION PROCESSES ...........................................................................................52 6.6.1 Change management ..............................................................................................53 6.6.2 Service asset & configuration management .............................................................55 6.6.3 Service validation & testing .....................................................................................56 6.6.4 Release and deployment management ....................................................................57

6.7 SERVICE OPERATIONS PROCESSES ..........................................................................................59 6.7.1 Event management .................................................................................................60 6.7.2 Incident management .............................................................................................61 6.7.3 Request fulfilment ...................................................................................................63 6.7.4 Problem management .............................................................................................63

6.8 SUMMARY .......................................................................................................................64

7 AGILE SERVICE MANAGEMENT PROCESSES .........................................................................65 7.1 INTRODUCTION .................................................................................................................65 7.2 WHERE IS THE WASTE IN SERVICE MANAGEMENT PROCESSES? .....................................................65 7.3 HOW IS AN AGILE PROCESS ORGANIZED? ................................................................................66

8 PRACTICAL EXAMPLES .........................................................................................................67 8.1 INTRODUCTION .................................................................................................................67 8.2 EXAMPLE GOVERNMENT AGENCY ..........................................................................................67

8.2.1 Introduction ............................................................................................................67 8.2.2 Organisation ...........................................................................................................67 8.2.3 Background .............................................................................................................67 8.2.4 Organisation model .................................................................................................67 8.2.5 Service management processes ...............................................................................69

Table of Contents IX

8.2.6 Challenges and solutions ......................................................................................... 69

8.3 FINANCIAL INSTITUTION EXAMPLE ......................................................................................... 69 8.3.1 Introduction ............................................................................................................ 69 8.3.2 Organisation ........................................................................................................... 70 8.3.3 Background ............................................................................................................. 70 8.3.4 Organisation model................................................................................................. 70 8.3.5 Service Management processes ............................................................................... 71 8.3.6 Challenges and solutions ......................................................................................... 72

8.4 EXAMPLE CARE INSTITUTION ................................................................................................ 72 8.4.1 Introduction ............................................................................................................ 72 8.4.2 Organisation ........................................................................................................... 72 8.4.3 Background ............................................................................................................. 72 8.4.4 Organisation model................................................................................................. 73 8.4.5 Service management processes ............................................................................... 74 8.4.6 Challenges and solutions ......................................................................................... 75

8.5 SUMMARY ....................................................................................................................... 75

APPENDIX A, SCRUM SELF-ASSESSMENT ................................................................................... 79

APPENDIX B, LITERATURE LIST .................................................................................................. 85

APPENDIX C, GLOSSARY ............................................................................................................ 87

APPENDIX D, ABBREVIATIONS .................................................................................................. 89

APPENDIX E, WEBSITES ............................................................................................................. 91

APPENDIX F, INDEX ................................................................................................................... 93

Table of Contents XI

Figures FIGURE 3-1, SCRUM DEVELOPMENT PROCESS. ......................................................................... 13 FIGURE 3-2, SCRUM TEAMS.............................................................................................. 13 FIGURE 3-3, THE KANBAN PROCESS. .................................................................................... 19 FIGURE 4-1, ROUTE TO VALUE. ......................................................................................... 24 FIGURE 4-2, THE LOGICAL RELATIONSHIP BETWEEN MATURITY LEVELS - SOURCE: [HTTP: OGC]. ................. 27 FIGURE 5-1, THE FRONT OFFICE / BACK OFFICE ORGANISATION. ..................................................... 34 FIGURE 8-1, THE ALM ORGANISATION. ................................................................................ 68 FIGURE 8-2, THE ALM-ORGANISATION. ................................................................................ 70 FIGURE 8-3, THE ICT-ORGANISATION.................................................................................. 73

Tables TABLE 1-1, APPENDIXES. ................................................................................................. 3 TABLE 3-1, EFFECTIVENESS ASPECTS OF AGILE SYSTEM DEVELOPMENT. ............................................. 10 TABLE 3-2, EFFICIENCY ASPECTS OF AGILE SYSTEM DEVELOPMENT. .................................................. 11 TABLE 3-3, SCRUM TERMS PROJECTED ON SERVICE MANAGEMENT. ................................................... 17 TABLE 3-4, THE DIFFERENCES BETWEEN KANBAN AND SCRUM. ....................................................... 21 TABLE 4-1, MIND-SETS OF CHANGE STRATEGIES LÉON DE CALUWÉ. ................................................. 23 TABLE 4-2, ROUTE TO VALUE PROJECTED ON SERVICE MANAGEMENT. ................................................ 25 TABLE 4-3, SCRUM DEVELOPMENT PROCESS LEVEL 1.0................................................................ 28 TABLE 5-1, THE FOCUS OF SCRUM ACTIVITIES. ........................................................................ 32 TABLE 5-2, THE FOCUS OF SCRUM ACTIVITIES. ........................................................................ 32 TABLE 5-3, THE FOCUS OF SCRUM ACTIVITIES IN TERMS OF MANAGEMENT PROCESSES. ............................ 34 TABLE 5-4, PROJECTION OF THE SCRUM ON THE FRONT OFFICE / BACK OFFICE ORGANISATION. ................... 35 TABLE 6-1, RELATIONSHIP BETWEEN THE AGILE MANIFESTO AND SERVICE MANAGEMENT PROCESSES. ............ 39 TABLE 6-2, SERVICE PORTFOLIO MANAGEMENT......................................................................... 41 TABLE 6-3, DEMAND MANAGEMENT. .................................................................................... 42 TABLE 6-4, FINANCIAL MANAGEMENT FOR IT SERVICES. .............................................................. 43 TABLE 6-5, THE RISK CONTROL OF SERVICE LEVEL MANAGEMENT. .................................................... 45 TABLE 6-6, THE RISK CONTROL OF SUPPLIER MANAGEMENT. .......................................................... 47 TABLE 6-7, THE RISK CONTROL OF INFORMATION SECURITY MANAGEMENT. .......................................... 48 TABLE 6-8, THE RISK CONTROL OF AVAILABILITY MANAGEMENT. ...................................................... 50 TABLE 6-9, THE RISK MANAGEMENT OF CAPACITY MANAGEMENT. ..................................................... 52 TABLE 6-10, THE RISK CONTROL OF CHANGE MANAGEMENT. .......................................................... 53 TABLE 6-11, THE RISK CONTROL OF SERVICE ASSET & CONFIGURATION MANAGEMENT. ............................ 55 TABLE 6-12, THE RISK CONTROLS OF SERVICE VALIDATION & TESTING. ............................................. 56 TABLE 6-13, THE RISK CONTROL OF RELEASE & DEPLOYMENT MANAGEMENT. ........................................ 58 TABLE 6-14, THE RISK CONTROL OF EVENT MANAGEMENT. ............................................................ 60 TABLE 6-15, THE RISK CONTROL OF INCIDENT MANAGEMENT. ........................................................ 61 TABLE 6-16, THE RISK CONTROL OF REQUEST FULFILMENT MANAGEMENT. ........................................... 63 TABLE 6-17, THE RISK CONTROL OF PROBLEM MANAGEMENT. ......................................................... 63

Appendices APPENDIX A, SCRUM SELF-ASSESSMENT ................................................................................ 79 APPENDIX B, LITERATURE LIST........................................................................................... 85 APPENDIX C, GLOSSARY.................................................................................................. 87 APPENDIX D, ABBREVIATIONS ........................................................................................... 89 APPENDIX E, WEBSITES .................................................................................................. 91 APPENDIX F, INDEX ....................................................................................................... 93

An important sprint forward XIII

An important sprint forward Service management, as charted in recent years, focuses on services. Most important is that the (end) user is adequately served. One of the aspects that plays an important role in service is the functionality offered by applications. Crucial is that this functionality and quality seamlessly match the business processes of the user. This issue has been recognized since the 80's of the last century. Through the use of case-tools, natural language simulations and prototyping, we now, by 2017, have found a new way of developing with Agile and Scrum's principles. In short, cyclical successes, along with the user, come to functionality that is desired / required. Even better: the most required functionality is first developed, thus making the essence visible to the user. Well, then the question is: how does service management fit in? In response to this question, Bart carefully analysed the service management processes in order to find the central question which risks should be managed to deliver service in accordance with the Service Level Agreement (SLA) norms. This risk management is then depicted on Scrum's best practices. Based on this, he describes the recommendations for successful collaboration between management processes and an Agile development process, such as Scrum. Finally, he acknowledges that not only the agile development process must be in order to meet customer expectations, but also the service management processes must be reduced to the actual essence: providing added value to the customer. At this point, Bart concludes this book with his vision to consider service management in an extremely agile manner and shape it by means of the requirement based process design concept. With great pleasure I have taken note of the contents of this book. As an editor, it was a great challenge for me to keep the content on the one hand and barely enough, and on the other hand to provide an adequate response to a broad spectrum of common questions in the market on how to deal with service management in relation with the development of Scrum. And the result is there, a book that has been spelled out, yet suitable for different types of readers. Hopefully, as a reader, you will experience the exposures as useful and useful in your practice. The practice is very obstinate, especially in the field of Scrum! If you have other or additional experiences with service management in cooperation with Scrum, we would love to hear from you! Louis van Hemmen BitAll b.v.

Foreword XV

Foreword From time to time, there has been a major change in the way we look at our development and service management processes. Besides the methods also the means and the people also change. The rising of thinking in Agile terms is not new, but bringing into practise of Scrum and Kanban in this area has been a huge escape in recent years. Many organisations are now orientating themselves to this innovation, which often means that one wants to do something with such innovation, but exactly what is not clear. Other organisations have already begun with Scrum or Kanban but have not yet arrived in a stable phase, with this innovation crystallized and secured. In particular, the interface between development and service management is a green field. With this book, I want to share my experiences with you. The book has an Agile structure. This means, for example, that it describes 'barely enough' what I want to transfer. I'm assuming in this book that you already have service management models in place. I do not explain them. I also assume that you already have some knowledge of Agile techniques. Because in the world of Scrum and Kanban many terms are used in different ways. This book gives an overview of these terms. After the introduction, I first describe the three biggest bottlenecks that I signalled in the market. In short, these are the administrative inability caused by immaturity of the new system development processes, failure to achieve the intended return on investment due to the lack of metadata and finally, the problem to integrate solutions in complex information systems and chains of information systems. Then I give the definitions and describe the concepts used in this book. The solution to these problems is in my view in analysing the risk control we know from the service management processes. In the past, these may not always be as effective and efficient, but are still valid. Whether these controls are now deployed in the service management processes or in an Agile development process, does not matter. As long as these controls are effectively and efficiently used, the identified bottlenecks can be prevented or resolved. Before thinking about a solution, it is important to realize that not all innovative developments have to be realized with Scrum or other Agile developments. There are good reasons to tackle certain developments Agile and the others just through a classic (iterative) waterfall. For those developments that you want to pick up through an Agile approach, it's important that you first depict the Agile development process on your organisation. This can be achieved through a blueprint approach. It allows you to properly map the scope of the Agile development process and design the interface with other service management and development disciplines. I have included a general picture in this book. Next, I describe the controls of service management processes that are relevant in the context of Scrum and other Agile approaches. Per control, I then describe the possible measure in the Agile development process. This will manage the three main bottlenecks and, moreover, many others. Finally, in this book, I refer to my book 'Quality Control and Assurance', which states that a service management organisation only provides truly added value when all Agile service management processes are based on the concept of requirement based process design. This means so much that no functionality in a service management process is formed if this is not ratified by a stakeholder. In this way, we can also get the sting out of the argument that service management processes are bureaucratic and do not yield value to the customer. For example, in the last chapter of this book, there are three cases that describe how in practice the relationship between Agile system development and service management can be shaped. Of course, the list of risks and countermeasures described in the book is not complete. You can help me to supplement this by responding to this book and sharing your experiences with me, which I can be include in a subsequent edition of this book.

Appendix A, Scrum self-assessment 79

Appendix A, Scrum self-assessment

1. Introduction This appendix describes the self-assessment to determine the maturity of the Scrum development process. This chapter describes the scope, purpose, design and operation of self-assessment. The following chapter contains the assessment questions.

1.1 Scope The successful setting up of a Scrum development process is mainly human work. The team organizes itself. Nevertheless, there are generic aspects to recognize in such a Scrum process. The work done by the team can be divided into maturity stages. Getting a Scrum development process working properly is not a sinecure, especially when the Scrum teams have to share information with each other and therefore have to coordinate the implementation. It takes a lot of time and perseverance to get the team to an effective and efficient implementation and to hold it. The drafting of a plan of approach for the design of the Scrum development process is therefore an important tool. A useful approach here is to divide the plan of action into a number of phase plans, with each phase filling in a certain maturity level of the Scrum development process. To determine whether a level is reached, a yardstick must be used. The self-assessment can be used for this purpose. The self-assessment contains a number of questions for each level of maturity, on the basis of which it can be determined to what extent the Scrum development process meets the maturity level. The questionnaire can be used by the Scrum master in the form of a self-assessment and by an auditor in the form of an audit questionnaire. The structure of the questions is kept the same as the ITIL v2 self-assessment, as published on the OGC website [http: OGC]. However, the questions are more detailed, because they are provided with help questions. Section 4.2.6 of this book describes how to complete this assessment. This appendix also contains only assessment questions per maturity level.

2. Scrum self-assessment

2.1 Level 1, Preconditions Q# Questionnaire Y/N M/O Q1.0/1 Has a Scrum team been set up that creates new information systems

and / or changes to it, based on an Agile approach? Q1. Which scrum teams are that? Q2. Which (type of) applications are included?

M

Q1.0/2 Have you identified the customers for your development services? Q1. Which customer group do you recognize? Q2. Are all customers assigned to a product owner? Q3. In which document are the provided services described?

O

Q1.0/3 Has the interface been identified with the customer? Q1. What may a customer request, e.g. features / stories / service requests et cetera? Q2. Is this interface also identified e.g. the product owner or the service desk?

O

Minimum score to reach this level is: ‘Y’ for all ('M') questions plus one 'Y' for the ('O') questions.

No

Table A-1, Assessment level 1.

80 Agile Service Management with Scrum, Appendices

2.2 Level 1.5, Management intention Q# Questionnaire Y/N M/O Q1.5/1 Is the purpose and benefits of the Scrum development process

spread throughout the organisation? Q1. How can this be recognized?

M

Q1.5/2 Are there control data defined to make the Scrum process measurable? Q1. Is the backlog controlled by the product owner? Q2. What is the reliability of the scheduling of entries on the product backlog?

O

Q1.5/3 Are there any agreements regarding the sprint lead time and the amount of story points that are processed in a sprint? Q1. How is it directed and reported?

O

Minimum score to reach this level is: "Y" for all ('M') questions plus one 'J' for the ('O') questions.

No

Table A-2, Assessment level 1,5.

2.3 Level 2, Process functionality Q# Questionnaire Y/N M/O Q2.0/1 Are responsibilities assigned to the various Scrum development

process activities (formally endorsed and is this known in the organization)? Q1. Who is the product owner and who is the Scrum master? Q2. Are the roles, responsibilities and competencies of these roles described?

M

Q2.0/2 Has the scope of the Scrum development process been determined in terms of products and services? Q1. Which products are supported? Q2. What services are recognized?

M

Q2.0/3 Are there any mechanisms for monitoring the lead time of entries on the product backlog and the sprint backlog? Q1. How does monitoring take place and how is this reviewed?

M

Q2.0/4 Are all feature requests from the customer verified for applicability and authorization? Q1. How do you determine what a customer has rights to?

M

Q2.0/5 Do you have a procedure for handling the feature request from application to implementation?

M

Q2.0/6 Do you have a mechanism to improve the Scrum process (sprint retrospective at the end of a sprint)? Q1. How do you deal with that? Q2. Who governs it?

O

Q2.0/7 Do you have a mechanism for implementing continuous integration, regression testing and continuous deployment?

O


Q# Questionnaire Y/N M/O Q1. Which mechanism is used, for example, a DTAP street?

Q2. Has a complete flow been defined, such as integration, regression testing and deployment?

O


No


2.4 Level 2.5, Internal integration Q# Questionnaire Y/N M/O Q2.5/1 Do you compare the delivered deliverables with the original (non)

functional requirements? Q1. Do you register requirements, for example, in the format of a user story?

M

Q2.5/2 Do you have a mechanism to reuse or update the (non) functional requirements for an application in case of a new increment? Q1. Do you determine the impact of a feature based on existing requirements?

M

Q2.5/3 Do you use regression tests based on the requirements to determine whether the functionality and quality that have not been changed still meet the set requirements? Q1. Is there a relationship between requirements on the one hand and acceptance criteria and test cases on the other hand? Q2. Is there a check in the DoD to determine whether the required requirements are met?

O


No


2.5 Level 3, Products Q# Questionnaire Y/N M/O Q3.0/1 Are the standard acceptance reports regularly created and submitted

to stakeholders? Q1. Which acceptance test types are recognized (FAT, User Acceptance Test (UAT) or Performance Stress Test (PST))? Q2. Will this be managed?

M

Q3.0/2 Is the Scrum team's service explicitly defined and agreed including service levels and service norms? Q1. Where are these recorded and managed?

O

Q3.0/3 Are the products and services recorded in a CMDB? Q1. Is there an administration of CIs in order to determine the impact and the risk of the requested feature requests?

O

Minimum score to reach this level is: "Y" for all ('M') questions plus one 'Y' for the ('O') questions.

No



2.6 Level 3.5, Quality assurance Q# Questionnaire Y/N M/O Q3.5/1 Are the standards and other quality criteria applied by the Scrum

team documented? Q1. Is there a determination of the DoD?

M

Q3.5/2 Are the team members of the Scrum team adequately trained? Q1. Which employees? Q2. What courses?

M

Q3.5/3 Does the organisation design and review the Specific, Measurable, Acceptable, Realistic, and Time-Based (SMART) goals for the Scrum development process and are the improvement points managed? Q1. What goals are recognized (functionality, quality and maturity)?

O

Q3.5/4 Does the organisation use any tools to support the Scrum development process? Q1. Which tools for continuous integration? Q2. Which tools for continuous deployment? Q3. Which tools for the regression tests?

O

Minimum score to reach this level is: "J" for all ('M') questions plus one 'Y' for the ('O') questions.

No


2.7 Level 4, Management information Q# Questionnaire Y/N M/O Q4.0/1 Do you provide management with information about service targets

and current performance? Q1. What service norms are identified and what are you reporting? Q2. How do you report on the progress of feature requests and (epic) user stories? Q3. Are measures taken to correct service norm deviations? Q4. Can the product owner initiate organisational changes?

M

Q4.0/2 Do you provide management with information about trends in velocity and service level shortcomings?

M

Q4.0/3 Do you provide management with information about standard services?

O

Q4.0/4 Do you provide management with information about number of requests for new services or changes to existing services?

O


No


2.8 Level 4.5, External integration Q# Questionnaire Y/N M/O Q4.5/1 Does the product owner involve the service level manager and

availability manager when setting up service norms? M

Q4.5/2 Does the product owner consult the service delivery and support processes such as capacity management and financial management during the negotiating of service levels and service norms?

M


Q# Questionnaire Y/N M/O Q4.5/3 Does a central risk and impact analysis take place through a change

management process in case there are heterogeneous features (more Scrum teams involved)?

O


No


2.9 Level 5, Customer interface Q# Questionnaire Y/N M/O Q5.0/1 Do you check with the user whether the activities performed by the

Scrum team adequately meet the needs of the business? M

Q5.0/2 Do you check with the users if they are satisfied with the offered services? Q1. How do you check this?

M

Q5.0/3 Do you actively monitor the trend in customer satisfaction? M Q5.0/4 Do you use the information from customer satisfaction surveys in

your service improvement agenda? Q1. How do you use the information?

Q5.0/5 Do you monitor the perception of the customer regarding the services offered to them? Q1. How do you monitor the perception of the customer?

M

Minimum score to reach this level is: 'Y' for all ('M') questions. No Table A-9, Assessment level 5.

Appendix B, Literature list 85

Appendix B, Literature list Reference Publication

Best 2011 B. de Best, “SLA best practices”, Dutch language, Leonon Media 2011, ISBN13: 978 90 71501 456.

Best 2012 B. de Best, “Quality Control & Assurance”, Dutch language, Leonon Media 2012, ISBN13: 978 90 71501 531.

Best 2014 B. de Best, “Acceptatiecriteria”, Dutch language, Leonon Media, 2014, ISBN 13: 978 90 71501 784.

Best 2015a B. de Best, “Agile Service Management met Scrum in de Praktijk”, Dutch language, Leonon Media, 2015, ISBN13: 978 90 71501 845.

Best 2015b B. de Best, “Ketenbeheer in de Praktijk”, Dutch language, Leonon Media 2015, ISBN13: 978 90 71501 852.

Best 2017a B. de Best, “Cloud SLA”, English language, Leonon Media, 2017, ISBN13: 978 94 92618 009.

Best 2017b B. de Best, “SLA Templates”, English language, Leonon Media, ISBN13: 978 94 92618 030, 2017.

Best 2017c B. de Best, “DevOps Best Practices”, English language, Leonon Media, 2017, ISBN13: 978 94 92618 078.

Best 2017d B. de Best, “Beheren onder Architectuur”, Dutch language, Leonon Media, 2017, ISBN13: 978 90 71501 913.

Caluwé 2011 L. de Caluwé en H. Vermaak, “Leren Veranderen”, Kluwer, 2011, tweede druk, ISBN13: 978 90 1301 65 43.

Deming 2000 W. Edwards Deming, “Out of the Crisis. MIT Center for Advanced Engineering Study”, 2000, ISBN13: 978 02 6254 11 52 .

Galbraith 1973 Jay R. Galbraith, “Designing complex organisations”, Addison-Wesley Longman Publishing Co., Inc. Boston, MA, USA, 1973, ISBN10: 02 01025 590.

Kaplan 2004 R. S. Kaplan en D. P. Norton, “Op kop met de Balanced Scorecard”, 2004, Harvard Business School Press, ISBN13: 978 90 2542 30 32.

Layton 2012 Mark C. Layton, “Agile Project Management for Dummies”, Wiley Publishing Inc., 2012, ISBN 13: 978 1 118 02624 3.

Looijen 2011 M. Looijen, L. van Hemmen, “beheer van Informatiesystemen”, zevende druk, Academic Service, 2011, ISBN13: 978 90 12582 377.

Nimwegen 1992 prof. Drs. H. van Nimwegen R.A., “Praktijkgids De Controller & Informatiemanagement afl. 2 (augustus 1992)”.

Nimwegen 1993 prof. Drs. H. van Nimwegen R.A., “Administratieve processen vastleggen, verbeteren en ontwikkelen”, Kluwer Bedrijfswetenschappen, Deventer, 1993, ISBN13: 978 90 2671 68 81.

OGC 2011 CSI OGC, “Continual Service Improvement”, ISBN13: 978 01 13313 082.

OGC 2011 SD OGC, “Service Design”, ISBN13: 978 01 13313 051.

OGC 2011 SO OGC, “Service Operation”, ISBN13: 978 01 13313 075.

OGC 2011 SS OGC, “Service Strategy”, ISBN13: 978 01 13313 044.

OGC 2011 ST OGC, “Service Transition”, ISBN13: 978 01 13313 068.

Pols 2009 R. Van de Pols, “ASL een framework voor applicatiemanagement”, Van Haren Publishing, 2009, ISBN13: 978 90 87533 120.


Reference Publication

Pols 2011 R. Van der Pols, “BiSL Een framework voor Functioneel Beheer en Informatiemanagement”, Van Haren Publishing, 2011, ISBN13: 978 90 87536 879.

Shalloway 2011 A. Shalloway, “Demystifying Kanban”, Net Objectives Press, www.netobjectives.com/system/fils/Demystifying-Kanban_0.pdf.

Thiadens 1999 T. Thiadens, “beheer van ICT-voorzieningen”, Academic Services, derde herziene uitgave, ISBN13: 978 90 3951 39 03.

Table B-1, Literature list.

Appendix C, Glossary 87

Appendix C, Glossary The Scrum and Kanban concepts are not included in this list because they are already described in Chapter 3. The terms with an underscore are references to terms that are also defined in this appendix C. Term Explanation ASL ASL is a framework for application management. This model describes

how application management can be implemented based on operational, tactical and strategic management processes.

Balanced scorecard The balanced scorecard is a control model depicting critical success factors and performance indicators in four perspectives, namely: the financial perspective, internal perspective, innovation perspective and customer perspective. This control model is used by many companies to monitor the chosen strategy.

BiSL Business information Services Library, is the first and only public standard for functional management and information management. BiSL explains the processes and activities necessary to send information from user and business options. It is a coherent framework, focusing on both operational, tactical and strategic processes, as well as mutual relationships (definition www.ITSMF.nl).

CAB The Change Advisory Board is an advisory body within the Change Management process. In the CAB, change requests are authorized, scheduled and released for production.

CFIA The Component Failure Impact Analysis is an analysis technique that links a ICT service to the ICT components involved. On the basis of this, weak spots in the ICT infrastructure can be found and countermeasures can be taken.

Change Management

Change management is the implementation of changes in the ICT infrastructure in such a manner that disturbances in ICT services as a result of changes are prevented or minimized.

CRAMM-analysis A CRAMM analysis is performed to determine the risks of a product or service. The threats and vulnerabilities are based on the product or service concerned. A countermeasure must be devised of any identified risk.

Generic Acceptance Criteria

Generic acceptance criteria are the requirements that the service management organisation imposes on the ICT products and ICT services to be used. The generic acceptance criteria are based on the critical success factors of the service management organisation's service management processes. These acceptance criteria are called "Generic Acceptance Criteria" because they are information system independently defined. They can even be defined organisation independently by choosing a commonly used reference model like ITIL.

ITIL ITIL is a set of best practices focused on managing ICT infrastructures.

Critical success factor

A critical success factor is a factor that affects the extent to which the goal of a process is achieved.

Measurement requirements

An acceptance criterion should indicate how to determine whether the information system complies with the acceptance criterion.

Performance indicator

A performance indicator is a means that makes a critical success factor measurable. A performance indicator must be able to assign a norm and a measurement unit.


Term Explanation RACI Responsible, Accountable, Consulted and Informed (RACI) is a way of

making tasks, responsibilities and powers of a process clear. This is also called RASCI, with the 'S' for Supportive '.

Review The term has two meanings in this book: • a way of accepting; • a way to verify whether a process is correct implemented and

performed.

RFC A Request For Change (RFC) is a change request to get a new configuration item or change an existing one.

SLA A Service Level Agreement (SLA) is an agreement between a customer and the ICT service provider about the ICT services to deliver in terms of quantity, quality and cost.

Specific Acceptance Criteria

Specific acceptance criteria are the requirements that the user organisation imposes on the ICT products and ICT services to be used. The specific acceptance criteria are based on the critical success factors of the user organisation's business processes. These acceptance criteria are called "Specific Acceptance Criteria" because they need to be determined by organisation and even by product.

SMART Specific A concrete and clear target with described results. Measurable The desired results are measurable in terms of, for

example, time, cost and / or other quantitative criteria.

Acceptable The goal is acceptable and achievable in both the eyes of the one who determines the target as the one who has to achieve the target. The 'A' also stands for 'Accountable', someone must be responsible for the intended purpose.

Realistic The target is realistic (achievable) and relevant given the environment / circumstances within which the goal is to be achieved.

Time-bound The goal is to measure progress towards the goal in terms of milestones and time.

SPOF A Single Point of Failure is component in a system that is causing potential disturbance. The intended solution of a SPOF is to double the relevant component. A SPOF analysis therefore includes the analysis of single-run components in a system.

Test case A test case describes what needs to be tested. Both logical and physical test cases are recognized. The logical test case describes 'what' to be tested, the physical describes 'how to be tested'.

Test scenario A collection of test cases that are related to each other. For example, a test scenario that is defined for a use case.

Table C-1, Glossary.

Appendix D, Abbreviations 89

Appendix D, Abbreviations Abbreviation Meaning ALM Application Lifecycle Management ASL Application Services Library BiSL Business information Services Library

CAB Change Advisory Board

CI Configuration Item

CIA Confidentiality, Integrity and Availability CCTA Central Computer Telecommunications Agency

CEMLI Configuration, Extension, Modification, Localisation, Integration

CFIA Component Failure Impact Analysis

CI Configuration Item

CIA Confidentiality, Integrity, and Accessibility CMDB Configuration Management DataBase

CMM Capability Maturity Model

CMS Configuration Management System

CRAMM CCTA Risk Analysis and Management Method

CRC Cyclic Redundancy Check CSI Continual Service Improvement

DAP Dossier Agreements and Procedures

DevOps Development & Operations

DML Definitive Media Library DoD Definition of Done

DSDM Dynamic Systems Development Method

DTAP Development-, Test-, Acceptance- and Production environment

EPD Electronic Patient Dossier

ETL Extract Transform Load EVO Evolutionary Project Management

FAT Functional Acceptance Test

FiFo First in First Out

FTA Fault Tree Analysis

ICT Information & Communication Technology IT Information Technology

ITIL Information Technology Infrastructure Library

ILM Infrastructure Lifecycle Management

LCM LifeCycle Management

CEMLI Configuration, Extension, Modification, Localisation, Integration NFR Non Functional Requirement

OGC UK Office of Government Commerce

OLA Operational Level Agreement

PBI Product Backlog Item

PID Project Initiation Document


Abbreviation Meaning PRINCE2 PRojects IN Controlled Environments PST Performance StressTest RACI Responsible, Accountable, Consulted and Informed RASCI Responsible, Accountable, Consulted, Supportive and Informed RFC Request For Change ROI Return On Investment RFC Request for Change RPO Return Point Objective RTO Return Time Objective RtV Route to Value SaaS Software as a Service SAFe Scaled Agile Framework S-CMDB Software Configuration Management DataBase SIP Service Improvement Programme SKMS Service Knowledge Management System SLA Service Level Agreement SMART Specific, Measurable, Realistic, Accountable and Timely

SPoC Single Point of Contact SPoF Single Point of Failure

SQL Structured Query Language

SQP Service Quality Plan

TDD Test Driven Development UAT User Acceptance Test

UC Underpinning Contract

VSM Value Stream Mapping

WIP Work In Progress

XP eXtreme Programming Table D-1, Abbreviations.

Appendix E, Websites 91

Appendix E, Websites Reference URL htpp Dialogueincubator http://www.dialoguesincubator.nl/wp-content/uploads/2011 /06

/Scrum.pdf http Blog http://blog.coryfoy.com/2011/07/recreating-Scrum using-kanban-

and-explicit-policies/ http Blogspot http://abcdsliithswkprojects.blogspot.nl/2013_08_01_archive.html http Fastlane https://blog.codecentric.de/en/2014/07/devops-product-

ownership/#more-23866 http IBM http://www.ibm.com http Netobjectives http://www.netobjectives.com/blogs/real-differences-between-

kanban-and-Scrum. http OGC http://www.cabinetoffice.gov/ http Onion https://myAgilemind.wordpress.com/2011/10/28/what-does-the-

planning-onion-mean-to-you/ http Scrumallicance http://www.Scrumalliance.org/why-Scrum http Wiki https://nl.wikipedia.org/wiki/Agile-softwareontwikkeling#Agile-

methoden Table E-1, Websites.

Appendix F, Index 93

Appendix F, Index

A

acceptable · 82 Acceptable · 88 acceptance · 14

- criteria · 3, 6, 14, 16, 17, 38, 49, 51, 53, 54, 81, 87, 88

- environment · 61 - report · 81 - test · 18, 26, 33, 35, 38, 50, 51, 52,

54, 56, 57, 59, 75 - testing · 18

accountancy · 6 accounting statement · 6 accuracy · 6, 57, 72 adaptive application management · 62 adaptive change · 53 adaptive software development · 11 additive application management · 62 additive change · 53 administrative task · 20, 62 agile

- modeling · 11 - unified process · 11

Agile · XIII, 9, 11, 17, 18, 23, 36, 37, 42, 43, 46, 48, 50, 51, 52, 55, 56, 57, 59, 65, 69, 90 - application · 23 - approach · XV, 1, 3, 9, 18, 79 - concept · 1, 2 - definition · 9 - development approach · XV, 1, 2, 23 - development method · 7 - development process · XIII, XV, 1, 2, 5,

32 - framework · 12 - idea · 17 - iteraton · 11 - manifesto · 9, 11, 23, 37, 39 - method · 2, 11, 18 - mind-set · 1 - principle · 37, 38, 39 - service management process · XV, 65 - software · 9 - software development · 9 - statement · 6 - structure · XV - system development · XV, 1, 2, 3, 9,

10, 11, 64 - term · XV, 1 - testing · 26

ALM · 67, 68, 70, 71, 89 ALM organisation · 67, 68, 70 annual plan · 32 application

- architect · 42 - component · 50, 56, 57, 58, 70, 72, 73 - landscape · 41

- lifecycle management · 25, 33 - management · 1, 5, 32, 33, 34, 35, 36,

39, 46, 62, 72, 87 - Management · 32 - portfolio · 6, 25, 35, 69, 71 - sizing · 38

Application Lifecycle Management · See ALM

Application Services Library · See ASL appointment · 15, 62 architect · 2 architecture landscape · 35 architecture scenario · 35 architecture viewpoint · 29 arrangement · 5, 49, 50 ASL · 1, 3, 5, 17, 25, 33, 34, 35, 36, 87,

89 asset owner · 14, 17, 66 assignment · 16, 73, 74, 75 audience · 1 AUP · 11 authentication · 48, 49, 63 authorization · 48, 49, 53, 63 availability · 18, 38, 44, 46, 47, 48, 49, 50,

51, 60, 75, 82 availability management · 38, 50, 51 availability manager · 51 availability plan · 35

B

back office · 31, 34, 35, 39, 67, 68, 70, 71, 73, 74

backlog refinement session · 15 backup and recovery · 48 balanced scorecard · 87 baseline · 6, 14, 15, 25, 47, 49, 57, 58 behaviour · 15, 25, 50, 51, 63 best practice model · 5 BiSL · 1, 3, 5, 33, 34, 35, 36, 87, 89 black box · 21 black list · 60, 61 blueprint · XV, 31, 32, 71 branched · 62 bug · 14 build · 13, 25, 57, 58, 68, 70, 71 builder · 14 building · 19, 26, 33, 43, 47, 51, 53, 54,

55, 56, 57, 60, 67, 73, 74, 75 building block · 54, 56 bureaucracy · 69 business

- analyst · 2 - architect · 42 - case · 6, 7, 25, 43, 63 - information service · 40, 41 - landscape · 41 - language · 16


- process · XIII, 10, 20, 31, 41, 42, 52, 54, 57, 88

- process owner · 2 - relationship manager · 46

Business information Services Library · See BiSL

C

CAB · 17, 35, 68, 73, 74, 87, 89 Caluwé · 23, 31, 67, 70, 72 Caluwé colour · 23 Capability Maturity Model · See CMM capacity · 11, 38, 40, 44, 46, 47, 51, 52,

75, 82 capacity management · 38 capacity modelling · 38 capacity plan · 35 care application · 72, 73, 74, 75 category · 24 CCTA · 89 CCTA Risk Analysis and Management

Method · See CRAMM CEMLI · 57, 58, 59, 89 CEMLI release · 57, 59 Central Computer Telecommunications

Agency · See CCTA CFIA · 87, 89 chain · 2, 6, 7, 20, 26, 32, 34, 58, 60, 70,

71, 72, 73 chain level · 6 change · 1, 5, 10, 12, 16, 17, 18, 23, 29,

31, 32, 38, 39, 40, 43, 46, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 63, 65, 67, 69, 70, 72, 73, 74, 79, 82, 87 - authority · 53, 55, 67, 68 - calendar · 16, 17 - management · 7, 16, 17, 34, 35, 37,

38, 52, 53, 54, 55, 56, 71, 73, 74, 76, 83, 87

- management process · 53 - request · 6, 39, 73, 87 - strategy · 23

Change Advisory Board · See CAB CI · 38, 55, 56, 57, 58, 61, 75, 81, 89 CIA · 42, 48, 49, 89 classification · 26, 40 client · 2 CMDB · 25, 43, 55, 56, 61, 81, 89, 90 CMM · 5, 6, 26, 89 CMS · 25, 89 code review · 14 collaboration · XIII, 3, 7, 9, 16, 35, 46, 51,

55, 59, 67, 74, 75 co-locate · 11 communication · 11, 38, 46, 73 company policy · 6 competence · 21, 24 competitor · 24 complaint · 35, 39 completeness · 6, 72 compliance · 6, 43, 49

compliment · 35, 39 component · 15, 50, 52, 55, 88 Component Failure Impact Analysis · See

CFIA concurrent user · 52 Confidentiality, Integrity and Availability ·

See CIA Confidentiality, Integrity, and Accessibility ·

See CIA Configuration Item · See CI, See CI configuration management · 25, 33, 34,

38, 52, 55, 56 Configuration Management DataBase · See

CMDB Configuration Management System · See

CMS Configuration, Extension, Modification,

Localisation, Integration · See CEMLI, See CEMLI

contingency factor · 10 Continual Service Improvement · See CSI continuity · 38, 44, 46, 47, 57 continuity management for IT services · 38 continuity plan · 35 continuous

- delivery · 9, 10, 11, 25, 37 - deployment · 7, 23, 24, 25, 37, 38, 39,

47, 48, 55, 56, 57, 58, 59, 62, 72, 75, 76, 80, 82

- flow · 10 - integration · 7, 11, 23, 24, 25, 37, 38,

39, 47, 48, 55, 56, 57, 59, 62, 72, 76, 80, 82

- service monitoring · 45 continuous delivery · 10 contract · 9, 35 control a flow · 18 control quality · 6 core service · 42, 43 corrective application management · 62 corrective change · 53 correctness · 6 countermeasure · XV, 1, 5, 37, 46, 47, 48,

49, 52, 54, 55, 56, 57, 87 craftsmanship · 10 CRAMM · 38, 87, 89 CRAMM-analysis · 87 CRC · 48, 89 critical success factor · 87 Crystal Clear · 11 CSI · 16, 89 customer · XIII, XV, 1, 7, 10, 14, 15, 20,

24, 25, 27, 28, 29, 34, 42, 44, 45, 53, 60, 63, 65, 66, 75, 79, 83, 87, 88

customer satisfaction · 9, 10, 83 Customer satisfaction · 10, 37 Cyclic Redundancy Check · See CRC

D

DAP · 44, 45, 89 data model · 29, 57, 58, 59


data storage · 49 database · 29, 52, 58 De Leeuw · 10 defect · 12, 14, 16, 39, 46, 56 Definition of Done · See DoD Definitive Media Library · See DML delegated asset owner · 14 demand / supply fulfilment · 51 demand / supply statement · 49 demand control · 42 demand determination · 42 demand management · 40, 42, 43, 52 demarcation · 2, 32, 51, 52 Deming · 11 deployment pipeline · 25 deployment process · 57 deployment team · 34, 35, 40 design · XV, 3, 9, 10, 11, 13, 16, 18, 23,

26, 35, 37, 38, 44, 50, 55, 60, 64, 67, 68, 70, 71, 73, 74, 75, 79, 82

design criteria · 75 designer · 2, 14 designing · 19, 36, 50, 74 Development , Test-, Acceptance- and

Production environment · See DTAP Development & Operations · See DevOps development organisation · 26, 27, 31, 67,

69 development process · XIII, XV, 1, 2, 3, 5,

6, 7, 10, 11, 12, 13, 14, 17, 18, 19, 20, 23, 24, 25, 26, 27, 28, 29, 31, 32, 33, 34, 39, 44, 56, 57, 72, 79, 80, 82

development team · 12, 13, 14, 15, 16, 17, 18, 21, 25, 26, 31, 33, 34, 35, 39, 40, 47, 49, 50, 51, 53, 54, 62, 63, 67, 72, 74, 75

DevOps · 2, 21, 24, 40, 89 disadvantage · 40, 47 disruption · 14, 60 DML · 25, 89 DoD · 14, 16, 40, 42, 43, 45, 47, 48, 49,

51, 52, 54, 55, 56, 57, 59, 60, 61, 62, 63, 64, 81, 82, 89

DoD entry · 43, 47, 48, 49, 51, 52, 55, 56, 57, 59, 61, 62, 63, 64

Dossier Agreements and Procedures · See DAP

downstream phase · 20 DSDM · 5, 11, 89 DTAP · 89 DTAP environment · 58 DTAP street · 25, 62, 65, 81 Dynamic Systems Development Method ·

See DSDM

E

effective · XV, 3, 6, 10, 18, 41 effectiveness · 1, 5, 9, 10, 27, 63, 69 efficiency · 1, 5, 9, 10, 11, 27, 69 efficient · XV, 6, 11, 18, 41, 42 Electronic Patient Dossier · See EPD

end user · 14 end user support · 33 environment · 16, 26, 40, 55, 58, 59, 60,

63, 74, 75, 88 environmental management · 40 EPD · 72, 89 epic · 14, 15, 16, 82 estimate · 11, 16, 17, 24 ETL · 58, 89 event catalogue · 14, 60, 61 event management · 35, 59, 60, 61 Event management · 60, 74 EVO · 11, 89 evolutionary · 1, 66, 67 evolutionary project management · 11 Evolutionary Project Management · 89 exception · 49, 60, 62, 74 exception management · 60 expertise · 20, 21, 40, 53, 60 external employee · 72 external integration · 28 External integration · 82 Extract Transform Load · see ETL eXtreme Programming · See XP

F

Fast · 10 FAT · 14, 81, 89 Fault Tree Analysis · See FTA feature · 7, 10, 12, 14, 15, 16, 17, 18, 24,

25, 28, 34, 37, 39, 40, 43, 44, 47, 49, 51, 52, 53, 54, 55, 68, 71, 72, 74, 79, 80, 81, 82

feature driven development · 11 feature request · 7, 12, 34, 35, 39, 40, 51,

52, 68, 71, 80, 81, 82 FiFo · 89 FiFo principle · 54 financial information system · 54 financial management for IT services · 43 First in First out · See FiFo focus · 32 framework · 2, 9, 23, 26, 27, 33, 74, 87 front office · 31, 34, 35, 39, 67, 68, 70,

71, 72, 73, 74, 75 FTA · 89 FTE · 68 Functional Acceptance Test · See FAT

G

generic acceptance criteria · 87 generic service team · 70, 71 generic tool architecture · 47, 48 governance · 6, 17, 34, 35, 36, 53, 54, 55,

56, 58 grooming · 15


H

health model · 60, 61 heterogeneous feature · 83 housekeeping · 40 human resource management · 15

I

ICT · 89 ILM · 67, 68, 69, 70, 89 ILM organisation · 67, 69, 70 impact analysis · 17, 29, 34, 35, 37, 38,

44, 47, 51, 54, 55, 56, 59, 61, 71, 74, 76, 81, 83

impede · 21 impediment · 14 inadequate capacity · 15 incident · 6, 7, 12, 14, 16, 33, 34, 35, 39,

40, 43, 45, 46, 53, 54, 57, 60, 61, 62, 63, 64, 65, 68, 69, 71, 74, 76

Incident · 61, 63 incident management · 7, 59, 63 incident resolution · 35 information · 33

- architect · 42 - availability · 48 - confidentiality · 48, 49 - integrity · 48, 49 - landscape · 41 - management · 1, 5, 32, 33, 34, 35, 45,

46, 70, 87 - manager · 2 - planning · 35 - security management · 48, 49 - system · XV, 1, 2, 3, 5, 6, 7, 10, 11,

14, 26, 29, 31, 34, 35, 39, 40, 41, 42, 43, 44, 48, 49, 50, 51, 52, 54, 59, 79, 87

- system development · 5 Information & Communication Technology ·

see ICT Information Technology · see IT Information Technology Infrastructure

Library · See ITIL infrastructure · 35

- architect · 41 - facility · 51 - landscape · 41 - management · 1, 2, 5, 32, 33, 49, 61,

72 Infrastructure Lifecycle Management · See

ILM innovation · XV, 2, 5, 19, 32, 33, 36, 37,

47, 49, 51, 52, 54, 87 integration test · 26 internal spec sheet · 44, 45, 46, 51 IT · 89 IT auditor · 2

ITIL · 1, 2, 3, 5, 16, 17, 25, 26, 33, 34, 35, 36, 39, 40, 41, 42, 44, 52, 53, 67, 69, 70, 71, 74, 75, 87, 89

ITIL process · 70

K

Kanban · XV, 1, 2, 3, 5, 9, 11, 18, 19, 20, 21

Kanban board · 19, 20 knowledge · XV, 1, 14, 20, 21, 31, 38, 39,

40, 47, 48, 53, 60, 62, 63, 65, 71, 76 known error · 61

L

late change · 9 Late change · 10 LCM · 57, 58, 59, 89 LCM release · 57, 58, 59 lean software development · 11 lesson learned approach · 18 lessons learned · 17 LifeCycle Management · See LCM line manager · 2, 33, 62, 75 line organisation · 15

M

maintainable · 15, 50, 51 major change · XV, 6, 16, 37, 43, 44, 47,

53, 54, 55, 57, 72 manageable · 7, 21, 26, 43, 61 manifesto · 39 master product backlog · 35 mature · 3, 6 maturity · 1, 5, 6, 24, 26, 27, 28, 29, 60,

66, 79, 82 maturity level · 79 measurable · 82 Measurable · 88, 90 metadata · XV, 2, 5, 6, 7 migration path · 41 migration paths · 42 minor change · 16, 54, 55 mission · 39, 41 monitor architecture · 50 monitor function · 50 monitor provision · 50, 60, 61 monitoring · 28, 39, 40, 45, 47, 59, 60, 61,

62, 71, 72, 74, 80 monolithic software · 11 motivation · 10 multi disciplinary team · 12 multi tenancy application · 70, 72 multi tenancy solution · 34


N

NFR · 89 Non Functional Requirement · See NFR non-functional requirement · 6, 43, 44, 45,

46, 48, 49, 51, 52, 55, 66, 74

O

OGC · 26, 27, 89 OLA · 44, 45, 46, 89 one-time production order · 63 Operational Level Agreement · See OLA operational management · 21, 33, 40 organisation model · 67 Organisation model · 70, 73 organisation strategy · 41

P

panic purchase · 51 patchwork · 41 patterns of business activity · 42, 52 PBI · 12, 14, 15, 16, 89 peer review · 75 perfect application management · 62 perfective change · 53 performance · 16, 25, 27, 44, 52, 60, 82,

87 performance indicator · 16 Performance indicator · 87 Performance StressTest · See PST PID · 69, 89 pitfall · 5 planning · 15, 17, 18, 19, 24, 25, 32, 33,

35, 37, 40, 42, 47, 49, 51, 52, 69, 74 planning and control · 33 policy · 20, 21, 27, 47, 48, 49, 67, 73 policy statement · 27 portfolio management · 33, 40, 41, 42 potential shippable product · 14, 33 precondition · 27 preventive application management · 62 preventive change · 53 PRINCE2 · 5, 6, 17, 67, 69, 70, 74, 90 principle · XIII, 9, 11, 14, 15, 18, 23, 26,

37, 39, 48, 51, 62, 66 priority · 12, 15, 16, 17, 24, 40, 53, 62,

65, 72 problem management · 59, 63, 64 problem statement · 72 procedure · 7, 25, 26, 40, 57, 58, 62 process · XIII, XV, 2, 3, 5, 6, 9, 10, 12, 14,

16, 18, 19, 20, 21, 23, 25, 26, 27, 28, 29, 31, 32, 33, 35, 37, 38, 42, 45, 46, 49, 53, 54, 57, 58, 59, 61, 62, 63, 64, 65, 66, 67, 73, 75, 83, 87, 88

process improvement plan · 29 process manager · 6, 62 process owner · 6

product - backlog · 12, 14, 15, 16, 20, 32, 35,

42, 54, 69, 72, 74, 80 - ower · 46 - owner · 2, 12, 13, 14, 15, 17, 20, 21,

23, 24, 28, 32, 33, 34, 35, 38, 39, 40, 42, 45, 46, 48, 49, 51, 52, 53, 54, 62, 63, 68, 69, 71, 72, 74, 75, 79, 80, 82

- portfolio · 41, 43, 47, 67, 68, 71, 73 - roadmap · 24, 25, 32, 33, 34, 35, 40,

41, 42, 43, 46, 47, 49, 51, 52, 54, 74, 75

Product Backlog Item · 14, See PBI production

- assignment · 35 - control system · 20 - environment · 63 - process · 21

profile · 24, 52 programme manager · 2 programmer · 2 project · 14

- approach · 6, 17, 72 - management · 17 - manager · 6, 15, 32 - team · 15

Project Initiation Document · See PID PRojects IN Controlled Environment · See

PRINCE2 promote · 3, 63 promotion to production · 33 PST · 90 pull · 20 push · 20 push-system · 20

Q

quality - aspect · 14 - assurance · 45, 46 - control · 14, 34 - level · 6 - requirement · 15

quarterly plan · 32 question · XIII, XVI, 3, 26, 28, 35, 39, 54,

73, 79, 80, 81, 82, 83 questionnaire · 27, 28, 29

R

RACI · 88, 90 railway · 33, 42 railway crossings · 33 RASCI · 90 recovery cost · 51 refactoring · 43, 51, 52, 75 refining · 15, 17 regression testing · 7, 23, 24, 26, 47, 48,

57, 62, 80, 81 release


- and deployment management · 37, 38, 52, 57, 58, 59, 75

- goal · 25 - management · 25, 33 - plan · 25, 44, 74 - planning · 25, 35 - schedule · 49

reliability · 10, 80 reliable · 10 repeatable · 5 Repeatable · 26 repeatable process · 6 report · 7, 59 request · 14, 28, 39, 63, 68, 72, 79, 82 Request for Change · See RFC Request For Change · See RFC request fulfilment management · 63 requirement · XIII, XV, 3, 6, 9, 10, 12, 15,

16, 26, 29, 31, 33, 35, 37, 38, 39, 40, 42, 43, 46, 47, 48, 49, 51, 53, 55, 56, 57, 64, 65, 66, 69, 81, 87, 88

requirement analyst · 14 requirement based process design · XIII,

XV, 3 resource plan · 35 Responsible Accountable Consulted

Supportive Informed · See RASCI, See RACI

retrospective · 20, 23, 61, 80 return on investment · XV, 2, 7 Return On Investment · See ROI Return Point Objective · See RPO Return Time Objective · See RTO review · 88 revolutionary · 1, 66 RFC · 17, 65, 88, 90 risk

- analysis · 29, 34, 53, 54, 57, 59, 71, 75 - area · 6, 7 - control · XV, 2, 45, 47, 48, 50, 53, 55,

56, 58, 60, 61, 63 - management · XIII, 5, 6, 35, 37, 46,

52, 54, 55, 56 Risk

- control · 37, 53 Risk control · 54 ROI · 43, 90 role based access · 49 rolling out · 25 root cause analysis · 35, 63, 64 Route to Value · 24, 25, 32, 42, 44, See

RtV RPO · 48, 90 RTO · 48, 90 RtV · 23, 24, 32, 33, 34, 35, 90 rule · 11, 18, 20, 31, 59

S

SaaS · 29, 90 SAFe · 26, 33, 36, 90 Scaled Agile Framework · See SAFe

scheduling jobs · 40 S-CI · 6 Scrum · XV, 2, 5, 6, 7, 11, 12, 16, 17, 18,

26, 27, 28, 29, 31, 32, 37, 41, 56, 57, 58, 59, 61, 62, 63, 67, 68, 69, 70, 71, 72, 73, 74, 75, 79, 80, 81, 82, 83 - approach · 3, 6, 11, 12, 14, 18, 20, 35,

36, 37, 44, 54, 69 - development process · 2, 10, 11, 12,

26, 32 - master · 2, 12, 13, 15, 17, 20, 47, 68,

71, 74, 80 - Master · 17, 62 - model · 21 - of Scrums · 26, 34 - process · 11, 12, 14, 15, 24, 28, 38,

79, 80 - rolling · 34 - team · 6, 7, 13, 14, 15, 16, 17, 23, 25,

26, 29, 31, 33, 34, 37, 39, 40, 41, 45, 46, 47, 48, 49, 51, 52, 55, 56, 57, 58, 59, 60, 61, 62, 63, 65, 67, 68, 69, 70, 71, 72, 74, 75, 76, 79, 81, 82, 83

- terminology · 27 Scrumban · 9 security · 6, 44, 46, 47, 48, 49, 51, 57, 65

- baseline · 49 - event · 49 - manager · 48, 49 - plan · 35, 49

self - assessment · 79 - contained · 46 - made · 58 - management · 31 - managing · 31 - supporting · 39

senior management · 1, 70 service

- agreement · 5, 45 - catalogue · 41 - desk · 28, 34, 35, 37, 39, 40, 60, 62,

63, 65, 67, 68, 69, 71, 73, 74, 79 - level management · 6, 37, 44, 45, 46,

47, 49, 51, 75, 76 - level manager · 45, 46, 47, 48, 49, 74,

82 - management · XIII, XV, 1, 2, 3, 5, 6, 7,

14, 16, 17, 21, 23, 25, 26, 31, 32, 35, 36, 37, 38, 39, 40, 42, 44, 45, 51, 54, 55, 56, 60, 64, 65, 66, 67, 69, 73, 74, 75, 76, 87

- management architecture framework · 2

- management model · XV - management organisation · XV, 1, 5, 6,

16, 31, 32, 37, 44, 45, 51, 54, 55, 67, 69, 73, 75, 87

- management process · XIII, XV, 1, 2, 3, 5, 7, 26, 37, 38, 39, 64, 65, 66, 69, 87

- manager · 71, 72 - organisation · 6


- pipeline · 41 - portfolio · 40, 41, 42, 43 - portfolio pipeline · 42 - provision · 48, 50, 53 - reference manual · 75 - request · 63 - request management · 59 - strategy · 25 - team · 40, 69, 73, 74, 75

Service Improvement Programme · See SIP Service Knowledge Management System ·

See SKMS Service Level Agreement · See SLA Service Quality Plan · See SQP significant change · 16, 55, 60 Single Point of Contact · See SPoC Single Point of Failure · See SPOF SIP · 44, 90 skills · 31, 46, 51, 62 SKMS · 25, 90 SLA · XIII, 1, 6, 35, 36, 37, 44, 45, 46, 47,

49, 51, 52, 57, 62, 66, 69, 71, 74, 75, 88, 90

SLA norm · 1, 6, 37, 44, 45, 46, 47, 52, 62, 66, 75

SMART · 82, 88, 90 software · 1, 6, 7, 9, 10, 11, 13, 14, 15,

26, 31, 37, 38, 40, 41, 42, 43, 46, 47, 49, 51, 52, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 68, 69, 70, 71, 74, 75 - asset & configuration management · 7 - configuration item · 6, 47 - configuration management · 25 - development · 1, 9, 11, 26 - release · 6

Software as a Service · See SaaS Software Configuration Management

DataBase · See S-CMDB source code scan tool · 43 Specific · 82, 88, 90 specify information requirement · 34 SPoC · 90 SPoF · 38, 50, 51, 88, 90 sprint · 10, 11, 12, 14, 15, 16, 17, 18, 20,

23, 25, 26, 32, 33, 37, 39, 40, 42, 43, 44, 45, 46, 47, 49, 51, 54, 55, 56, 57, 60, 62, 63, 69, 74, 75, 80 - backlog · 12, 15, 17, 35, 74 - burndown chart · 12, 15 - retrospective · 12 - retrospective meeting · 17 - review · 12

SQL · 52, 90 SQP · 29, 66, 90 stakeholder · 13, 15, 18, 33, 45, 53, 54,

65, 81 standard change · 16, 63 standardizing · 5, 7 standards and guideline · 49, 50, 51, 62,

75 steering group member · 2 story · 16, 19, 25, 28, 46, 55, 56, 57, 69,

72, 74, 79, 82

story point · 15, 16, 80 strategic layer · 32 strategic level · 32 Structured Query Language · See SQL supplier · 1, 15, 45, 47, 50 supplier management · 47, 48, 75 support team · 35 system development · XV, 1, 2, 5, 9, 11,

12, 17, 18, 20, 39

T

target architecture · 40, 41, 42 task separation · 48 TDD · 90 technical

- architect · 42 - excellence · 9, 10 - management · 32 - service · 41

test · 6, 13, 24, 26, 27, 47, 49, 54, 55, 56, 57, 58, 59, 75, 81, 88

test case · 6, 26, 47, 55, 56, 57, 81, 88 Test Driven Development · See TDD test scenario · 88 tester · 2, 14 testing · 14, 18, 19, 23, 24, 25, 26, 33, 35,

38, 50, 52, 55, 56, 57, 68, 71, 74, 75 theme · 16, 72 time box · 12, 15, 39, 40, 54, 69 timeliness · 6, 72 time-to-market · 7, 10, 31, 41, 42, 43, 45,

55, 57, 59 Time-to-market · 46 tool · XIII, 7, 9, 16, 38, 47, 48, 50, 51, 56,

57, 58, 59, 68, 75, 82 tooling · 1, 5, 14, 15, 47, 48, 55, 56, 59,

76 tooling architecture · 47 traceability · 55, 56, 57, 59 trend analysis · 63

U

UAT · 90 UC · 44, 46, 90 UK Office of Government Commerce · See

OGC uncontrollable cost · 43 Uncontrollable cost · 43 Underpinning Contract · see UC unit test · 14 User Acceptance Test · See UAT user organisation · 1, 10, 11, 31, 32, 33,

39, 42, 45, 57, 70, 73, 88 User organisation · 33 user story · 14, 16, 17, 21, 46, 54, 81


V

value stream · 20 Value Stream Mapping · See VSM velocity · 16, 17, 33, 82 verification · 28 version management · 25, 56, 57, 58, 62,

75 version management library · 25 version management tool · 56, 58 vision · XIII, 24, 25, 32, 33, 34, 35, 40, 41 vision statement · 25, 35 visualization · 19 V-model · 24 VSM · 20, 90

W

waste · 1, 2, 3, 11, 37, 54, 61, 64, 65, 66

white list · 61 WIP · 18, 19, 20, 37, 45, 46, 90 WIP limit · 20, 21 Work In Progress · See WIP work package · 17 work stock · 12, 53 workaround · 62, 63 workflow · 7, 18, 21 working software · 9 workload · 63 workload & scheduling · 35, 40 workmanship · 10 workplace · 67

X

XP · 11, 90

About the author 101

About the author

Bart has been active in ICT since 1985. He worked primarily with the top 100 of Dutch business and government organisations. He has acquired experience in different roles within all aspects of system development, including operations for 12 years. After that, he focused on the subject of service management. Currently, as a consultant, he is active in all aspects of the knowledge management cycle of service management, such as training ICT managers and service managers, advising service management organisations, improving service management processes and outsourcing (parts of) service management organisations. He graduated at both the HTS and University level in the management field.

Other books by this author 103

Other books by this author

DevOps Best Practices Best Practices for DevOps In recent years, many organisations have experienced the benefits of using Agile approaches such as Scrum and Kanban. The software is delivered faster whilst quality increases and costs decrease. The fact that many organisations that applied the Agile approach did not take into account the traditional service management techniques, in terms of information management, application management and infrastructure management, is a major disadvantage. The solution to this problem has been found in the Dev (Development) Ops (Operations) approach. Both worlds are merged into one team, thus sharing the knowledge and skills. This book is about sharing knowledge on how DevOps teams work together. For each aspect of the DevOps process best practices are given in

30 separate articles. The covered aspects are: Plan, Code, Build, Test, Release, Deploy, Operate and Monitor. Each article starts with the definition of the specifically used terms and one or more concepts. The body of each article is kept simple, short and easy to read.

Author Publisher ISBN

: Bart de Best : Leonon Media, 2017 : 978 94 92618 078

Cloud SLA The best practices of cloud service level agreements More and more organisations choose to replace traditional ICT services by cloud services. Setting up effective SLAs for traditional ICT services ia a real challenge for many organisations. With the arrival of cloud services, this seems to be much simpler at first, but soon the hard questions come up like data ownership, information links and security. This book describes what cloud services are. The risks involved in entering into contracts and SLAs are discussed. Based on a long list of risks and countermeasures, this book also provides recommendations for the design and content of the various service level management documents for cloud services.

This book first defines cloud and then describes various aspects like cloud patterns and the role of a cloud broker. The core of the book is the discussion of contract aspects, service documents, service design, risks, SLAs and cloud governance. In order to allow readers to get started with Cloud SLAs, the book also includes checklists of the following documents: Underpinning Contract (UC), Service Level Agreement (SLA), Document Financial Agreements (DFA), Document Agreement and Procedures (DAP), External Spec Sheets (ESS) and Internal Spec Sheets (ISS).




SLA Templates A complete set of SLA templates The most important thing in providing a service Is that the customer is satisfied with the delivered performance. With this satisfaction, the supplier gets re-purchasing’s, promotions in the market and is the continuity of the company ensured. Perhaps the most important aspect of this customer satisfaction for a supplier is that the employees in question get a drive to further develop their own knowledge and skills to satisfy even more customers. This book describes the templates for Service Level Agreements in order to agree with the customer on the required service levels. This book gives both a template and an explanation for this template for all common service level management documents.

The following templates are included in this book: • Service Level Agreement (SLA) • Underpinning Contract (UC) • Operational Level Agreement (OLA) • Document Agreement and Procedures (DAP) • Document Financial Agreements (DFA)

• Service Catalogue • External Spec Sheet (ESS) • Internal Spec Sheet (ISS) • Service Quality Plan (SQP) • Service Improvement Program (SQP)



Agile Service Management with Scrum€¦ · Agile Service Management with Scrum On the way to a healthy balance between the dynamics of developing and the stability of managing the

Documents