Kamu: improvements to ITSM (and one day ITIL), Agile and DevOps
Author: Rob England
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
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 assessment
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.
Full article: basicsm.com/content/kamu-improvements