Agile practice is no longer a stranger to most of the IT companies or even non-IT companies. Under the Agile umbrella, there are two popular terms, Scrum and Kanban. If we ask “what are the differences between them?”, there may still be a lot confusions when comparing these two methods.
In this article we will not set black-and-white definitions to distinguish these two methodologies. Instead, we’ll look at a few use cases to see how these two methods are used in real life.
Waterfall Scenario
It may be a bit controversial to bring the word waterfall in an agile discussion. It may become a cat-and-dog fight. However, as a pet owner if we handle it properly, we can have them connected well together. Here is the evidence.
Once you finished the “Awww”, let’s continue. In a waterfall type of project, it often has a given timeline with sequential phases, e.g. requirement gathering, analysis, design, develop, testing and transition to operation. Can we use Kanban or Scrum in a waterfall project?
It’s not recommended to use Scrum in a waterfall project. It’s mainly due to Scrum’s core concept – Sprint. Sprint is a repeatable, short and fixed time interval that a team commit to complete a set of tasks or deliverables. The interval is usually between 2-4 weeks. Sprint is suitable for the situations where a team has clear short term goals with dynamic long term timeline. This nature eliminates Sprint and Scrum from the waterfall projects.
Waterfall projects often have clear overall goals that fit in the mid to long term timeline. It also requires certain level of dynamics within each phase. For example, regression testings in the testing phase may bring a number of defects with mixed priorities. It’s hard to predict how many and what type of defects may come up. It’s not practical to leave placeholders for defects in a sprint when doing a spring planning. We don’t know how many defects will come up and how complex they are.
On the other hand, sprint is not required in Kanban. Waterfall projects often use the Kanban method to help on visualizing tasks. Project teams can track how tasks flow through different states, e.g. To Do, In Progress and Done. Project teams can further tailor states, e.g. adding Review, Blocked and other required states. It enables project managers, team members and other stakeholders to gain transparency across the project.
Note that project phases and Kanban states are two different terms. One project phase may have multiple Kanban states. We’ll talk more about the Kanban states in the following sections.
In addition to the visualisation, the Kanban method also provides project teams the flexibility to handle dynamics situations. Using the same regression testing example, if the test team identified defects, they can directly add the defects on their Kanban board. Based on the priority of the defects, the development team can put the defect cards under different states and track them accordingly.
There are many other benefits of adopting Kanban practice in a waterfall project. We will not list them all here. For further information, this article may shed more lights: Kanbanizing the Waterfall.
Scrum Master and Project Manager
Scrum Master is a role that is responsible for managing the Scrum processes and guide the team to follow the Scrum best practices.
The nature of the Scrum is to scope small and manageable tasks within sprints. It requires frequent planning, review and retrospective activities. Without a lead to manage and guide all these activities, it can become low efficient and leads to unnecessary distractions. This is why scrum master plays an important/mandatory role in a Scrum team.
Is scrum master the same as project manager? No, they are two different roles. A scrum team usually is small. There are debates about the perfect size of a Scrum team. The article What is the Recommended Scrum Team Size shed some good lights on the team size. In this Scrum master vs project manager discussion, let’s just use the general term small to describe the team size.
For a small team, having a project manager may be an over kill. However, for a project that have multiple teams and multiple project phases involved, project manager becomes a must-have role. A project manager is responsible for overseeing the progress of the whole project.
In this case, Kanban method can provide great visibility and transparency for the project manager across teams and project phases. We will talk more about visualisation options in the following sections.
Board
We probably have seen a lot similar pictures like the one below. Some fancy versions may have the stickers on a class wall to add some show flavor. People often call it a Kanban board. Nothing wrong to call it so. But when a Scrum team call their board as a Kanban board, it’s where a lot scrum-vs-kanban confusions come from. To help on the following discussions, let’s just call it a board for now.
When a Scrum team choose to use a board to visualise their tasks, they must ensure that only tasks within the current sprint are presented on the board. When the next sprint comes, they should put another group of cards on the board. It’s often forbidden to add new cards on the board during a sprint.
On the other hand, a Kanban team don’t drive their tasks’ movement on their board based on sprints. The board is more for visualizing the overall progress of a project or a project phase. The project team can move the cards around based on their priorities or change of priorities. The project team control how many tasks they should load in the In Progress column. It ensures that there aren’t too many in progress tasks that may overload an individual or a group team members.
In other words, to measure the workload against the team capacity,
- the Scrum team controls the quantity of the cards across the whole board
- the Kanban team controls the quantity of the cards in the In Progress column of the board
Having said above, using a physical board is a double-edge sword. On one hand, it improves the visibility and team collaboration. On the other hand, it may become an overhead to manage.
For Scrum teams, due to the short intervals of sprints, the board can be out of sync quickly if the team doesn’t updated it in time. For Kanban teams, you may found regardless how big a board you’ve chosen and how small the card you use, the board can become congested very quickly. To make it worse, if you have a virtual board (e.g. Jira or Azure Board) at the same time, you almost double your work by constantly syncing the physical board with virtual board. So if you have a virtual/digital board, it should already fit for purpose for your visualisation requirement. Let’s leave the white walls and class walls alone.
Tools
There are many advantages of using a digital board. Especially when more and more people work remotely nowadays. Using a digital board makes it possible for continuous visualisation and collaboration. There are a lot of tools in the market that we can choose to use. Among all the tools, we will pick two most popular ones, i.e. Jira and Azure Board, to look at how to set up Kanban and Scrum in these tools.
From Jira side, it’s pretty straight forward to set up either a Kanban board or a Scrum board. When you create a project, Jira provides templates for both Kanban and Scrum, as shown below:
When we create projects under these templates, we can see that a Scrum project has pretty much the same layout comparing with a Kanban project, except two things:
- the Scrum project has Backlog on the left pane; the Kanban project doesn’t
- the Scrum project asks for starting a sprint; the Kanban project doesn’t
These differences match what we discussed in earlier sections. So definitely a thumb up for Jira. Let’s take a look at Azure Board next.
When you create a project in Azure Board, it doesn’t give you the same options as Jira. Instead, it provides four Work Item Process options, as shown below. It is, not very clear, at least to me as a user. I would ask questions like, if I want to create a Scrum board, do I choose the Agile option or the Scrum option? If I want to create a Kanban board, which option should I choose?
This is a typical Microsoft style. Their approach is like they provide multiple options to users to achieve the same outcome. It’s up to users to choose which one they like to use. If you’ve asked yourself questions like “Do I use Azure CLI or PowerShell/Bash?”, you’ll know what we are talking about here.
Luckily Azure has pretty good wiki articles that compare the differences between these options: Choose a process and About Boards and Kanban. With all these options to choose, you’ll find that the Sprints page is always showing on the left pane regardless which process template you use. If you want to create a Kanban board, you can choose to just use the Boards page and ignore the Sprints page, as shown below.
Summary
There are some other differences between Scrum and Kanban. As we mentioned at the beginning of the article, we are not aiming to do a thorough comparison between these two and draw off-the-book lines between them. Instead, by using the examples above, hopefully it can help on clearing some questions marks you had before. And the key point is that we should let the methods and tools to serve us, not the other way round.
