Kanban from the trenches; Lessons learned (Part 2)

On my previous post about Kanban, I presented the challenges we had in our Engineering team. They were:
1. Uncontrolled growth of Work In Progress.
2. Not Enough visibility.
3. Reduced quality.
4. Inability to properly estimate all tasks upfront.
5. Planned features and improvements are hard to manage and implement.

During the implementation of Kanban we focused on solving those problems.

Implementation

We did a 2 step approach, first we had an online shared spreadsheet, then we moved everything into Jira (our issue tracker).

Online Spreadsheet

We started with the online spreadsheet because we needed to have something really flexible. The goal for the spreadsheet was just make things visible. Once things became visible to the Engineering and the Support team, it started to become clear the basic workflow we were following for our issues. We were able to know which tasks we had open, which ones we were working and the ones we closed. That also helped to simplify our release process, in particular to know what was solved since the last version.

Even with just the online spreadsheet, we started to feel things were different. We were already focused on the most important issues, and trying to solve them as soon as possible. It was time to move forward with Kanban

Using Jira

I spent some time configuring our jira workflow, the task board and dashboard to accommodate our current needs. I think it got to a point were it became really useful to us. I reproduced the basic workflow we followed for most of our issue types, by defining the transitions. I created a new version to be used as the Engineering Backlog. I added many built-in metrics from Jira to that particular version. I configured the Task Board to work as our Kanban board, and introduced limits to each of the steps to control WIP.

The dashboard became an important tool. It not only showed us what was happening, it also showed us there were a large amount of really old unresolved issues. It triggered a big review of all the existing issues. In a collaborative effort between Support and Engineering we were able to clear many old issues which were no longer problems to our clients. That allowed us to close or relocate issues to reduce our backlog in about 60~70 issues. That was a big help in terms of the time invested in prioritizing the reminder issues. All in all within the first 2 months since we implemented Kanban, we went from 170 issues in our backlog to only 60. I know, seems like magic, but we know it’s not. The magic at this point was just exposing an existing problem. Solving it took a lot of effort.

I will not go over everything we track in the dashboard here, but I will highlight a metric that caught my attention. We measured the Created vs Resolved issues over the last year. Once we started tracking things in jira, you can see how clearing the backlog, and having a team focused on solving a limited amount of issues helped us. Our focus is to be able to completely clear the backlog, and get to a point of being able to tackle issues as they appear and provide the fastest turn around possible.

During this time, everybody was exited and wanted to keep tackling issues, that seemed to be the right way to go. There were guys saying, I think I fixed the issue I was working on, I will take another one while I run the tests. That was our first attempt to solve more issues in less time. We agree only to do so, if there was still and open slot in our board. There were some times where they felt blocked by this limitation, thinking they were wasting their time. We then realized, whenever we are blocked by the WIP limit, work or think about improving the flow. Getting more tasks to work at the same time, was actually the opposite of why we implemented Kanban in first place.

We also used the task board from Jira  as the Kanban board. It’s in particular important when we do our daily calls between the Engineering and Support team. It helps everybody to have visibility over the process and status. What we are doing, what is blocking us and mostly important, how we can help each other. That improved greatly the communication between the two teams, and usually we see ourselves working together as a single team. Going over the open issues daily, kept everybody focused on the WIP we had, and not being distracted by other stuff going over around.

We also used the task board on the prioritization weekly meeting. That meeting aimed to see what was done, and if there was any empty slot on the selected column, we would be able to fill it with a new item. I also used here a feature from Jira, that would let us know if we run under a minimum amount of issues in the selected column. That would trigger an on-demand prioritization meeting. In this way, we would never run out of issues to be selected by the development team. It is a visible improvement the way how we were able to discuss and agree on what will come next.

What’s next?

I guess we are done with the first phase of implementing Kanban. We quickly experienced many benefits from it, which I can highlight:

• Controlled WIP. This was the major source of problems up to this point.
• Focused team: Issues are being tackled and closed faster than ever.
• Greatly reduced our lead time.
• Reduced backlog. The smaller the backlog the better.
• Improved visibility to other teams. Through the shared dashboard and the kanban board.
• Increased Quality. By just focusing on a small number of issues, allowed us to improve the quality of the work done for each.
• We do not care much about estimating now, as we clear issues before they become a problem. I will explain more in this in a future post.
• Easily manage new features or enhancements. If they get to the selected column, they will get done.

We are at the point were we need to work on improving our lead time, and reducing the sources of variability. These are the main goals of Kanban. We will start reducing WIP and work on the bottlenecks as they appear. We need to generate slack to allow us to work on improving the flow, that will be a way to improve our process.

If you are implementing Kanban in your company or team, I would love to hear from you. What is working, what is not, or questions you might have.