Effective Use of Kanban for Infrastructure Support Teams

Support activities for information technology systems can generally be broken into two categories, user requests and project tasks and there are a myriad of tools and processes that can be employed to manage that work. Solutions range from simple spreadsheets to complex Microsoft Project plans to commercial ticket tracking systems with lots of workflows and reporting features. Finding the right solution can be challenging and must be customized to the way you perform your work, and the budget you have available to build a support tracking system.

When I launched my test environment support team a decade ago with minimal budget and only two additional technicians, I created a highly-customized Microsoft Infopath template to ingest all work requests we needed to track. This simple solution allowed the team to easily capture the work being performed with a simple interface to report on basic metrics (mostly the number and types of requests closed each month).

As the platform teams we supported transitioned to an Agile development methodology using the Atlassian suite of tools, I partnered with with our highly talented ScrumMaster, Stephanie Teague, to develop a modified Agile process that would model the work done by our team without some of the more rigid processes of Agile like story points, sprints, and releases. The solution Stephanie crafted for us centered around using the Jira Kanban board to track the different phases of the work being performed by the team.

Kanban board utilities (not just Jira), typically provide the ability to highly customize both the data in the issue and the way it is presented on the board to make the board work best for your team. And while the concept of using Kanban for IT project management (Google search: using Kanban for infrastructure projects) is not new, I wanted to share how my team used it to make our lives easier with the six achievable steps Stephanie presented to us.

1)    Define how project tasks, milestones, and rollup items map to the issue types available to you.

• Epic – Each major project was defined in an Epic issue on the board. All work related to the project was rolled up under the corresponding Epic
• Story – Stories serve three purposes on our board. The main purpose is to be the low-level task that needs to be accomplished as part of the project. The second is to act as a roll-up task to simplify workflow management when we need to track a step of the project that consists of multiple related actions. For example, the story “Deploy Server” may have tasks to provision hardware, configure network, install OS, etc. Lastly, we would use stories when there was a project milestone that we also wanted to track, but without any actionable items associated with it. We also used stories to capture one-off work items that weren’t a large enough scope of work to be considered a project, but they also were not a user problem or service request.
• Sub-task – When stories acted as a roll-up issue, we would generate sub-tasks under the story to define the action to be performed.

2)    Describe the work in your issues by telling a story. Start with a summary, provide background and a description of what needs to be done, and state the exact things that need to be met for the issue to be marked as done. Do research on the web and with your existing Agile teams to find a story format that works best for your team.

3)    Set up the steps of your workflow as columns on the board, but I’d recommend at least these five categories, from left to right:

Backlog > Ready > In Progress > Review > Done/Cancelled

• Backlog is where it all begins. All new project tasks or work ideas for the team begin in the Backlog. Here is where you spend the time to do story elaboration and make sure each issue has all the necessary information for it to be assigned and completed successfully. Don’t move an issue out of Backlog until it is truly ready.
• Ready is where your elaborated stories will sit and wait for someone to pick up the task and work on it.
• In Progress is where you put the work actually being performed at the present time. This is where it is important to limit the number of issues allowed to be in the column; taking on too many issues at once can lead to poor performance and decrease the overall productivity of the team. If an individual gets to a point on their task where they are waiting from someone or something, move that issue out of In Progress before moving a new one in (maybe add an On-Hold column?).
• The Review column is for completed tasks that are ready for a group review to make sure the definition of done is met, or as an interim review of any automation code being written where a formal review could be of benefit.
• Done is the last step of the workflow, once all the issue objectives have been met and reviewed. We also used this column to capture any issues that ended up being cancelled. Every-other week, we issue a “Housekeeping Release” on the board which removes all the Done/Cancelled tasks from view.
• You are free to add or remove columns as necessary to help you manage your workflow effectively. Keep an open mind as time goes on and adjust your workflow as needed to help your team stay on track.

4)    Use different board formats and query strings to visualize the data. Using the swimlanes of the board to separate the data, we have views that bring all high-priority to the top, or separate the lanes based on the project Epic, or our daily workflow board where each team member is in their own lane. You can also view or hide columns based on what is important to the person receiving that particular view.

5)    Use ceremonies effectively to keep making progress. Define a set of “standard” ceremonies and use those sessions to only do the work defined for that time. Staying focused on purpose minimizes disruption to the team and improves productivity. Attendance is improved because the team knows their time won’t be wasted during the meeting and management can be kept informed on work items without the team feeling micromanaged. We generally use these four specific ceremonies:

• A brief daily call to discuss status of in progress items and call out any impediments encountered. We also use this meeting time one day a week for backlog grooming to move work into the Ready column.
• A weekly review meeting to look over completed tasks and move them to the Done column, or to perform code reviews.
• A quarterly team retrospective without management present to review team procedures and discuss where improvements could be made.

6)    Document your process and put it somewhere everyone has access. Once you have your board and your workflow process defined, create, post, and share a rules-of-the-road document that clearly states:

• The purpose for each column on the board (the steps of your workflow)
• Where a task can go from each column (Backlog go only go to Ready, Ready can only go to In Progress, In Progress can go to Ready or Review, Only Review can go to Done, etc.)
• What must be accomplished before a task can be moved out of each column
• The standard ceremonies, what information is to be covered and how they are to be facilitated

This example is only one representative framework of an infinite number of ways that Kanban can be used for project and task management. There is no prescribed solution that will work in every situation and for every team. You must continually make adjustments to your process until you achieve the results you need, then continue to experiment with ways to continually make the process better. Using the example highlighted here, my team saw significant improvement in productivity and practically eliminated the question "where are you at with that project" from our leadership team. I challenge and encourage you to do better!