Scrum VS Kanban
Scrum and Kanban are both agile frameworks that are used to deliver software, or any other sort of project for that matter, in an incremental and iterative way. Both terms have become incorrectly interchangeable. Although there are many similarities between the two, understanding the key differences between both Scrum and Kanban will bring clarity.
As with all agile frameworks, we have a product owner, a development team and an intermediate person, known in Scrum as the Scrum Master and in Kanban he or she is known as the Agile Coach.
All three work together to get the most value to a client in the shortest amount of time. Work is divided into stories and those stories are put on a product backlog. So far, so good, both Scrum and Kanban do the same at the very basic level. The way both handle these stories is where the difference lies.
A Scrum team works in Sprints, a Time-boxed period in which the development team delivers a new iteration of the product. Most commonly these Sprints last 2 weeks, although 3 or even 4 weeks Sprints aren’t a rare sight.
Each Sprint start with a Sprint planning meeting. In this meeting the development team, Scrum Master and Product Owner decide which stories the development team will tackle during this Sprint. These selected stories are known as the Sprint Backlog. This backlog should not change during the Sprint.
On a daily basis in the Sprint, there is a Daily Standup meeting, a 15-minute standup meeting in which every member of the development team answers three simple questions: ‘What have I done yesterday’, ‘What will I do today’ and ‘Are there any problems that block me in going forward with my task’.
After a Sprint there are two rituals; the Sprint review meeting, where all stakeholders are invited to a demonstration of new functionalities added to the product; and the Sprint Retrospective meeting, in which the development team discusses what went well, what went wrong and what could be improved in the next Sprint. The goal of the retrospective is to improve the way of working in the team in comparison to the previous Sprint.
Some pitfalls of Scrum
Let it be clear that Scrum isn’t as easy as it seems, Scrum has its pitfalls. Most of these can be avoided by making these issues clear from the start of a project. Some examples are:
The Product owner not being available for questions of the team
When a Product Owner is always in meeting, or otherwise engaged, it could happen that the development team has to wait longer for answers on their questions, and by waiting for answers blocking development.
Extending the Sprint with just a couple of days
Some teams will try to delay the end of a Sprint by a couple of days, just to make sure everything is ‘Done’. Every item that is not ‘Done’ at the end of a Sprint goes back into the Product Backlog. No exceptions. Extending it by just a couple of days would create a desync in the rhythm and possibly create a desync with another team that depends on your team.
Changing the Sprint length
Changing the Sprint length during a project is just not done. It will disrupt the team’s flow and the velocity of the team will go down. Once you’ve chosen a Sprint Length, your team should stick to it.
Not having the same Sprint rhythm as another team
In larger projects, teams will be dependent on one another. Not having the same Sprint rhythm will cause issues because you’ll have to wait for the other team to be ready for you, or vice versa, which would once again block progress.
The Scrum Master being too involved
A Scrum master is a dedicated role in the team. It is very hard to be a Scrum master and develop at the same time. He or she should be like a firefighter, be idle at times, but be ready when an emergency occurs.
Trying to solve problems within a Daily Standup
The Standup has to be a short time boxed meeting. Answering the questions and going forward. If there are problems, they should be handled before or after the Standup, not during.
Kanban is a continuous process. There isn’t a Sprint backlog. Only the columns on the board and the prioritized product backlog.
The Kanban Board is crucial within Kanban. It is usually split into three columns: To Do, Doing and Done. More columns can be added to fit your needs but those three have to be there.
To limit the work that can be done there is a Work in Progress limit on every column on the Kanban board which is related to the team’s capacity. For example, a team of four developers would be able to handle 6 to 8 stories at the time. The lower the limit, the faster work will pass through the board. Having it too low though will result in a bottleneck situation.
Kanban has a Daily Standup meeting, a 15-minute standup meeting in which every member of the development team answers three simple questions: What have I done yesterday, what will I do today, are there any problems that block me in going forward with my task.
Demo meetings are held at regular intervals. During these meetings all stakeholders are invited to a demonstration of the new functionality since the last demo.
Kanban also has retrospective meetings, which have the goal to improve the way of working of the team and solve any issues that have risen since the last retrospective.
In Kanban there are multiple ways you can do retrospectives. One way would be to do them on a regular basis (bit Scrum like). Although this doesn’t fit in the Kanban way of working, this provides a welcome disruption of the daily workflow and if conducted well the retrospective will result in a morale boost for the team since they have been listened to and know problems they have will be handled or have been handled during the retro.
Since having retrospectives on a regular basis kind of goes against the way of working in Kanban, a simpler way of holding retrospective has been popping up the ‘Stop and Solve‘. This means that every time there is an issue (that the person who encountered it can’t solve on their own), an immediate retrospective involving the full team is called. Everyone looks into the problem, and brainstorms for possible solutions until a solution is found.
There are pros and cons on both ways of working; what is chosen depends on the team.
Some pitfalls of Kanban
Like with every framework, Kanban has its pitfalls. Some examples:
Kanban board not being up-to-date
One of the most important pieces of Kanban is the Kanban board, if that is not up-to-date it will result in the team not having a up-to-date view of what needs to be done. You would be looking at the past.
Not keeping to the WIP limit
Having too much tasks in one column will reduce the overview the team has, and tasks will get ‘lost’. A solution would be to implement physical limits to the board by drawing a line.
Is there a Holy Grail?
The answer to that question is quite simply: No.
It all depends on the situation you’re in. Scrum would not work for teams that do not have clear business requirements. What we mean by that is a systems team or a helpdesk team. Kanban would be way more useful for these sort of teams; high priority tickets appear on the backlog and are handled as fast as possible by the team.
An advantage of Scrum compared to Kanban is that the business will know what will be delivered during the next Sprint.
Kanban is more dependent on the incoming requests.
As said before; it all depends on the situation you’re in. Analyze the situation before deciding which agile framework will work best for your team!