Two-Speed Transition: Tradition & Innovation

Two-Speed Transition:

Tradition & Innovation

itSMF UK Service Transition SIG23 November 2015

@ITSMFUKTransMgt #twospeed

Two speed transition

• two approaches

• three topics

• five minutes per slot

• six speakers

@itammartin #twospeed

Join the conversation

• #twospeed

• follow the SIG - @ITSMFUKTransMgt

@itammartin #twospeed

Round 1:

Release Management

#twospeed

Release - the traditional approach

Sue Cater

Principal Service Acceptance Manager

Atos

[email protected] #twospeed

Eight Steps1. Develop Release Management Policy and Strategy

2. Release Specific Initiation and Planning

3. Design, Develop, Build and Configure the Release

4. Hardware, Software, License Acquisition

5. Execute Release Plan

6. Release Acceptance – Final Operational Readiness Test

7. Deploy Release

8. Post-Implementation Review / Lessons Learned


Five Stages


Stage 1 - Plan

Plan

1. Develop Release Management Policy and Strategy

2. Release-Specific Initiation and Planning:

3. Release planning meeting

4. Review Test plan

5. Develop communications plan

6. Develop plan for this release


Stage 2 - Build

Build

1. Design, Develop, Build and Configure the Release

2. Hardware, Software, License Acquisition:

3. Develop Release Candidate – identify affected CIs

4. Retrieve baseline from SKMS

5. Execute Release Plan:

6. Release Validation - Review test plan including business and use test cases

7. Build and Configure Release Candidates

8. Technical Testing of release candidates individually and together


Stage 3 - Accept

Accept

1. Release Acceptance – Final Operational Readiness Test:

2. ORT and UAT

3. Review SLAs to understand any impact on agreed service levels - manage

issues through with SLM

4. Ensure ITSC and BC plans have been updated/completed

5. Review Training Plan - ensure that all support team readiness activities are

either completed or on target to complete prior to termination of ELS

6. Ensure all support team communications are on track and that build team

understand the extent of their ELS commitment


Stage 4 – Deploy

Deploy

1. Deploy Release:

2. Confirm all change approvals received

3. Review Communication plan and execute

4. Deploy release

5. Create request to update CMDB

6. Post Release validation

7. Notify Change Management

8. Invoke ELS and Transition to Operations


Stage 5 - Review

Review

1. Post-Implementation Review / Lessons Learned:

2. Complete Release Record

3. Hold PIR – joint with client and other suppliers?

4. Capture Lessons learned

5. All completed documentation collected and associated to

Release close process

6. Release template updated as needed for future Releases


Release - the agile approach

Matt Hoey

Change and Service Quality Manager

Grant Thornton UK LLP

@MattDHoey #twospeed

Being agile


Being agile in Release Management


Agile release management• speed to market

• fail fast

• flexibility

• the right product


Release Management1. Which of these do you feel is the most problematic?

2. Which of these would you be biased towards if there wasn't an easy

choice?

3. Which do you think works better for collaboration?

4. Which do you think is better for stability?

5. Which do you think is better for responsiveness?

#twospeed

Round 2:

Service Catalogue

Driven Transition

#twospeed

Catalogue - the traditional approach

Vawns Murphy

Change Specialist

@vawns #twospeed

The problem

*referencing http://www.itskeptic.org/dead-cat-syndrome

Help Desk Calls

Emails

?Web Forms

Application

Projects

Enhancements

Hosting

Infrastructure

Server

Storage

Network

Other

Workplace

Desktop

Messaging

Access

Telecom

End User

On-Board a New Employee, Request System Access, Change a Report

Business Executive

Manage IT Budgets & Costs, Track Service Quality

IT Customer Perception

How can we tell if what we are spending on IT is reasonable?

No transparency into IT spend and value of services provided

Why does it take so long for a simple request?

IT is difficult to work with, service quality not consistent

IT Challenges

Little ability to influence consumption, no cost visibility

Poorly-defined services, no standardization, limited control

Ad-hoc service delivery, each request treated as a one-off

Lack of coordination between technology silos within IT

Conflicting Processes

Disconnect Between IT and Internal Customers

@vawns #twospeed

• Who do you support?

• When do you provide support?

• How do you provide support?

• What do you support?

Common service assumptions…Everyone!

…Always!

…The customer’s way!

…Everything!

@vawns #twospeed

• Know your audience (requirements, business perspective, technical views)

• Link to the Service Portfolio

• Align with business priorities

• Frame the discussion for planning

• Know your supporting players

• It’s good to talk

• Use it or lose it!

Sorting it out

@vawns #twospeed

Service Catalogue & customer engagement

@vawns #twospeed

• Self Service

• Entitlement-based view

• Browse, search, order services

• Check real-time status online

• Order-on-behalf, email approvals

• One Point of Contact

• Service requests, requests for change, incidents, information requests – IT and beyond IT

• Application enhancements, project requests, non-standard services, business services

• Pre-defined Content

• Componentisation and reusability

