“We’re doing Kanban instead of Scrum, yay!” “No sprints, fewer meetings, no stupid planning...”.
Many developer teams hate Scrum and the difficult practices that come with it. Kanban looks so much easier from the outside, but for Kanban to work really well, you need even more discipline than in Scrum.
It is important to know the differences - both from a team efficiency and motivation perspective. So let us clarify a few misconceptions.
Why many teams consider a move to Kanban
Here are some common reasons for teams to switch from Scrum to Kanban:
- Nobody wants to be the Scrum Master and organize meetings - “so, let's switch to kanban where there is no Scrum Master and no meetings - problem solved!”
- The team fails to deliver on the sprint content and the sprints keep spilling over to the next sprint. “That means Scrum and sprints are pointless - let's remove them - problem solved!”
- There are so many long and boring meetings in Scrum. “Sprint planning takes hours and is totally useless, and sprints fail all the time anyway. Daily meetings take an hour. The demo at the end of the sprint is meaningless as only the team is present - let's remove the ceremonies and do Kanban - problem solved!”
If these are your reasons for considering moving to Kanban I have some bad news for you: life is not going to get much easier on the other side of the fence.
Let us look at each of the above “reasons” in turn.
Not needing a Scrum Master
The Scrum Master helps the team to do good Agile, helps the product owner manage and refine the backlog, and keeps an eye out for things that the team should improve.
Kanban teams need these things too.
In fact, because Kanban teams lose the sprints, they lose the discipline required for internal deadlines for planning, demos and retrospectives. This makes it even more important that someone takes ownership of this being done.
Failing to deliver on sprint goals
The team can feel bad when it fails to deliver on sprint goals, and the items move to the next sprint. Therefore, if we remove the sprint limitation, we should be able to work until work is completed, and then feel better, right? Yes, that is true.
On the other hand, Scrum sprints are short because they:
- promote splitting work into smaller chunks (which leads to better quality and visibility on progress)
- promote planning to avoid overloading people (velocity-guided sprint loading)
- provide an artificial deadline to complete work
- provide a feedback cycle that the rest of organization can understand
By losing the above effects, you can actually end up hurting the team’s performance.
Rather than blindly moving to Kanban, first discuss why your sprint goals are not achieved. There can be changes that the team can try first, such as:
- improving work splitting (in refinement or separate splitting squads)
- improving Definition of Ready and Definition of Done
- improving backlog refinement
- analyzing what surprise work impacts the sprint (and book capacity for it or improve communication in the organization to avoid surprises)
- Investigate reasons for unplanned or ad-hoc work. Is it because of high and increasing technical debt?
The team should consider the above, internal factors. Is the reason for unpredictable sprints coming more from internal reasons, or external? Maybe the team is close to customer support. Maybe the team has many products to support in production. Maybe the team’s work consists of refactoring and bug fixing.
These kinds of external factors that make work unforecastable are solid grounds for considering the move to Kanban. But many teams blame these external factors too easily, and forget to even try to improve the internal reasons listed earlier.
Long meetings
Do your Scrum meetings take too long? Here is how long they should be (adapted from the scrum guide for a two week sprint):
- Sprint planning - 3-4 hours
- Daily meeting - 15 minutes
- Sprint review - 2-3 hours
- Sprint retrospective - 1-1.5 hours
In addition to the above, the team should spend time on backlog refinement. My recommendation is to have a one hour weekly refinement meeting, and see if this is enough. Make the meeting longer or shorter as needed so that you can refine most stories before sprint planning. Individuals (a Product Owner and team members) should prepare stories outside the meeting as well.
Retrospectives and Reviews
Kanban teams still need to do retrospectives regularly. Stopping retrospectives completely will lead to a bad team spirit, stress and problems not getting addressed. In fact, because Kanban teams do not do sprint reviews at all, you need to emphasize retrospectives even more. Spending slightly more time on retros would probably benefit most Kanban teams.
Daily
Dailies make sense for Kanban teams too, so no change there.
Demos
Demos could be arranged some other way. In my experience, it makes sense for Kanban teams to have a monthly demo. The list of things to be demonstrated is longer, so you risk participation fatigue.
Don't forget that you can always demo each ticket, especially if the ticket is very important to the requester.
Planning
Kanban teams could skip planning altogether. I tried this in the Scrum to Kanban transitions that I attempted. The result?
After a while I found that the team was totally lost. They did not understand the big picture, and were not interested in anything other than their own ticket. I started to call this “ticket blindness”. It can lead to suboptimal problem solving.
In my experience, I would recommend that even Kanban teams do some planning to keep everyone on board and have a chance to clarify product vision and release visions ahead.
So does Kanban save a lot of meeting time?
In summary, Kanban saves a little bit of meeting time. But, the freedom of “no sprints” is not without cost. Getting rid of some meetings adds risks and challenges in other areas.
Should you consider a move to Kanban?
I am not saying I don’t recommend a move to Kanban. I did it twice in my career, and both times our team spirit and output increased. Kanban can be more fun and create more output. But you have to consider many things before you make the switch. As a rule, most teams should learn and practice Scrum first, and then experiment with Kanban if it seems interesting. For many teams, Scrum is the better choice.
Kanban does not relieve you from having a Scrum Master or planning meetings. Kanban teams have to replace the discipline of the Scrum sprint with other agreements like item size limit, scheduled demos and retrospectives, and regular planning.
So yes, you do get more freedom. But with this freedom you have to add discipline of your own.
Published: Mar 21, 2022
Updated: Aug 11, 2022
