I sat down with an Agile Coach recently and told him about how Beyond20 teaches classes outside of just Agile/Scrum, including 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 really cool conversation.
This Agile Coach had previously worked as an IT Director, and when his team learned about ITIL concepts, they were already working in an Agile fashion. They then took this learning and figured out how to overlay these concepts with how they were already managing their work. They basically “swarmed” around Incidents – understanding what the SLAs were for the various incidents (so they knew how quickly Incidents needed to be resolved) and worked this allotted time into their sprints.
Unfortunately, most organizations still struggle with the question of “How do we balance our daily firefighting and still get new projects/products completed quickly while using an Agile approach?”. Teams that do both ongoing operations and project/product-focused work can still work in an Agile fashion. They would still maintain a Product Backlog and divide up their time into ongoing operations and product-focused work. Let’s say our team deals with Incidents 40% of the time (the goal being that the team will look for ways to decrease this amount of time in the future). Then, 40% of my team’s availability will be carved out for firefighting / managing incidents, leaving 60% of my time for product-focused work; and this will be accounted for in our Sprint Backlog. This time can be handled in a couple of different ways, either by removing that amount of time from the overall team’s availability or creating a user story for operational-type of work.
If the team finds that they’re handling less ongoing operations-type work (incidents, problems, changes, etc.) in a particular sprint, great. The team has more time to devote to product-focused work. If you’re finding that the team is pulled into operations more than expected, then they’ll 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 readjust going forward. Further, you will want to set expectations with your stakeholders that if the team gets more of these “iteration interrupts” within a particular sprint, less work will get finished.
In a recent Scrum@Scale class, Jeff Sutherland discussed the importance of always leaving teams some “buffer time” in a Sprint. In most organizations, “buffers” have 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 leave 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.