Nikolay Sturm's Blog

Musings about Development and Operations

Kanban in Operations - 10 Months Later

| Comments

10 months ago we introduced Kanban at work. This is a short status update on our journey.

The most important change we see, is a vastly improved focus on finishing work. Unfortunately we don’t have numbers to back this up, but everyone on my team agrees that the kanban board with its WIP limits and visualization of work helps immensely. There is a downside however, some people see this as additional pressure. Work is no longer hidden, but always clearly visible on the board, so people see what needs to be done next and cannot just slack as easily as in the old days.

Our board changed almost every month, as we optimized the design in our monthly retro meetings. I spare you the details, but we still use a pretty basic design with columns Backlog (MMF or Milestone), Planning (MMF -> Tasks), WIP and Done.

Being a sysadmin team, we often have people come to us, asking for implementation of some small project that still takes time to do properly. In the old days, we would just take the project and try to implement it on the side. These days, we have a prioritized project backlog and ask people to join in a discussion on our kanban board about where their request fits in. Interestingly, most people don’t take this opportunity! I consider this a good thing, as it helps us focus on important projects instead of nice-to-have ones. When people do come to our board, they see what else we have in our pipeline and usually agree to some sensible prioritization.

Historically we never did much project planning, so when we introduced Kanban, we started with ad-hoc planning. We ran into several issues with this approach:

  • At our company, people can work from home some time of the week. With only a physical kanban board, they had a hard time figuring out what to do next.
  • We had no place to store project artifacts.
  • There was not enough information on our post-its for people to actually having an idea what the card was about.
  • Management began asking questions about project performance.

Most of these problems where addressed by amending our physical kanban board with an issue tracker called redmine. This allowed us to store much more information with an issue and finally led to a point where we even were able to estimate t-shirt sizes for our tasks and delight management with some kind of sensible reporting (keeping it as minimal as possible). We are still looking for the sweetspot of electronic issue tracking, however. How much information can and should we collect in the issue upfront and how much information should be pulled by the worker on demand?

Besides redmine we have a legacy ticketing system for user requests. Infected with the pull virus, we applied some minor changes that allowed a quasi-pull workflow when dealing with requests. Before, each new ticket was assigned to one person and then pushed elsewhere if necessary. Now we can easily see which tickets are not being worked on and pull them in case of a bottleneck.

A side effect of all this was my introduction to systems thinking. I only started exploring this field recently, so there are not many results yet. It was reassuring to see, though, that our failure demand is usually around 10%.

Despite all the positive effects, we are still struggling with commitment to the Kanban way of working. Practice still heavily depends on a champion being around.