Can Kanban in Software Support?
Introduction:-
------------------
We are basically developers and mostly follow Agile methodology during our development cycle. Recently, we got responsibility for handling a Software Support group. Here the scope is bit different; we need to provide a quick fix (L2 fix) on the system so that the user can proceed.
We have seen few new problems and constrains during the Support, which was quite different than normal development cycle. As usual a first question comes to my mind “Can Software Support problem be addressed with Agile Methodology?” we started thinking solution using Agile.
Initially we were not sure about the success of Agile method in Software Production support. Later we found Agile Methodology was quite helpful also in Software support.
We started using Kanban to address one of the problems of support, and we have seen it is quite a good success using these methodologies.
Problem statement:-
--------------------------
Every day, L1 support team (direct interface to the users) used to get calls by the end user. Among these call few calls can be handled by the support team itself. Rest of the calls need to be handled by L2-support-team by creating a production-ticket for L2- support-team. L2-support-team-LEAD used to assign this ticket to the L2 team. L2-support-teams are mostly expert in their technical field. In this case we will assume Desktop client, server/service, and Database are different works where the production needs support.
Production environment are always dynamic, based on the user usage on the production support calls and intern number of production ticket may differ.
Here the responsibility of the Support-team-LEAD is to equally distribute the support calls among L2-support-team to balance the L2 tickets, which intern leads to better customer satisfaction and stability in the system.
Mapping of the Kanban methodology:-
----------------------------------------------------
L2-support-team will be divided based on their technical field, let’s say Desktop-client, server/service, and Database. Each team needs to announce the maximum number L2 issue/ticket fix per day. In our case Desktop-client can solve 3, server/service can solve 5, and Database with 3. At any point of time it should not cross the announced limit. Moreover new ticket backlog also should not cross 6 tickets at any point of time.
Support-team-LEAD responsibility is to assign the backlog issue to the responsible team.
At any point of time the threshold should not cross the defined limit. If it crosses the maximum limit, Support-team-LEAD needs to be alert for the immediate plan. Let’s say in for the database team pending task was 5 at a point which was above then the maximum value. Now the Support-team-LEAD needs to be alerted, and need to pitch into the database area and help the database team to fix the tickets. Once the database backlog is on the track, the LEAD can go back his/her earlier task of issue/ticket assignment.
Conclusion:-
-----------------
We have observed this way of production issue tracking can have better control in the production system.
However this implementation is completely as author specific and the scenario faced by him. This concept may not applicable one to one to other products.
If you have to create such a fancy process to handle support, than I would suggest that Kanban his hiding your root cause problems rather than exposing them.
As such, using Kanban here is a sure fire way to continue to have dysfunctions in perpetuity. Good software doesn't need fancy support.
Also see:
http://Scrumcrazy.com/bugs
> Here the responsibility of the Support-team-
> LEAD is to equally distribute the support calls
> among L2-support-team to balance the L2 tickets
That's a push-based system. An agile process would use a pull-based approach whereby teams draw work from a backlog as soon as their Work In Progress limits can accommodate it. Kanban is one way of managing and visualising this, but that doesn't seem to be happening here.
It's reasonable, in a Kanban support model, to have an L1 team triage work into the backlogs of appropriate L2 teams. This determination might be based on team skillsets for example, or perhaps the quality of service that is to be provided. However it would not be reasonable to have a team lead triage work by monitoring availability and directing work towards teams on that basis.
All agile and lean methods, including Kanban and Scrum, use a self-balancing pull-based approach for drawing work through in order to add and release value.