Kamu: improvements to ITSM (and one day ITIL), Agile and DevOps

kamu
When the three meet, (ITSM, Agile, and DevOps), when we reconcile their world-views, they can all learn from each other. Here is a grab-bag of ideas to share between them. As it grows I'll structure and organise it better as required.

Improvement: the Three Ways

The Phoenix project describes the Three Ways: Flow, Feedback, and Learning. Make sure your CSI covers the three ways

Improvement: feedback

don't let ITIL's process and CMMI obsession mean you only feed back to improve your management of process. that is secondary.
Your primary goal is feedback to improve the service itself. This is what Agile feedback loop does.
You need both.

Service Strategy: brownfield

The real world is full of horses and snowflakes (Agile/DevOps speak - look it up). Sites are brownfield not greenfield: there is a legacy of enormous investment in information and technology. Systems are complex and inter-connected. This is a very real impediment to DevOps that requires major investment to address it: don't underestimate it and don't over-apply the Agile/DevOps "religion" without understanding the risks and costs: it's bigger than you think.

Service Strategy: multi-modal

Agile and DevOps are more aporopriate for some systems than others. Find out about bi-modal, tri-modal, pace-layered strategies. basically legacy systems are improved by more traditional means while new "systems of innovation" and more stand-alone systems are built using agile/devops. Different strokes for different apps.

Service Strategy: complex value streams

The Real IT world isn't building bespoke systems any more: they are complex aggregations of XaaS, COTS, and outsourcing, with in -house integrations and point solutions development. DevOps in such an environment is immature.

Service Design: documentation

Developers ahve always wanted to reduce documentation, e.g. the old "self-documenting code".
But automated test scripts are arguably a large part of requirements and design documentation if they are treated as such: built up front; published; archived.

Change Management: culture of trust

Change Management needs to move to a mindset of facilitator of change not gatekeeper. To do this, much trust needs to be given to those making the changes. E.g. Developers should assess the risk of their changes - who else is better qualified to do so? They should also do the deployment into production for the same reason.

Change Management: Standard Change

Organisations need to rediscover the fundamental ITIL concept of Standard change. A Standard Change is pre-approved. in order to execute one, you only need record it and schedule it. Each type of Standard Change will have rules around what that involves. e.g. Scheduling could be anywhere from "whenever" to "once the business owners have agreed to the proposed time".

Once you automate build, test, and deploy, all changes through that mechanism are Standard Changes. [True statement?]

Change Management: slower cadence

It's OK to slow the Agile cadence down for production releases, in order to reduce risk. E.g. going from once a day to once a week has little impact on time to market, but allows consolidated user acceptance testing of new functionality

Change Management: faster cadence

Clearly most change management processes need to speed up to meet Agile demands. Remove fixed delays in the process. Find faster communications mechanisms than CAB. Only use CAB for highest risk changes

Change Management: better risk asessment

Risk assessment tends to be a blunt instrument. Get more sophisticated. Allow discretion. Empower developers to assess risk: they know best. (but make them accountable)

Release Management: Infrastructure as code

The use of code (APIs, scripts, specialised tools) to automate the creation of servers, platforms, storage, network, databases... means the system is deployed as one code build for the application and the infrastructure it runs on: spin up/tear down of complete environments; infrastructure versioned and migrated as source. You would no more manually build the server than you would manually re-type the application executable.

Release Management: Continuous Integration

Intense automation of build, test, audit, approval, and environmental migration.

Release Management: Continuous Delivery

Intense automation of production deployment.

Release Management: incremental release

It doesn't have to be big bang. Find out about canary release; dark launch.

Release Management: user impact

DevOps and Agile folk can under-estimate user impact of changes. A third of the population are technophiliacs, a third are tech-neutral, and a third are technophobic. You can't expect all non-IT staff to cope with changes to functionality without prior warning and training, and without extra support and coaching on the day. Unions have a view about this too.

Incident Management: Fail Fast

it is quicker for a developer to replace the broken code than it is for an application support coder to find the bug, write a fix and an emergency CAB to assemble to approve it. And fix the automated tests so the error doen't get through again

Incident/Problem Management: Replace not Fix

Don't write an emergency fix: repair the orginal code and push a new release through the full automated test and deployment - just as fast and lower risk