Archived: Configuration & Change Management in Agile DevOps – Part 1

We have successfully adopted and transitioned into DevOps, Agile and continuous integration with weekly deployments of code, new features and functionality to the TfL website. This is the first in a series of posts looking at how we manage these processes behind the scenes. 

Change, release, configuration & service transition is moving from gatekeeping to devolved, trusted & collaborative safe continuous delivery
Change, release, configuration & service transition is moving from gatekeeping to devolved, trusted & collaborative safe continuous delivery


In order to accommodate the faster lead times and weekly deployment frequency, we discovered that some areas of the ITIL framework are too heavy and don’t easily accommodate the volume of change (code and infrastructure) that we are deploying each week. Therefore, we are evolving into a new hybrid framework including elements of Agile, Scrum, Prince2, DevOps and “light-touch” ITIL that works for us.

We have a constantly evolving cloud-based infrastructure, based on an open data model that includes new distributed and dynamic virtualised systems/servers and a unified API. One of our key values is to be “quick to market,” so we need the capability to keep our data and cloud architecture up to date, in near real time, incorporating configuration data and performance metrics like cloud infrastructure health, web page load speeds, JP response times, etc.

Agile is an overlay and introduces different gearing (rates of change) for various sprint deliverables, so beyond priority/impact discussions, this is the challenge for ITIL.

Weekly Deployments & Continuous Integration

We are executing weekly release and deployments, so the governance of the traditional ITIL framework struggles to keep up because we do changes in configuration management, change management, problem management and release, service transition and deployment life cycles every single week.

Therefore, we use a Release Note to summarise all agile project team change activity which is also part of the “definition of done.” In addition, we work visually, using flip charts, white boards, burn down charts, post-it- notes, Kanban, Scrum boards, Jira activity streams, Hip Chat, and so on. This means everything is transparent and visible to all.

To minimise risk we load, security and performance test each release package, testing on a weekly basis. It’s complex stuff, so we do retrospectives, early and often, to catch bugs quickly, test in dev with code reviews and learn from mistakes.

ITIL as a framework should not be by-passed, though some of the processes become machine driven and automated, e.g. for version control we use Puppet and CloudFormation. It’s not perfect, but it works and we continue to evolve and change things to suit what works and discard what doesn’t.

If you’re involved in similar processes or have any comments or questions on the ones described here, please leave us a reply in the comments section below.

In part 2 , I’ll discuss infrastructure as code and the CMDB.

3 Comments

  1. Excellent work by TFL IM. This is what is known as do it as required not do it as layed down by rules or frameworks i.e. use your common sense also.

  2. While replying to such emails has never elicited a response, I will try again. The add a comment link gets page not found. Your emails are truncated. This makes searching in them impossible.

    1. Hi Walter, apologies but I’m not sure what emails you are referring to? If you can give me more info I can try to find out the answers to any questions you have.

Leave a Reply to clearance magnetic mailbox covers Cancel reply

Your email address will not be published. Required fields are marked *