Start where you are now with Kanban

Three weeks ago I started to work at a new client. The first two days at the client I had the chance to coach a bunch of different teams. All with different challenges, though working in the same company, they all got their individual first experiment to start with.

IT Operations

Being bombarded with tasks by the product department, the IT Operation team had to find a way to get an overview of all the tasks demanded and a working prioritization scheme.

VISUALIZE YOUR WORK

First thing we did was to visualize the input queue in their ticketing system. We decided to give the product department a view, where they could see all the things they wanted to be done by operations. Next we created a view for the operations team, where they would the see the top twenty tasks demanded by the product department.

LIMIT WIP

The top twenty tasks would also serve as a limitation of allowed tickets and would be refreshed once a week to start with. We also limited the doing column.

MAKE POLICIES EXPLICIT

Next thing was to agree on and write down policies. The following list shows what we agreed on in no specific order

  • Prioritizing tickets is done by the product teams
  • Tickets must be written in User Story format
  • 2nd level support is done by the “Kanban Duty Hero”, who is announced in the daily standup
  • The input queue is refreshed on a weekly base
  • Daily Standup starts at 09:30

MEASUREMENT

To see whether the changes we implemented would be helpful, we decided to ask the operations team to rate, on scale from 0 to 10, how good or bad they thought the overview of their work was, they felt about prioritization of tasks and how much pressure they currently feel. The idea was to ask the to rate these three things before the introduction of the changes and then again on a weekly base.

IT Support

Consisting of two people the IT Support team is responsible for everything around the internal infrastructure. They serve over 100 people in the company. Tasks include setting up workstations for new hires and traditional support tasks like resetting passwords and changing empty toners. Their biggest challenge, at the time I had been there, was to keep up with the huge amount of new hires and the corresponding need of setting up new workstations.

IDENTIFY TYPES OF WORK, THEIR SOURCES, ARRIVAL RATE AND RISK

Starting by identifying the work types of the team, we learned there were three different types. The first type of work identified we called incidents. Incidents represent work to support internal IT like running the email server, password resetting, making sure the printers are working and more. A work type we called new hires was the second work type identified. This work type includes everything new colleagues need to start working on their first day. Improvements are the last type of work. Improvements represent work the team does to shorten lead time of the first two types of work.

The source of improvements is work created by IT Support therefore internal and controlled by them. Incidents on the other side are external, raised by monitoring systems and people creating support tickets because of issues they might experience. The source of work type new hires was of course the HR department.

Arrival rates were very different. Improvements are under the control of the team and pulled by them as soon as the last one is finished. Incidents come in distributed over the day, sometimes just a handful, sometime less or more. New hires come in randomly throughout the week often in batches.

Regarding risk it was pretty clear new hires had the highest risk and cost of delay would be pretty high if new colleagues would have to wait for their workstation. We assigned a fixed date class of service for new hires. Incidents, had to be fixed as soon as possible. Therefore we assigned a standard class of service for new hires. Improvements were assigned the intangible class of service. Now we had a ranking between the different types of work. New hires would be worked on first than incidents and improvements last. You might think improvements will never be worked on, don’t worry we took care of that, too.

CONNECTING THE DOTS

Let’s remember the challenge IT Support faced. The challenge was to handle the number of new hires next to the incidents. Improvements were targeted at reducing the lead time of work types new hires and incidents. Setting up the computer and all accounts for a new colleague took pretty long. So the first improvement they were working on currently was to improve the way they set up new workstations.

With two people in a team you don’t have many options, but by analyzing the arrival rate and risk dimension of each work type we found a solution we wanted to try.

We decided that new hires had to be worked on at every point of time. That way we would reduce the waiting time for new hires to a minimum. This could and would be done by one person of the team. The other person of the team would take care of all incidents coming in. The number of incidents would never keep that person busy so that he has enough time to work on the current, limited to one, improvement the rest of the time.

By agreeing on these policies, visualizing the work with a very simple board and measuring throughput of new hires, IT Support knows what how much work there is and make better decisions on what to work on next. It’s also assured they are working on improvements and focus on one at a time. Furthermore we hope it leads to the possibility to tell HR department whether the agreed entry date of a new colleague will be manageable or should be moved to a later date. This would save money and allow the new colleague to have a nice start.

Quality Assurance

After the IT I had the chance to talk to the QA guys. There were working in project, where there used Kanban boards already. Though the implementation was very shallow.

I talked with QA about their part of work inside the project. I must admit I don’t remember what exactly there problem was. What I remember is we decided to start measuring lead time on their most important work type. Additionally they would mark blocked tickets and collect the blockers. Our plan for the future is to analyze the blockers and see where the system can be improved.

On a side note

I also talked to the developers team lead. We agreed on things, which had nothing to do with Kanban. That’s why I will not tell you anything about it, but mention it because it is yet another solution although part of the IT department.

I also talked with one of the project managers. She surprised me with an awesome Kanban system. I was still able to help her, but didn’t take any notes while doing so, so I can’t tell you any specific details.

The Future

All the teams I worked with work in the same workflow. I think they know that more and less. My goal is to connect them one by one to get them on Kanban flight level 3. Though I think it will be a tough challenge I’m sure we will get there sooner or later.

I will write more about it as soon there is something to share. So, if you are interested in learning more about the journey I just started with them stay tuned.

I’m always happy about your thoughts so please share them with me in the comments.

3 thoughts on “Start where you are now with Kanban

  1. Thank you for sharing this.
    I’d be interested to see the board.
    I’ve thought about using Kanban type methods for IT ops but have been able to settle on a model.

    How would your implementation handle urgent requests, either urgent incidents, outages etc, or urgent enhancement or project tasks?

    • Hi Matt,

      sorry for the late answer. Sadly I don’t have a picture of the board. Though it was a very simple one. Nothing special. I’ll be at that particular client again end of the month and see what happened to the board. Maybe I write a follow up.

      TRUE urgent requests (outages) take the fast lane. They are way to expensive to have them waiting in queue. If you have a lot of urgent ticket you should try to identify the cause and talk to the inquirer.

  2. Great article! I have spoken in a few forums about the “tribal-mashups” that Kanban facilitates – between Design and Development, between Product Management and Engineering- and this article is good one for collaboration between Dev and Ops in IT.

    One of our customers had previously published a blog on their experience with Kanban in IT Ops, that you might find useful – http://blog.digite.com/kanban-in-it-operations/

    To respond to Matt’s question, I would think using David Anderson’s (and others’) “class of service” model would be a good way to define different swim-lanes on the Kanban board for different ticket categories – and set WIP limits on each (such as no more than 1 Urgent tickets at a time) in order to help with load balancing between different types of work that the team does. We do that at Digite/ SwiftKanban (www.swiftkanban.com) for our own support work – and it works very well.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>