When looking at Scrum vs. Kanban a few weeks ago, I shied away from Kanban because of the “just-in-time” aspect of resource allocation.  I felt that doing that with engineering resources wouldn’t allow me to budget our time effectively.  At our core we’re an MSP, and we tightly control our engineering allocation by providing proactive management of client resources.  If we allow outside circumstances (clients or otherwise) to define the necessary resources, I either have to maintain a bench of people from which to pull, or else I have to risk not having resources available.  Neither of these options are viable for our business.  I never proceeded past this point to look at other Kanban features or to discover personal Kanban.

Current Workflow

Our RT workflow looks like this:

  1. Ticket comes in
  2. Classify ticket according to severity and backlog
  3. If placed in Product backlog, stop.
  4. If placed in Priority backlog, assign to engineer and let them continue.

From an individual’s perspective, the workflow looks like this:

  1. Review all tickets in Sprint and Priority backlogs which are assigned to me
  2. Sort according to severity
  3. Work on high-severity Priority tickets
  4. Work on high-severity Sprint tickets
  5. Work on medium-severity Priority tickets
  6. Work on medium-severity Sprint tickets
  7. … and so on…

At the end of each ticket or periodically throughout the day each engineer checks to see if a higher-severity item has appeared in their assignment that preempts their current task.

Areas For Improvement

I would like to improve the workflow in the following areas:

  1. It is not clear to anyone but the engineer what tasks out of a two-week sprint are currently active from moment to moment or day to day
  2. It is not clear if an engineer has more on his plate than he can handle until late in the sprint, when I look at how many tickets each engineer has left in his queue
  3. There is no way for a customer to see if their tickets are active other than to look for responses or updates to them
  4. There is no way to indicate that a ticket is waiting for a response from a customer

Proposed Modifications

I’m not sure if I want to make changes by adding new ticket statuses to RT or if I want to do it by adding a custom field.  I’ll probably start with a custom field because it is easier to undo scrips or other programmatic logic that I build around it.   My thoughts are to implement a custom field with WIP limits and (possibly) use RT to control those limits.  My initial plan is to implement Kanban features at the individual level, adding the following workflow to tickets after they’ve been assigned to an engineer:

  1. Backlog (tickets assigned during planning meeting or priority tickets that come in during a sprint)
  2. Today (tickets they plan to work on today)
  3. Doing (the ticket or tickets that are in play right now)
  4. Waiting (tickets that are stalled and waiting on something external)
    1. Customer
      1. Approval
      2. Response
    2. Manager
      1. Approval
      2. Response
  5. Done

This system can work for staff in other departments, and it will also promote cross-department communication.  An example is to compare the following two scenarios:

Waiting On A Customer

Current Method

The engineer has finished work on an item and needs customer sign-off before closing the ticket.  They update the ticket to indicate that the work is done.  The ticket stays in an open state and its severity automatically increases each night that it remains open.  The customer is busy and doesn’t respond, and the engineer continues through the following escalation workflow for customer notifications (1 day between items):

  1. Update the ticket
  2. Email the customer directly
  3. Call the customer
  4. Escalate to the account manager to email or call the customer directly (possibly adding an extra day)
  5. Escalate to me (CEO) or my partner (CTO) to communicate with the customer directly (also possibly adding an extra day)

This results in a potential lag of several days before a ticket closes.

Proposed Method

The engineer has finished work on an item and needs customer sign-off before closing the ticket.  He or she sets the ticket to a status of “Customer – Approval” which automatically reduces the severity of the ticket to low and sends an email to the customer that the ticket is ready for review.  The ticket no longer increases in severity each night.  This ticket is also added to the daily report sent to the customer showing the state of all of their open tickets and which ones are waiting for a response or approval.  An aggregate report is also delivered to the account manager, so that he or she can communicate with the customer on tickets that remain open and pending response for more than three days.  After 5 days with no response from the customer, the ticket is automatically closed.

By enabling custom fields or statuses to show the state of the ticket, the following options appear:

  1. Customer can search for (or receive a daily report) for all tickets that are waiting for a response from them, classified by “approval” or “response” to indicate the type of action needed.
  2. Account manager can receive a daily report of all tickets that are waiting on a response from customer or management.
  3. Management can see all tickets that need their help (currently defined as blockers in the daily stand-up meeting)

The processes become part of the daily workflow for the people in each department, or the customers themselves.  In a storm of ticket updates it’s easy to miss the ones requesting a response.  A dashboard or report will stand out from the noise of everything else.

I still don’t know if custom fields or custom ticket statuses is the right way to go.  I’ll probably figure that out along the way.