After a couple of years using Scrum, we recently moved to Kanban. Overall, it has been a very positive experience. Yet, as our implementation continues there are a few, important things we need to keep in mind.
Scrum vs Kanban in brief
Scrum and Kanban are both agile methodologies used in software development. So far, the best way I’ve come across to differentiate between the two is based on the idea of ‘Change Agent’ as explained in this post.
In Scrum, the change agent is the commitment made by the team to complete a set amount of work of a certain quality within a sprint (at Settled, we worked in 2-week sprints).
In Kanban, there are no defined sprints. Rather, the change agent that determines how much work is taken on is the work that is actually in progress. In Kanban, only a limited number of stories can be at the same stage of the development process at any given time. Only when a story is moved forward, a new one can be brought in.
Why we decided to move from Scrum to Kanban
We’re a small cross-functional team and, throughout our company, we try to be as agile as possible.
A few months ago we started noticing that due to frequently changing requirements and the occasional unexpected bug to work on, Scrum was not the best framework for us to use.
If a requirement changed mid-sprint, it was not ideal to pause the development and wait for the end of the sprint to update stories on the basis of the new requirements.
Additionally, we started all of our sprints with a big sprint planning meeting. Of course, if a story was rejected mid-sprint, some of the time invested during sprint planning was effectively wasted.
Planning for two weeks of work can also be tricky. As a team, we got pretty good at it but we would always end up either finishing all the work a couple of days in advance or carrying stories across sprints.
For all of the reasons above… we decided to try out Kanban.
So far it has been a very positive change.
What we like about Kanban
The Kanban way of working feels much more aligned with the way we approach work at Settled.
It allows us to be nimble, make decisions and implement changes with minimum holdback.
? High-priority features are moved forward faster
We allow for stories to be in the development stage for a maximum of 3 days. This means that if we want to start working on a new story which is high-priority, the maximum we’ll have to wait is 3 days. Overall, we aim to release all stories within 5 days.
⏱️ We invest time in what really matters
We only spend time discussing features that are definitely going to be implemented. Long meetings are no longer needed and we don’t spend time discussing features that may end up not being built.
? We have much better visibility of our bottlenecks
When a story is put into the development stage on the Kanban board, we start tracking the number of days it stays at the same stage.
Every day we have a very clear view of stories that are taking longer than expected or development stages where stories are accumulating.
With Scrum, we didn’t have such visibility, as technically every story could take up to two weeks.
? We always have a backlog of smaller stories ready
If there is a small piece of work that we want to pick up, we don’t have to wait for sprint planning to bring it into the board.
? We also kept what works: retrospectives
Scrum worked well for us for a long time, so we decided to keep the elements of it that we liked to most and use them in our implementation of Kanban.
For example, we still do regular Sprint retrospectives, which some call Kanban retrospectives. These usually happen every two/three weeks and give the team the opportunity to discuss what worked well and what could be improved.
We found that these meetings are really important as they allow us to reflect as a team, reset both our minds and the Kanban board, and start working on new stories with a fresh approach.
We switched from Jira to Trello
To manage our Scrum board, we used Jira which is a powerful tool with endless options. Moving to Kanban, Trello felt like a simpler solution to manage our board. We also have a physical board which we refer to in our daily stand-ups. While Trello is not perfect (for example, we still haven’t found the perfect solution for tracking and managing epics), it’s sufficiently easy to use and it’s a nice visual representation of our work.
Things to be careful about
By switching to Kanban our processes have definitely improved, but they’re still not perfect.
After a few retrospectives, we identified some issues we should definitely be mindful of:
? We all have to be proactive about tech discussions
With Scrum, tech discussions where a crucial part of our sprint planning and we would talk through every story in detail. This was especially useful to identify any blockers, share knowledge and plan out the work.
With Kanban, there is no official planning meeting to kick off a sprint. This means that we all have to be aware of when a tech discussion is necessary before diving into the development of a feature.
Most stories we work on are small pieces of work that can be generally planned out very quickly and released within 5 days. For anything more complex, the team is always available for an in-depth tech discussion and, possibly, to break down the story in smaller parts.
? Low-priority stories can be left behind
With Kanban, stories are ordered on a priority basis. This means that some low-priority tasks may be left behind. It’s useful to be conscious of this and work on these type of stories every once in a while.
? No end to the sprint… no team lunch?
In Scrum, the end of the sprint often coincides with a big feature release and a celebratory team lunch. At Settled we still like to have the occasional celebratory lunch, even if releases are more frequent and there is no strict end to a sprint.
We are overall happy with the transition from Scrum to Kanban. I think that this new way of working is helping us to build faster and deploy features more often.
Kanban seems to be especially suitable for teams who enjoy working closely and in a very dynamic way but does require the team to be proactive and have awareness of the process.
Moving from Scrum to Kanban: a positive experience with a few things to keep in mind was originally published in Settled Engine Room on Medium, where people are continuing the conversation by highlighting and responding to this story.