Early in 2024, we decided to finally pull the trigger on our switch from the scrum-based Agile methodology to a Kanban workflow. It was one of those things that we had talked about for a while and it made sense to everyone. Still, we never quite worked up the guts to actually make such a significant change, simply because working in sprints has become the de facto standard of most teams in Spendesk and the technical landscape generally.
For a bit more context about us, our team is responsible for ensuring that companies using Spendesk’s services comply with our KYC and regulatory requirements. This means that we are typically a service team for core product, compliance, and business demands. So even though we plan our product roadmap over a period of time, we have to remain interruptible to sudden more urgent requests from compliance, legal requirement updates, or business changes.
How Scrum worked for us (until it didn’t)
Until 12 months ago, we followed a scrum-based methodology, organising work into two-week sprints centered around a sprint goal. The purpose of scrum is to achieve a project goal by breaking it down into smaller, more manageable sprint-sized tasks. By using story points to estimate effort, teams can, in theory, gauge how much work they can complete in each sprint. This should lead to greater predictability over time and more accurate project completion estimates.
The unique thing about the Scrum approach is that the team has to commit early to executing a fixed batch of work over two weeks and then sprint to execute it. Multiple sprints patched together contribute to the delivery of a major project. The idea is for the the team to attempt to accurately estimate how much work we can deliver in a Sprint, and then strive to complete all the selected work within the period.
The Kanban style favors a continuous flow of work through the team’s planning and production process. So, rather than small, repetitive sprint cycles, we have a steady pipeline of work flowing like an assembly line.
Over time it became increasingly obvious to us that our reality seemed much closer to Kanban for reasons I’ll share below.
The 3 biggest challenges we had with Scrum
Disruptions from urgent interruptions
Typically, we’d have major goals or projects that we plan to execute over a period - say 3 to 6 months. This is where Scrum shines because planning is easier when you split the work into sprint-sized batches and deliver incrementally. However, our team rarely has the luxury of focusing on a particular project for over a few weeks before getting interrupted by an urgent business or regulatory need. So rather than having a cohesive link of 4 to 6 sprints focused on achieving a significant milestone in a project, we end up having patched sprints where we jump from one topic to another and back again maybe. To make it even worse, in an attempt to keep a project’s stream of work flowing, while also dealing with an urgent interruption, we’d end up with individual sprints containing tasks from unrelated topics. Making the sprint goal a bit of a joke and inevitably leading to the dreaded team silos
💡 Team silos: Also known as teams in a team. You know there are silos when you show up for standup and almost everyone else’s update sounds like gibberish to you, and you just about sense everyone tune out when you’re giving your updates.
Carryovers became the norm
The scrum principle requires the team to commit early to delivering a batch of work within a sprint period (2 weeks for us). The idea is to estimate how much work can be accommodated within a sprint by estimating the effort for each task with story points during sprint planning sessions (a.k.a. refinements).
💡 Story points: This is a somewhat gamified way of estimating the amount of time needed to complete a task or feature (a user story). It’s done by assigning a number to a story from 1 to 13, with one representing a simple task requiring the lowest possible effort and 13 a complex task requiring the maximum effort.
Eventually, the goal is to fill the sprint with tasks (or user stories) up to a maximum number of story points (say 40).
Unfortunately, all this relies on an assumption and probably the biggest myth about software engineers, that we can accurately predict the amount of time and effort a task will take before we get started on it. Stuff always comes up when you get started, stuff that you didn’t anticipate in your planning. So as long as the amount of work to be done is fixed, and the engineering capacity available is also fixed, then time has to adjust.
Ever so frequently, the work expands beyond the 2 weeks and is carried over to the next sprint. When this happens continuously, it begins to feel more like a flow of work, you know, just like Kanban.
Sprint cycles were not relevant to hard deadlines
Previously, I explained how sprints use a maximum number of story points estimates to achieve predictability, allowing the business to anticipate when features or projects will be completed. However, as we’ve discussed, estimates are rarely precise, and sometimes wildly off. Unfortunately, the other side to this is that business deadlines are often inflexible, as they are typically driven by far-reaching real-world implications.
However, business deadlines are not often adjustable because of real life far-reaching implications.
So what typically happens is that work flows at different rates. Close to a deadline, tasks move pretty quickly through the workflow, engineers stay up till late, superfluous requirements get cut and everyone is at max output. At the beginning of the project, tasks move more slowly while there is high ambiguity, plans are still getting refined and everyone is a bit more relaxed.
Scrum doesn’t account for a team’s different flow rates. It assumes a world where engineers are always working at an average level of output, but the reality is different for our team and indeed most product-focused teams.
Why Kanban was a better fit
Eventually, making the switch to Kanban was much smoother than we imagined. Thinking about at it now, I realize we were forcing the Scrum ideas to fit a way of working that was not suited to it. I think a lot of teams do this as well.
On the other hand, we’ve gained a lot from adopting Kanban principles, particularly, the idea of setting work-in-progress (WIP) limits.
💡WIP limits: Limiting Work in progress is a key principle in Kanban. The idea is to set a hard limit (we use 5) on the number of tasks in progress at the same time. This limit helps narrow the team focus on a small amount of tasks per time
Setting hard limits on the number of tasks in progress at any time forces everyone in the team to concentrate on a single topic at any given time. As a result, it’s led to a dramatic increase in collaboration and team engagement. Where we had silos of individuals working on separate things, now we have a more cohesive team effort that has led to improved solution design, collaborative implementations, and faster reviews.
The continuous flow style has also helped us integrate urgent interruptions naturally into our workflow, rather than seeing them as nuisances to avoid. Our product manager has found this especially helpful! 🙂
How we made Kanban work for us
That said, Kanban is not the silver bullet solution either. Even though it aligns more with our team’s ways of working, the continuous flow style also has some disadvantages. We found that there were some useful elements of Scrum we wanted to keep, which I’ll highlight below.
A regular cadence of reviews
While we ditched story pointing, estimates, bi-weekly sprints, and sprint goals, we maintained the concept of bi-weekly reviews (borrowed from sprint reviews) because we wanted to maintain a regular cadence of looking back after a short period to assess our progress, bottlenecks, and potential improvements.
This is particularly useful for periods when we don’t have the motivation of a looming hard deadline. With a continuous flow, it’s easy for the team to lose track of progress, slide into inefficiencies, or pick up low-value work. So having regular reviews is one way to keep ourselves accountable.
Rate of flow metrics
We found it useful to track the rate at which tasks flow through the cycle. We do this by measuring how many tasks we could complete every 2 weeks. This borrows the Scrum idea of tracking work within short cycles but removes the need to commit to executing a fixed amount of work in that cycle.
By measuring our flow rate and revising the results regularly we can identify issues in the different parts of our process that may be slowing us down. Over time we’ve implemented changes to our planning and ways of working and it was super helpful to have a metric to see how our changes impacted productivity.
Fluid road map planning
One challenge with the continuous flow style is that it’s easy to lose track of the big-picture timeline for the different projects the team is involved in. This is particularly true when the team has more than one project in the pipeline or when there is a hard deadline on a project’s delivery date.
With road mapping, we can visually define the 3 elements of project management;
💡 3 elements of project management
- Engineering capacity available
- Scope of work to be delivered
- The time available
The road map helps us visualize the 3 elements when planning so we can figure out what needs to be adjusted to achieve our definition of success.
Reviewing our progress on the roadmap and making adjustments as we progress gives us the best chance of hitting our targets, for example, when there is no allowance for extra time with the deadline for an important project, we borrow engineers from other teams to beef up our capacity. Other times when an exceptional user experience was required, we’ve made a clear case for a time adjustment, or when it’s critical to just get something out the door we’ve adjusted the scope of work to deliver the barest minimum MVP version.
Summary
In summary, switching to Kanban has not only helped us adapt our way of working to be more closer to the demands of our reality, but it has also helped us improve our process. Incorporating Kanban ideas like limiting work in progress has helped break down silos and improve collaboration. For further reading, I’d recommend the book Kanban in Action by Marcus Hammarberg, it was a great guide for our implementation. Next up for us is to revamp our team’s North Star metrics. Can’t wait to tell you all about it.