Jai’s Weblog – Tech, Security & Fun…

Tech, Security & Fun…

  • Jaibeer Malik

    Jaibeer Malik
  • View Jaibeer Malik's profile on LinkedIn
  • Subscribe

  • Feedburner

  • Enter your email address to subscribe to this blog and receive notifications of new posts by email.

    Join 40 other subscribers
  • Archives

  • Categories

  • Stats

    • 426,576
  • Live Traffic

Implementing Kanban for Services team

Posted by Jai on August 3, 2010

Kanban is well-known Lean process used in manufacturing industry and further in Agile Software Development also. In this post we will see how we can implement the system for different services teams like Operations, IT, Network and Help Desk etc. How push and pull system in place work for these teams. How a typical Kanban board looks like for these teams. How Kanban plus Scrum can be extended to accommodate specific requirements. The challenges in implementing Kanban for these teams and the need for retrospectives and continuous improvement for the same.

Kanban in General

Kanban is a Signal Card used in any pull system. It is about visual flow of value through the system by eliminating waste by pull system based on limiting work in progress and improving the flow process continuously. It is based on different Lean principles like delivering Customer Value, Eliminating waste, Pull system, continuous improvement etc.

It has been very well adapted in manufacturing industry and further in Agile Software development. In this post we will discuss further how the same process can be integrated with different Services teams also.

Services Team?

Think of some complex scenario where you have some services team, where there is continuous flow of services:

  • Operation Team: Team handling regular maintenance activities for some website to keep it running all the time.
  • Infrastructure/Network Team: IT team taking care of all the infrastructure/network activities inside an organization.
  • Services Team: Any other services team handling end users to provide some kind of services.
  • Help Desk: Team helping users in resolving their queries.

Current Working Model

The current working model for most of these teams is mostly the Push system. Usually there is some team lead who analyze the requirements first or the new support tickets first and then assign those tickets to individual team members who all are part of some kind of support or services team.

Each team member is more or less unaware of the tickets assigned to other team member. Every time the teal lead needs to assign the new ticket he needs to analyze the work load on every team member to assign the ticket further. Every team member needs to wait for the new ticket to be assigned or some time they are overloaded with the tickets to be resolved. Tickets may be pending for response from end users or some other party. Each team member may be restricted to solve only one kind of ticket if he gets good at that and if he/she doesn’t receive different type of work. The whole push system is a lot of waste to every team member. There is no knowledge sharing among the team.

General Work flow – Push system

Some of the general activities done by different services teams are, which may differ a bit from team to team,

  • daily support activities
  • daily reporting on tasks
  • daily maintenance activities
  • daily handling of different type of issue
  • daily walk through of new work assigned to themselves
  • no idea what other team members are doing
  • focus mainly on individual backlog
  • lot of wait until work is assigned to individual
  • lot of pressure to maintain individual backlog
  • lack the team spirit in support activities
  • coordination between different team members tends to be less
  • system designed to support more on task focussed scenario rather than as a team
  • etc. etc.

Following diagram shows the general workflow for the push system for these teams

kanban-for-services-team-push-model

Problems with Push System

You can see in the diagram that the work is assigned by the Team Lead (TL) to each individual team member which maintain their own backlog. The whole push system cause lot of waste associated in the process like dependency on TL to get the work assigned. Each team member over burden by individual work. TL needs to maintain picture of each individual backlog. No team collaboration with individual backlog. And many more similar problems.

From the above diagram, you can make out the problems which the push system can generate for the team,

  • push system
  • lot of waste in the process
  • TL needs to look at backlog for each team member
  • individual backlog burden
  • No clear backlog view
  • Lot of wait for new tickets
  • Lot of stack of tickets on individual backlog
  • No team collaboration
  • No clear bottleneck visible in the process
  • Work can stuck at different level for each team member
  • etc. etc.

Solution – Pull System

Think of another system with the following characteristics,

  • System which support pull flow
  • system to support continuous flow of work
  • system to indicate the problem points and impediment in the flow of work
  • work done as a team
  • focus on supporting work
  • support team spirit than individuals
  • less burden on individual in terms of assigned backlog
  • better planning and prioritize of work
  • better capacity management

kanban-for-services-team-pull-model

How Kanban can help

