Friday night, 9 p.m., and the hallways are dark. Light spills from individual cubes here and there, and the same conversation echoes throughout the halls in surround sound.
The IT release is in full swing. New functionality is on its way to Production Systems while Development and Support Teams around the globe are using the unified communications bridge to check system status, install software, check off validations.
We do this a couple times a month, once for system upgrades and once for our custom applications. It’s exciting because new IT software is how our telecommunications company delivers new features to customers.
And yet, is this twice-monthly formal release cycle Agile?
Some developers complain that their sprints hit a testing and deployment waterfall. In a perfectly Agile world, scrum teams could sprint on their own schedules all the way to production. I have read about startups with continuous integration tools that purport to streamline software delivery to complex environments. Here at Level 3, we have hundreds of interdependent applications, some first deployed back in the ‘90s (ancient history in IT-land, and some were in operation even before Level 3 existed). There’s a lot of testing that has to be coordinated. Sometimes it’s like remodeling your kitchen; 20% of the work is adding the new features and 80% is making sure it works with everything that’s already there. Our new reusable services architecture will help change that dynamic, but we have a lot of “old stuff” that reminds me of the vintage stove in my first house (a fixer-upper). It still works, so why upgrade?
And then there’s the question of how Agile fits ITIL (IT Infrastructure Library). In ITIL v3, release and change management are about controlled planning, process-centric implementation of change, and coordinated communications and deployments. Sounds slow, rather than Agile.
We’ve been using ITIL as a framework for adding structure to IT services. When Level 3 doubled in employees last year (after acquiring Global Crossing), it became apparent that we needed more structure and a common language as the two companies’ processes came together. ITIL gave us common ground and language.
We use Agile in the “Plan-Design-Build” stages, but the “Operate” stage leverages ITIL concepts. Increased rigor from the ITIL framework is helping us to protect the business by focusing on service availability, and Agile helps us accelerate the business with new capabilities. We’ve struck a balance of monthly code releases, a coordinated transition to production systems for the several weeks’ of epics and sprints. And in the spirit of ITIL’s continuous improvement, we keep looking to go faster without compromising quality.
I imagine the overall process to look more like this than the diagram above:
This month, we’re adding a lot of new features to help our operations teams run the network better. I’m looking forward to checking the customer satisfaction numbers down the road for proof of the impact that the additional automation is bringing to the business.
So, the next time you’re working during off-business hours, when it’s so quiet that you can hear the clicking of keyboards and know who is there by the glow from their workspace, let me know your thoughts. How does Agile meet ITIL in your organization?
Latest posts by Carolyn Reuss (see all)
- Engineering your path forward: A letter to my daughter (and any young woman exploring a future in technology) - July 23, 2013
- Are You an IT Superstar? - April 16, 2013
- Can ITIL be Agile? - July 23, 2012