Getting Past the ITIL + Agile Frustration
I get a lot of questions around best practices for managing IT operations in an Agile environment. While incorporating Agile methodologies into IT operations can be frustrating – it absolutely does not have to be.
I had a refreshing experience recently while talking to an Agile coach about how Beyond20 teaches classes outside of just Agile/Scrum, including ITIL (Information Technology Infrastructure Library). After telling him a bit about what we do with ITIL, I waited for the expected response of “UGH. ITIL is the worst!” (or something equally dismissive). Instead, he said, “I love ITIL! It helped our IT organization so much, and it works great with Agile.”
This is something I know and have seen myself (we use these concepts together all the time). However, up until that very moment, I had not encountered an Agile coach who had anything approaching this reaction. It prompted a fascinating conversation.
Combining Agile and ITIL Improves Performance
This Agile Coach had previously worked as an IT Director whose team was already working in an Agile environment when they began learning about ITIL concepts. They took the new ITIL concepts and figured out how to overlay them with how they were already managing their work using Agile.
1. “Swarm” Around Incidents
One of the changes they made was to move from a tiered escalation process, to “swarming” around Incidents. By understanding the SLAs (Service Level Agreements) for various Incidents, the team knew how quickly they needed to be resolved, and worked this allotted time into their sprints. This also helped more quickly get the right expert to solve the Incident, thereby saving the team even more time.
2. Balancing Firefighting and Project Completion with Agile
Many organizations working on managing IT operations in an Agile environment struggle with balancing daily firefighting while continuing to get new projects/products completed quickly with Agile. It is possible! The short answer to how is to simply maintain a Product Backlog divide up you team’s time into ongoing operations and product-focused work. Here’s an example:
Let’s say your team deals with incidents 40% of the time (the CSI goal being to look for ways to decrease this). That means 40% of your team’s availability will be carved out for firefighting/managing incidents, leaving 60% of their time for product-focused work – this will be accounted for in your Sprint Backlog.
You can manage 60% of time in a couple different ways, either by removing it from the overall team’s availability or creating a user story for operational-type work.
If the team finds itself handling less ongoing operational-type work (incidents, problems, changes, etc.) in a particular sprint – great! – they’ll have more time to devote to product-focused work. If the team is pulled into operations more than expected, then members will have to remove some lower-value items from the bottom of the Sprint Backlog. If this happens, it’s important to discuss these issues as part of the sprint retrospective and adjust going forward.
It’s important to set appropriate expectations with your stakeholders so they’re aware that less work will get finished if the team gets more of these “iteration interrupts” within a particular sprint.
3. Buffer Time Done Right
In a recent Scrum@Scale class, Jeff Sutherland discussed the importance of always leaving teams some “buffer time” in a Sprint. In most organizations, “buffer” has become a bad word and something to avoid. However, you have to leave your team some time for the surprises that invariably arise throughout the week. It’s better to give your team some wiggle room and achieve everything they’ve set out to do, rather than – what we more commonly do – overcommit, burn out our folks, and under deliver – leaving everyone unhappy.
IT operations will always have its challenges and bottlenecks. But Agile — or Agile combined with ITIL — can provide an effective way to balance issues and project completion.