Kanban is all about continuous flow in work and putting limit on work in progress with continuous improvements in the process. Some of the high level benefits are,

  • regular flow of work
  • better prioritization and control of flow
  • better clarity in terms of work limit
  • better team work
  • shared responsibility with in the team
  • more helpful in planning resources and work
  • more helpful in planning future projects/work
  • etc. etc.

Implementing Kanban for Team

We will see how we can implement Kanban system for these teams to suit their requirements.

Requirements

In general there may be different kind of regular work these services teams do on day-to-day basis. On higher level we can say,

  • Handling Incidents/Urgent issues in the process
  • Handling top priority tasks of support
  • Handling regular project work like upgrade, analysis, research etc.
  • Handling high business value items
  • Handling different dependent tasks for those related regular work


Sample Board

The below diagram show a sample Kanban board for such teams.

kanban-for-services-team-board

Team can define that,

  • priority tasks of support etc. will take highest priority
  • this much time each support task takes to get done
  • this much each new project usually takes to get finished
  • only these many support tasks, new project tasks on each state
  • divide the board based on functional/business value
  • to have individual backlog also during the in progress stage
  • etc. etc.

Kanban with Scrum, Scrumban

The process can be twisted a bit to merge Scrum with the process to help the team to handle the work better. To track the in progress work for each ticket, you can have different status in between.

Putting Scrum in the place during the in progress state to handle different process for different teams.

Sample Board

As shown, the board can be adjusted a bit to fir the new scrum process inside the in progress state of the work.

kanban-for-services-team-kanbanscrumboard

For different business requirement like new small project or upgrade/improvement you can run it as scrum process also and still can track the whole high level item in kanban system.

Continuous Improvement

No process is full proof. It is the learning over a period of time which makes it fit best to the team. Being open for the changes and improving from the learnings is what differentiate one team from the other. In the same way, doing retrospective of the process regularly definitely helps the team in improving over the process. It helps the team to find out their strength and help in putting the limit over work in progress. It also helps the team in removing the impediments for the regular flow of the work.

Do what makes sense?

Every services team differ from each other in terms of the problems they face and the solution for the same. The whole team all together and the way they work need to evolve over a period of time to understand the concept behind the process and make changes to the process to adjust around and improve the same which fits best to them all. There may be few things which may work for one team but not for the other. The whole idea is to keep the mind open and learn and improve over time.

6 Responses to “Implementing Kanban for Services team”

  1. […] I came accross with a blog which describes how Kanban can work for services and Scrum developement. And this is the visual […]

  2. Jaibeer,

    That’s really a good description about things going on in an operations team. I have focussed myself more to the project things in operations which have to be dealt with in the free time slots. The ticket system here takes up the task to decide which ticket is urgent. This is done by a ruleset and estimated SLAs.
    This article is a great start to get into Kanban for IT operations!

  3. Dany m said

    Hi there, I have a question, does your support team use a ticketing system to track the issues or just the kanban board? The reason I am asking, In my DBA team we currently have a ticketing system for change management and trying to use kanban as well. The problem I see is that we will be doing double work, updating the ticket system plus the kanban board. How does your team handle this, if they do?

    Thanks

    • Jai said

      Yes, it is one of the common practical issues which usually teams encounter. It depends on the ticking tooling system you are using. Now a days most of the tooling systems do support Aigle/Lean process. We also started with the typical kanban board to get the team up to speed and to get familiar better with the process initially. During start yes it will be duplicate information and there might be some discrepancy or overhead issues to maintain the information. But accordingly you can plan to totally move to ticketing system for dashboard.

      Some teams do use smart boards for ticketing systems dashboard as a replacement for the white board. Again it will depend on the team and what is more productive for them.

      • Dany M said

        Thanks for the respond. What about Daily Tasks? Do you post those to the board as well or only requests from other users? Under the Goals column, I didn’t see a section for daily activities so was wondering if you track those jobs.

      • Jai said

        The Regular support tickets includes your daily tasks also. You can maintain both individual backlog and team backlog on the board. On white board you can put it the way it suits to team and for tooling you need to configure it as per the team requirements.

        To track the daily tasks, or sub tasks of a particular task which can be divided among team member you can do on both white board and tooling system. Most of the ticket system do support sun tasks for a particular task. You can move sub tasks/tasks for daily job from backlog to goals. Each sub task will have linking to parent task to track the things better and will help in generation reports too.

        On white board you can plan to use different color sticky for sub task and put the parent task id on each sub task sticky to link the both.

Leave a comment