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.
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
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
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.
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
The below diagram show a sample Kanban board for such teams.
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.
As shown, the board can be adjusted a bit to fir the new scrum process inside the in progress state of the work.
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.
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.