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.
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.
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
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.
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.
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.
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.