• Provisioning Connection

• Servers

• Desktop

• Access

Service Request Catalogue

@vawns #twospeed

• Measure and reward Service Catalogue use

• Discourage Service Catalogue by-pass

• Most important for the Service Catalogue owner/manager:

• The Service Catalogue must be the most credible source of service information. Any errors found by users or testing must be corrected quickly

• The Service Catalogue must present what Customers and Users need and in their terminology

• The Service Catalogue must be simple and easy to use

• The Service Catalogue must include the most sought after information

Use it or lose it!

@vawns #twospeed

Just rememberIf all else

fails …

trust

yourself!

@vawns #twospeed

What does good look like?

Some real world examples

Release times reduced

Changes deployed out side the process decreased by 95%

10% reduction in issues found during DR tests

DR in sync with production

@vawns #twospeed

Catalogue - the agile approach

Patrick Bolger

Chief Evangelist

Hornbill Service Management

@patb0512 #twospeed

Issues with traditional approach

@patb0512 #twospeed

Traditional vs Agile Approach

@patb0512 #twospeed

Agile Value Proposition

@patb0512 #twospeed

Themes, Epics & StoriesProject

Launch new Service Request

Catalog

Themes

Incident Management

Service Request Catalog

SLA Reporting

Epics

Enable single sign on access

Users can view/manage callsAs (who), I want (what), so

that (why)…

Stories

Tasks

@patb0512 #twospeed

ITSM meets AgileITSM Product Backlog

Request Fulfilment Incident ManagementProblem

Management

Epic Epic Epic

User

Story 1

User

Story 2

User

Story 3

User

Story 1

User

Story 2

User

Story 3

User

Story 1

User

Story 2

User

Story 3

Story Story Story Story Story Story Story Story Story

Sprint 1 Sprint 2 Sprint 3

ITSM Sprint Backlog

@patb0512 #twospeed

Scrum

@patb0512 #twospeed

• Identify service need (new, change, improve)

• Start with something manageable and achievable

• Break down need (themes, epics and user stories)

• Self-organising team works out the ‘how’

• Use t-shirt sizing to estimate effort

• Set simple goals

• Run a short sprint (fixed time)

• Review sprint and plan next iteration

• Continuous improvement optimizes agility

Get going with agile

@patb0512 #twospeed

Service Catalogue1. Which of these do you feel is the most problematic?


choice?




#twospeed

Round 3:

Early Life Support

#twospeed

ELS - the traditional approach

Peter Mills

Principal Service Architect

Arqiva

Peter Mills #twospeed

• Design coordination

• Service design pack

• Training

• Transition planning and support

• Testing

• Handover documentation

• Specifically impact of operational processes

• Communication plan

• ELS agreement

ELS – how to avoid the dead cats!*

*referencing http://www.itskeptic.org/dead-cat-syndrome


• People

• Project Manager BRM

• Project Team Resolver Group

• Service Architect Service Desk

• Users/Customer BRM

• Process

• Communication

• How long will ELS last?

• Because SLAs will be reduced/suspended

• What are the exit criteria?

ELS – how to avoid the dead cats!


ELS - the agile approach

Jon Morley

Service Transition Manager

The University of Nottingham

@JonMorleyITSM #twospeed

Innovating ELS - approach• Define and agree your requirements and acceptance criteria for ELS like any another non-functional requirement

upfront -

• This is regardless of whether or not this is part of Agile Sprints or traditional requirements gathering activities

• Requirements and criteria should involve identifying

• Length of the time boxed warranty period

• Where it needs to be located e.g. onsite

• Any special requirements e.g. floor walking

• Identify your stakeholders – project and support teams, suppliers, partners, senior managers and customers – and

get their input into the requirements


Innovating ELS – tools & methods• Have a Kanban board or similar to show the work in progress

• Agree the “rules” of the board with your team e.g. the amount of columns, prioritisation,

significance of issues, how to deal with blockers and so on

• You should continue to use existing tools for logging calls e.g. via your ITSM tool –

otherwise your board and team can get bogged down / duplicate effort

• Develop and follow an appropriate high level stakeholder plan to compliment lower

level implementation and back out plans


Innovating ELS – people & collaboration

• Walk your stakeholders – particularly Senior Managers and

Customers through the plan and agree the communication

checkpoints e.g. daily / weekly reports

• Have representatives add cards to the Kanban board in

accordance with the agreed ‘rules’.

• Ensure people do not circumvent the existing ticket logging /

incident process.

• Undertake regular (ideally daily) stand ups for a maximum of 15

minutes with the right people e.g. project team, support and the

customer together.

• Facilitate resolution of any issues requiring deeper investigation

outside of the stand up


Early Life Support1. Which of these do you feel is the most problematic?


choice?




#twospeed

Continue the debate

• follow the SIG - @ITSMFUKTransMgt

• join the SIG's LinkedIn group

• join the Service Transition SIG

#twospeed

#twospeed

Two-Speed Transition: Tradition & Innovation

Documents