Agile software development approaches were originally created to address software development challenges. As enterprises that don’t sell software as their main product adopt agile, they find the need to adjust their approach in order to apply agile across their IT organization and entire enterprise.
In previous posts, I explored how you can use agile to work with COTS and business intelligence, both of which are common activities that are different from (but not entirely unlike) software development activities frequently found in IT organizations. In this post, I’d like to explore how you can perform another activity, IT service, in an agile fashion.Characteristics of IT Service Work
IT service work includes areas such as service desk, release management and configuration management that are related to providing information technology services in an organization. There are several other areas that could be included in this description, and I could spark several semantic arguments about what is included in the IT service work category.
To keep things simple, what I’m talking about in this post are those teams in an IT organization that tend to have work with the following characteristics (as opposed to teams that work on software development projects):Work items usually takes the form of a request or a ticket. These items show up at unpredictable times. Some items are extremely time-sensitive, especially if they deal with people not being able to get their work done, while other items represent changes which are not quite as time-sensitive. Each item is independent from every other item. This means that as soon as you finish the requested action you can deliver the results to the requester, without waiting to finish other, unrelated items. Items generally have less uncertainty surrounding them than items on a software development backlog might have. The only exception to this is when the item represents a bug that requires investigation to identify the root cause. Work Flows Through an IT Service Team
You can group agile frameworks into two groups: those based on timeboxed iterations, such as Scrum, and those based on flow, such as Kanban.
Each type of framework is better suited for different situations. The context in which you want to apply each framework helps you determine which framework works better for your team to establish your methodology.
Flow frameworks are better suited to IT service work than timeboxed iterations. There’s a variety of reasons for that:Flow approaches provide greater flexibility to deal with priorities that change frequently. You can change your priority every time you start working on a new item. Flow approaches are better suited for work items that show up randomly, are independent of each other and are generally not part of a bigger whole. Flow approaches are better suited for work items that you can deliver when you are done rather than those that need to be grouped together with other changes. How Work Flows in an IT Service Team
To describe how to apply a flow approach to an IT service team, let's look at a team that maintains a not-for-profit professional organization’s website, including membership administration, event registration and community groups.
Work flows into this team when someone submits a question, request or complaint via a “contact us” form on the organization’s website. The team can’t predict when these questions will come in, and the items vary in their urgency. The team also has a few ongoing efforts to introduce changes to the website driven by new programs or events.
The team has five members, each with their own area of responsibility. A few of the members have the ability to back up the others when necessary or deal with the more involved support situations.
The team is distributed so they use Trello to keep track of the items they must work on and the items that are in progress. Because the items do not all have a consistent workflow, they keep their board straightforward by dividing items into the following sections:
Newly identified items are placed here when either the team identifies work they need to do or someone submits a request via a form on the website.
Items that have been triaged and have sufficient information to proceed.
Items that a team member has picked up to work on.
Waiting for Verification
An item where a team member has completed the work and has requested verification that the work was completed appropriately.
The requestor or other team member verified that the work was done satisfactorily.
Change was implemented on the website or request was delivered to the requestor.
When someone submits a request via a form on organization’s website, the form sends an email notification which Trello converts to a work item in the “new” section.
The team members take turns triaging the items in the “new” column. As part of their triage activity, they determine the urgency of the item and classify what type of work it is (i.e., does it relate to membership, event registration or website content). The team member doing the triage sets the appropriate label to indicate the type of work. They then move the item to “on deck” and place the new item in a specific order in the “on deck” section based on the item’s priority.
When a team member is able to move an item they were working on from “in process” to “waiting for verification,” they check the “on deck” section for a new work item to start on. The team has some rules that everyone uses to select an item that are based on priority and the type of work that each item represents.Experiencing the Best of Both Approaches
Even though the team uses a flow approach, they’ve adopted some practices used by teams working in an iterative fashion, mainly because they found value in adopting those practices, not because anyone required them to.A regular planning cadence
Once every other week, the team gets together to look at the “on deck” section to determine if the items are in the proper order, whether there are any new initiatives that they need to account for and whether there are any items in “on deck” that could be removed altogether from their board.
This discussion is like a sprint planning meeting with the exception that the resulting queue - in this case the “on deck” section - is not set in stone. Essentially, this discussion serves to reorder the “on deck” items based on the team’s current understanding of the priorities.Daily stand-ups at the board
The team gets together once per day to briefly discuss what everyone is doing that day and to determine if there are any in process items that have hit a roadblock. During these stand-ups, the team members discuss:What the team needs to do to get things moved across the board. Based on what is known right now, what item the team should start working on next whenever there is room. Retrospectives around the board
The team also finds value once every other week to discuss how to improve their process. They have this retrospective while looking at the board, because it provides insight into how the team is doing. The questions the team asks during these retrospectives include:Is there any hidden work that’s not represented on the board? Do we need to add a queue section? Are there any impediments? How can we remove them? Are we tracking things at the right level?
The team used these retrospectives to end up at their current process. They certainly didn’t start using a flow approach with the process described here. Rather, that process evolved as the team got some experience and held retrospectives to gradually improve the process.Measure and learn
To aid with their retrospective, the team tracked a small set of metrics that also helped them to identify obstacles in their process. These metrics include:Throughput: the number of items completed this week Lead time for each item (completed date and start date) Average lead time for this week Items completed with > 0 blocked days Total blocked days A list of places where items were blocked How Can You Get Started?
Would you like to begin using a flow approach in your IT service team? The best way to get started is to map your current process using a board similar to what I described previously. Then, place all the work your team is currently working on in the appropriate section and start working together as a team to gradually improve your process using stand-ups, metrics and retrospectives.
Do you have any experience applying flow techniques in an IT service team? Share your experiences in the comments below.