Is Agile and ITSM possible? Can IT departments form agile teams when teammates are primarily responsible for responding to and resolving IT service requests and incidents?

Absolutely! IT leaders must likely communicate the tradeoffs with business leaders and guide their teams in time management. There are ways to split time between the agile teams’ program and product development work and their ITSM responsibilities.

What about agile DevOps teams? They must resolve incidents or fulfill end-user requests more than occasionally. How can we address their ITSM responsibility so it’s less likely to disrupt their work and minimally impact sprint commitments?

Life’s simple with dedicated DevOps and ITSM teams  

Ideally, an IT organization will have DevOps teams fully dedicated to delivering product and program enhancements. These teams use agile tools like Jira to manage their backlogs and make adjustments when they must respond to incidents or requests. Since the IT organization has separate teams dedicated to ITSM, agile teams rarely respond to day-to-day incidents and requests. Even better is when the organization has site reliability engineers (SREs) who provide a frontline defense to resolve major incidents and identify root causes of problems.

Ok. Stop laughing. I know I just envisioned a perfect and highly unlikely scenario.

Agile teams in large organizations are likely getting pulled into incident management much more than realized – and all too many are in firefighting mode – one of four paranoias I highlight for CIOs. The word “burnout” appears 42 times in the 2024 Accelerate State of DevOps report, and it has many findings about stressed-out teams and the elevated risks around burnout. (Note: See my important article on from burnout to breakthrough.)

DevOps, Agile, and ITSM work in small IT shops but with several adjustments.

Time management and burnout problems are magnified in smaller IT organizations, where people are primarily assigned to run activities such as requests, incidents, and standard operating procedures. There’s significant demand for these groups to take on more programs and enhance products, applications, and infrastructure. Additionally, their IT leaders want to become agile and leverage agile methodologies like Scrum and Kanban. However, it feels impossible to get any form of commitment from the team because operations and services are of higher priority.

Addressing Agile and ITSM in one team is possible, but IT leaders must set priorities, communicate them, and review the impacts on service-level objectives (SLOs) or service-level agreements (SLAs).

Steps for Implementing Agile and ITSM With Teams

1. Research each team’s agile and ITSM performance

To get started, I recommended doing some research and analysis. Do this for every team with agile and ITSM responsibilities.

1. Analyze the tickets. What types of tickets are they responding to? What days of the week and times during the day are they coming in? For this analysis, segment out the highest-priority tickets requiring immediate response versus others with longer response and resolution time objectives.   
2. Look for optimizations. Are there ticket types with optimization opportunities that can be fulfilled faster and ideally without the agile team’s response? Consider opportunities to automate steps or improve documentation.
3. Capture basic metrics. How many tickets does the team work on per week? If you capture effort time or work time, calculate the minimum, maximum, and median time per week the team applies to ITSM work. If not, ask the team to estimate.
4. Identify low activity periods. Are there days and times when the team has fewer, lower-priority tickets to work on?

2. Review ITSM optimization opportunities

Here’s how to use this data to reduce the number of tickets and time applied to them. In addition, there may be a need to reset expectations and SLOs.

• Use (b) and (c) to share with the product owner. If the product owner wants more team capacity to work on the agile backlog, consider prioritizing the operational debt and implementing selected optimizations.
• Use (c) to compare resolution times against SLOs. If the team is not meeting them, review the cause and determine whether the SLOs are realistic and worth reviewing with stakeholders. If they consistently meet SLOs, consider adjusting how and when they respond to non-urgent tickets.
• Use (d) when there are opportunities to set different SLOs by day of the week or time of the day.

3. Guide agile teams on time management

Here’s the more significant opportunity for Agile and ITSM teams.

Ask each team member what time of day and days of the week they do their best work. Some will be morning people; others may be more productive later in the day. Many will favor Tuesdays and Wednesdays over Mondays and Fridays.

Ideally, we want to use their most productive periods to work on programs and products – their agile team commitments.

Review everyone’s productivity schedule with the ITSM low activity periods (d). Find times as a team and for each teammate when they can work on agile sprint commitments or the Kanban board with minimal impact on ITSM ticket responsibilities.

For example, if Jill is most productive in the morning and fewer tickets are coming in on Mondays and Fridays, I’ll guide her to work on her agile commitments on Monday and Friday mornings when it has the least impact on ITSM SLOs.

In fact, I’ll instruct Jill not to even look at the ITSM ticket queue during her productivity periods so it reduces distraction.

Repeat this with every agile teammate. How many hours can you carve off for agile work while minimizing the impact on ITSM SLAs? If the found capacity isn’t sufficient, review ITSM opportunities, especially if the business is open to reducing SLOs in order to increase agile team capacity.

4. Communicate the management policy

IT leaders can’t perform these managerial changes without communicating them, otherwise, there may be pushback if the team misses more SLAs.

• Communicate why the change is being made. IT leaders should seek to increase agile team capacity and focus while minimizing the impact of resolving incidents and requests.
• Define and communicate the time management strategy. Share the capacity with the product owner because the team should now make agile sprint commitments based on the capacity. In addition to the productivity time dedicated to agile work, factor in the weekly min/median/max time the team responds to tickets when setting a capacity expectation.
• Establish an escalation process for priority incidents.When teammates focus on agile work and aren’t looking at the ITSM queue, there’s a risk they may miss a high-priority ticket. IT leaders may need an alternative escalation path for P1s, SEV-1s, and other critical priority tickets. One opportunity is to use rule-based automations available in Jira and ServiceNow to push P1s and SEV-1s  onto the agile team’s backlog. Alerts can also be sent to Slack, Microsoft Teams, and other communication channels.

5. Measure the impact and make adjustments

IT leaders should measure the impact once a policy and practice is set or changed. Here are some questions to review:

• Are agile teams committing and completing work at higher velocities?
• Has the focus improved quality?
• Are ITSM SLAs impacted and to what extent?
• Are agile teammates happier and less stressed working with these guidelines?
• Does the change in ticket response impact employees?
• Is there a measurable impact on employee satisfaction (ESat) scores?  

Consider evolving this policy every few months, especially if optimizations and SLA changes can reduce the time agile teammates respond to tickets. Agile and ITSM is certainly achievable.

If you like this article, consider joining the StarCIO Digital Trailblazer Community, where we have more tips on Agile and ITSM, including an Advisory Connect program for Agile in IT Operations.