The Three Months We Stopped Pretending: A Kanban Story

My team was doing Scrum because that’s what all the cool kids were doing. Then, on a Monday planning session we were struggling to fit a list of unrelated tickets into a 2 week planning, then I heard the infamous affirmation: “this ticket is a priority and needs to be delivered by Thursday”. I had heard it so many times before, but this time I had enough and I realised that this was no longer a Scrum process, it was a mix of a bullet list of objectives and wishful thinking. Looking from outside, it looked like a Scrum methodology, the planning was there, the review, the grooming, and retrospective were there, we meet daily to do stand-ups, but these had become just part of the week, without adding the value they should, and everybody was ok with it, nobody said anything. So I said it wasn’t working.

When Scrum Becomes Theater.

Scrum was meant to be used to provide incremental iterations of a feature or project until its completion. For each cycle, usually 2 weeks long, there is a clear objective, and the progress of the product can be seen clearly. That was not the case for my team; What we had was a selection of unrelated tasks that may or may not fit in the sprint. Defining an objective was difficult because the team was expected to deliver 5 different unrelated things in a sprint. This led to an array of problems inside the team, as it will be described next.

The team had deadlines within the sprint.

Often, during the planning, we would hear things like “this ticket needs to be delivered by the end of the first week of the sprint”. I pushed back on this multiple times, explaining that in Scrum, everything is due at the end of the sprint. If we deliver all tickets on the last day of the sprint, it’s a huge success. Priorities became about which tickets we would address first because they needed to be ready mid-sprint.

One sprint goal is not enough.

Most teams have a bulleted list with up to 10 items as sprint goals. I never allowed my team to do it, and always pushed for a consensus about the most important feature we had to deliver during the sprint. The reality was that we were indeed doing multiple things at the same time and being accountable for delivering them all.

Given the nature of the work, the sprint scope kept changing.

The team was working with new approaches to fix the user experience and measuring the results in the process. Sometimes, after deploying a new feature and having it running for a few days, the product team decides to try a different approach, but doesn’t want to lose time. So, we had to stop some of the planned work to address the changes to the experiment. This was natural in the process, and one clear sign that sprints might not be the best choice.

Using sprint metrics to measure performance.

With all this chaos, the team’s delivery was inherently inconsistent. But the company was still measuring our velocity and holding us to it. I’ll not go into the discussion around measuring performance via sprint metrics, because that’s a long topic. So, the team was constantly feeling the pressure of under-delivering from the company’s perspective.

The team didn’t celebrate success.

Since consistency was not possible, and work kept changing mid-sprint, most sprints ended with hanging tickets that needed to be implemented in the following sprint. This kept the morale low in the team, because sprint after sprint, the team didn’t see any reason to celebrate, because it didn’t feel like success. But the team was delivering valuable work, and commercial metrics were impacted positively.

The team was trying to game the metrics.

In a classical move, when the metrics start to act against you, and it starts to feel unfair, the team starts to think about clever ideas to not be affected by it. One example was once a story that was already closed had a bug, and the team had to re-open it. There was some resistance from the team because the task would not be done by the end of the sprint, and this would impact the metrics.

Given these symptoms, what’s the diagnosis?

I’m a strong advocate for processes; they help to structure the work and keep the team focused. But I think that processes should work for people, not the other way around. As soon as we started to fight the process, trying to go around it, with gaming metrics, the process failed. All the symptoms mentioned above are signs of a failing process.

So, where do we go from there? Do we keep fighting the process and hope for the best? I don’t think that this is the best approach, because we’ll keep hurting and trying to work in a way that doesn’t fit the work we are trying to do. I think the best approach is to try something different, as an experiment. This means that the change needs to be measurable and tracked during its execution.

The switch Scrum –> Kanban.

My proposal was to switch from Scrum to Kanban to try to solve some of these problems. Unlike Scrum, Kanban doesn’t have sprints, so we didn’t need to try to fit the work into 2-week intervals. We also had the opportunity to re-prioritise the work, and the next free engineer could pick up the most critical ticket at that time. We kept the most important constraint of Kanban, aiming to have at most 1 ticket per person in progress.

Changing the process mid-year, with everything running, required some work as well. The first step was to come up with metrics. I choose to measure ticket throughput, besides our commercial targets. I was also measuring the developer experience via informal talks. I also came up with an exit strategy, in case Kanban was proven to be the wrong choice, I had a plan to go back to sprints and continue from where we stopped.

