3. IT Service Provision Learning Services
Provision
Training Service
Provision
IT Change
IT Transition
IT Support
Develop
Support
Manage
Certification Training
Tailored Training
Managed Training Services (Local)
SureSkills - Who We Are
Consulting &
Solutions
Learning
Services
Training
& Certification
9. Traditional ITSM facts and fiction
• ITIL is process based
• ITIL is heavy influenced by infrastructure, hence the name
• ITIL works best for traditional IT that have a more waterfall approach to
ITSM
• You don’t need ITSM if you have your services in the cloud.
10. PUBLIC
PUBLIC
How did we end up with these views?
• The core ITIL books consist of a lot about process
However it also talks about people and culture
• It talks about outcomes not outputs but shows outputs for each process
Adopt and adapt is talked about a lot but we have relied on consultants &
trainers to provide guidance to the enterprise
• Change is rigid and controlled and heavily based on the CAB
This is an often quoted misconception
11. PUBLIC
PUBLIC
What has ITIL to offer to digital
transformation?
• ITIL is non prescriptive
• It is flexible
• It is based on outcomes not outputs
• By using your risk appetite and technology enablers you can adopt and adapt ITIL to
your organization
• New guidance has been released The ITIL practitioner
16. PUBLIC
PUBLIC
What are Axelos top tips?
1. Always remember that YOU are accountable for YOUR service.
2. Outcomes are what matters not outputs, define what you want and measure them.
3. Communication is vital.
4. Create an organizational culture around service management.
5. Ensure that measures are MEANINGFUL and contribute towards outcomes.
6. Work in small steps ensuring that the changes are embedded.
7. Understand your needs and partner with your service provider if possible.
52. • Agile support is the continuation of the core agile principles that have been followed
within the delivery phase after a service has gone live…
• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan
• Support Team Structure
• Developers
• WebOps
• Analysts / Architects
• Scrum Master
• Security
• UX
Agile Support
What is Agile Support?
53. • Essentially both are Agile methodologies but Kanban work would be
ongoing and not broken into individual sprints.
• Scrum approach isn’t suited to Support as emergency incidents
received would disrupt a running sprint.
• Kanban very customisable. Every instance of it will be completely
different (eg. Different workflow, limits, etc.) therefore easily
adaptable to teams / projects / customers.
Kanban v Scrum
What’s the difference?
54. A method for managing knowledge work with an
emphasis on just-in-time delivery while not
overloading the team members.
Key components are a recognised workflow, a
mechanism to visualise it and metrics to measure
effectiveness.
Work limits are key where certain states or members
cannot be overloaded (ie. Work-in-progress limits)
What is Kanban?
Kanban
55. • If you try to do more things at the same time, you will take longer to complete them all
• Better to focus on highest priority/quickest win items to ensure continuous progress
• Work In Progress (WIP) limits restrict the volume of tasks engineers are allocated creating focus
How does Kanban help?
Kanban helps focus and prioritise
56. • Agile delivery doesn’t stop with Go-Live
• Clients require a continuation of Agile delivery throughout project lifecycle
• Once Support take over there’s still a requirement for continuous
improvement
• Kanban is the best fit as engineers handle multiple incidents across
multiple projects continuously
• Greater chance of continued business as uninterrupted service
management following delivery support transition
Kanban in Support
Why Kanban in Support?
57. • Get organised within your team and your project
• Create a visualisation method (ie. Board)
• Be dedicated – It will not be second nature at first and will need to be worked at
• Evolve with it – Don’t stick with an element that’s not working. Change is perfectly fine
within Kanban so make it your own
Getting Started with Kanban in Support
How to begin with Kanban
• Someone to “lead”
• Daily calendar 10min morning stand-up invite to all team members
• What did you do yesterday?
• What are you going to do today?
• What blockers are in the way of making progress?
• **Do not discuss the details of the incident**
• Large whiteboards fixed on the walls
• Regular sweep comparisons of the board to KIM
• Managers have to participate too
How to adopt Kanban
60. • Before Go-Live…
• Embedded support staff for final 2-4 sprints
• ½ funded by support & ½ funded by delivery
• Full collaboration within delivery team as scrum resources
• Knowledge transfer & Skilling up
• After Go-Live…
• Improved documentation brought back to support
• Improved visibility of support staff by the customer
• Service design package creation leading to new delivery phase (ie. DVLA phase 2)
DVLA Support
DVLA Case Study
61. • High-profile GDS exemplar project for online electoral registrations
• Unique on-site familiarisation transition phase following go-live into support
• 2 support staff embedded into GDS onsite for 6 weeks to assist with delivery of
change and gather knowledge (1 x WebOps & 1 x Application)
• Kanban support of all incidents, change and service requests
• Kainos Incident Management (KIM)
• Kanbanflow.com
• ITIL-aligned support delivery
• Sprint-based delivery of change
• Mixed team of WebOps and Application executing fortnightly sprints of pre-agreed
backlog changes
• Daily remote stand-ups with direct Cabinet Office involvement
Cabinet Office (IER) Support
IER Case Study
62. • An increase in work items within a specific column indicates a blockage during that life cycle phase
• An increase in coloured cards / “dots” indicates a project/engineer overload
• A reduction in lead times indicates an improvement in service management to the customer
Measuring Agile Success
How to tell when agile is working
63. • Kanban adopted within support in June - piloted across a number of teams
• Clear reduction in lead times across all agile projects (Pre-Kanban avg vs Post-Kanban avg)
• Seamless transition of delivery stories into support tickets
Measuring Agile Success
Kainos’ Agile Support Metrics
64. Challenges for Agile Support so far
Offsite
• Physical board impossible to
see so unable to know
allocated tasks
• Inability to update the board
with progress to inform other
team members or add new
tickets
• Solution! Digital version
using Kanbanflow.com and
dual updating adopted
M Integration
• Need to stop duplication of effort in
replicating KIM (incident) details
• Retain KIM security and confidentiality
so 3rd party tool has to be limited to
KIM# and title only
• Solution! Potential project for
someone to create a
kanban.kainos.com which hooks
directly into KIM, shows all projects
and is secure enough to display full
incident details
Adoption
• Encourage team enthusiasm
towards stand-ups and board
editing
• Diligent attendance of stand-ups
• Keeping update content to a
minimum
• Solution! Perseverance and
recognition that it is worth it to
have better organisation and
improved service
65. • What are the current gaps in the delivery of support on Agile projects?
• How do we ensure support is considered from the outset of a project?
• How can we ensure that the relevant governance is in place for a service as soon as it
goes live?
• Should there be a separate Support team on an Agile project, or is it a continuation of
Development post go-Live?
• If separate teams:
• Should we embed support engineers within the current delivery team, and when?
• Should we facilitate the use of delivery staff in a supporting role post go live?
• How do we address the allocation of work between break fix, enhancements and
continuous improvements?
Agile Challenges
What agile challenges are still present?
66. Successes of Agile Support so far
Organisation
• Much better visibility of your
workload
• Better daily planning as a
result of stand-ups
• Improved teamwork as
immediately obvious what
other team members are
doing allowing distribution of
incidents more efficiently
Customer Service
• Improved lead times from open to
close
• Regular prompting of customer-owned
incidents
• Improved customer service satisfaction
ratings
• No visible gap in service provision to
the customer. Continued agile
throughout.
Management
• Better visibility of engineer
workloads
• Better visibility of project
workloads
• Earlier visibility of incident
blockers as a result of stand-ups
• Less interaction with the team
required
67. • Scrubbing the defects
• Time-bound sprints
• Support and development team collaboration
• Transparency/Visibility
• Focusing on Business Value
• Improving Quality
• Focusing on Customers
• Stakeholder Engagement
• Application of best practices from Agile/ITIL combined
How does agile help support?
Agile Benefits