Then there is the Change Management process ☹
My favourite. Much maligned.
From ITIL v2, change management has been about assisting the implementation of changes while minimising risk. Many implementations of Change Management have tended to concentrate on the second part “while minimising risk” and turned Change Management into a bureaucratic nightmare. (NOTE: ITIL 4 reinstates its original purpose, I am glad to say.)
How about applying Agile to Change Management?
What if we start with a very simple Change Management process, which requires changes (altering the way in which a service is delivered) to be documented, tested as appropriate, and approved by the relevant stakeholders? No more, no less. Very simple.
Let this run and have the users (change management customers) tell us how they would like the process to evolve. They might suggest improvements like:
• Different types of changes depending on complexity and urgency
• Different ways to obtain approval (I once implemented a totally virtual CAB)
• Different change priorities
• Two change flows – one for Waterfall and another for Agile Development
• A lot more ideas, the list is endless
Then imagine having a fortnightly catchup (Showcase) with the users, to collect their ideas, and deliver those process improvements two weeks later? How about a Change Management process that actually makes users’ life easier!
My answer has always been – Why not?
Can we be Agile with services?
Same answer. The trick is to build the diverse teams to focus on value. And to define what is meant by ‘Done’ in an Agile sense. What is a releasable service improvement?
The move to microservices and decoupling helps with being able to deliver the minor enhancements, rapidly and with low risk. Design your services, right from the beginning, to support multiple releases over its lifespan. This fits beautifully with ITIL 4 Service Value Chains.
Agile development of services, with Agile service management in mind, leads to highly adaptable, and highly available services which can be continually enhanced, integrated and deployed. Again, stealing from the Guide:
“Agile Software Development + Agile Service Management = Agile IT (DevOps)”
I would even take this further, into Enterprise Service Management, and say:
“Agile Service Development + Agile Service Management = Agile Enterprise”
There is no reason why the Agile methodology cannot be applied to all service provision. This makes the Agile Service Management guide ever more relevant to all professionals.
And there is the
Upskilling: Enterprise DevOps Skills report
The DevOps Institute commissioned a report