I started by discussing my proposal with the product manager, as we were both responsible for the team and worked closely together. After getting their ok, I pitched the idea to the team because, in the end, they would be the ones using it on a daily basis, and they agreed with the idea as well. After that, I presented the idea to my manager, the senior engineering manager, and the group product manager, who was the PM’s manager. Finally, I also discussed it with the director of engineering in my skip-level 1:1. After getting approval from everyone, we made the switch.

What changed after flipping the switch?

Having a plan and the stakeholders’ agreement, I started to make the actual change. First thing was to configure a new board in Jira to track the Kanban tickets, followed by some process changes. Everything will be detailed next.

No more backlog view.

Scrum has a backlog view with all the tickets, and a sprint board with only the tickets that are planned for the sprint. Since Kanban doesn’t have sprints, the backlog view ceases to exist, and all tickets are shown in a single board. To make it easier for the team members to find relevant tickets, they were sorted by priorities, and there were swimlanes for each epic/project. The other immediate change was to show alerts in Jira if there was more than 1 ticket per person in progress.

Planning meetings moved from bi-weekly to project kick-off.

Instead of having planning meetings every two weeks, we started doing them ad hoc when needed. Project kick-off was a good moment to do planning related to that specific project. And the planning was more focused on dividing the work and planning the execution, not trying to fit it in a specific sprint timeline. The same for sprint reviews, they were not needed anymore. We did reviews for the projects.

We stopped estimating tickets in story points.

Another common bad practice during the Scrum time was to map story points <–> time. I heard multiple times people saying something like “If it’s 2 story points, it should be ready this week, maybe in a few days”. This led to a lack of clarity, double measuring, and pressure. Moving to Kanban, story points don’t make sense anymore anyway, so we started using t-shirt sizing to measure effort, and the sizes were mapped to time in order of magnitude (e.g., S is around a few days, M is around a week, L is around a sprint). I was explicit in explaining that these are approximations and not to be taken as commitments.

Measuring delivery.

The final change is that burndown charts and velocity charts don’t exist anymore, and we started measuring ticket throughput.

After the change.

After one quarter of doing Kanban, we went back to Scrum, not because the Kanban failed, the numbers show clearly that it worked. We went back because the conditions changed. We had a new PM who brought product clarity, the work became more predictable, and the team had learned to scope stories properly during the Kanban period. Scrum made sense again. Even after returning to Scrum, the numbers kept improving, signalling that by getting some distance and experimenting with alternatives, the team actually learned to work in a more structured way.

But the impact went beyond our team. Other EMs in the track came to me and asked for my help in switching temporarily to Kanban when they were in a similar situation as my team once were. By doing this experiment, I opened a door that was previously closed: the idea that the methodology needs to work for the team, so it needs to be adapted.

What the numbers showed

After one quarter of Kanban, I pulled the data. The results were clear, but not in the way I expected.

• Median cycle time: 20 days (Scrum before) → 10 days (Kanban) → 6 days (Scrum after)
• Story cycle time: 38 days (Scrum before) → 14 days (Kanban) → 8 days (Scrum after)
• Story throughput: 8.5/month (Scrum before) → 13.2/month (Kanban) → 15.0/month (Scrum after)
• Bug ratio: 33% (Scrum before) → 5% (Kanban) → 2% (Scrum after)

I expected the drop in cycle time, switching to Kanban meant no time waiting for the next planning. But what caught me by surprise was the decrease in the number of bugs, it went from being a third of our efforts to only 5% during the Kanban phase, dropping to 2% after coming back to Scrum again. The team started building features instead of constantly fighting fires. This changed the morale in the team, engineers felt more confident and more motivated.

Throughput stayed roughly consistent at 22-25 tickets per month, which was what I was aiming for. I wanted the change to improve how we work, while not preventing us from delivering value in a similar cadence. The real change happened at story level, the story throughput increased from 8.5/month to 13.2/month, and later to 15/month. The team was better at breaking down the work, while delivering with quality.

Going back to Scrum with these new habits meant we had the best of both worlds: the structure of sprints with the flow discipline we learned from Kanban. And we were doing it because it worked, not because all the cool kids are doing it.

What people have said

One of the engineers on the team wrote about it in their feedback about me: “You were agile in introducing Kanban, breaking down tasks based on effort, and when we switched back to sprint you stepped up further.”.

The PM also shared his feedback: “You helped both team and the PM set up a process which allows the team to start delivering new functionality while having clear expectations about timeline”.