Nowadays, it is pretty much impossible to see an ad for job opening in the field of IT, without the employer citing the use of some of the agile practices as a particular advantage. It seems like Scrum is currently leading, but lately there’s been more talk about Kanban – what teams they’re suited for, what challenges they can overcome and how much time they can save. But before we dive in further in explaining why you should let agile methodologies choose you, it wouldn’t be bad to explain Scrum and Kanban first. 

There are significant differences between these two agile methodologies and understanding them is key to choosing the path that will work best for your team. Scrum and Kanban are both iterative work systems that rely on process flows and aim to reduce waste.

So What is Scrum?

In a nutshell, Scrum is a tool used to organize work into small, manageable pieces that can be completed by a cross-functional team within a prescribed time period (called a sprint, generally 2-4 weeks long). To plan, organize, administer, and optimize this process, Scrum relies on at least three roles: the Product Owner (responsible for initial planning, prioritizing, and communication with the rest of the company), the Scrum Master (to oversee the process during each sprint), and Team Members.

What is Kanban?

Again, without getting too detailed, Kanban is also a tool used to organize work for the sake of efficiency. Like Scrum, Kanban breaks down the work into manageable chunks and uses a Kanban Board (similar to the Scrum Board) to visualize that work as it progresses through the work flow. Where Scrum limits the amount of time allowed to accomplish a particular amount of work, Kanban limits the amount of work allowed in any one condition. 

Where do Scrum and Kanban Overlap?

Like we already mentioned, they both rely on process flows and aim to reduce waste. They allow for large and complex tasks to be broken down and completed efficiently and maybe most importantly, they emphasize continual improvement of the work and process.

3 Differences between Scrum and Kanban

Within Scrum teams, there are at least 3 roles that must be assigned in order for it to work: the Product Owner, Scrum Master, and Team Members. Each has its own responsibilities and they must work together to achieve the wanted result. Another very important thing for Scrum teams is that they must be cross-functional, meaning one team must have all the necessary resources to complete the entire work. This is not the case for Kanban teams, since the work flow is intended to be used by any and all teams involved in the project. 

Like mentioned above, Scrum and Kanban boards are very similar, but at the same time very different. On a Scrum board, the columns are labelled to reflect periods in the work flow beginning with the sprint backlog and ending with whenever the work gets done. After the sprint retrospective, the board is cleared and prepped for the next sprint.  On a Kanban board, the columns are also labelled to show work flow states, but with one vital difference: they also publish the maximum number of stories allowed in each column at any one time. And since there is no sprint length, there is no need to reset the Kanban board as the work goes on. It will simply continue to flow for as long as the project continues.

Schedule is of the utmost importance with Scrum. The team is given a prioritized list of story points that need to be completed to deliver a product. Anything outside the scope they commit to must wait for the next sprint. Ideally, every two weeks the team produces a product, discusses optimizing the process, and moves into the next sprint. On a Kanban team, there are no required time boxes. Unlike Scrum, we can change priorities as the environment dictates.

Before choosing the right framework for your team, your focus should be on the culture within the company and building the agile values, and the implementation and use of agile frameworks should and must remain with the teams to decide. At the end of the day, if someone from above says: “From now on we’re using Scrum”, there is no agility there, right? 

Kanban defines only three guidelines: visualize your work, limit WIP (work in progress) and increase the amount of work done per unit of time (throughput). Most organizations want to complete tasks in ASAP style (to reduce lead time). With WIP visualization and setup, Kanban will allow you to optimize your workflow. You will achieve this by identifying bottleneck. Of course, whether Kanban is the right tool for your particular project depends on the context and, well, the project itself. 

Scrum is by its nature a framework that is best applied to projects when we only have an idea of the product we are creating, but we are not sure what’s the best way to do it, or what are the functionalities that will be accepted by users. In that case, Scrum makes sense because in short iterations, with constant feedback from users, we can discover what we’re doing and how.

When Not To Use Kanban or Scrum?

Kanban is generally not recommended to newly-formed, inexperienced teams, since they still need a higher level of guidance to reach the performing phase. Just because there are fewer rules, much is allowed, and inexperienced teams are less successful in such an environment. Kanban offers a lot of freedom, but also a lot of responsibility.

Scrum doesn't work if you only use it because you have to state in the ad that you're using an agile framework. Scrum, or any other framework, should not be used simply because someone said it, or because it’s popular. It is necessary to experiment and then determine which is right for your team or project. Do not use it to increase productivity, but to facilitate the work of teams. At the end of the day, whatever framework you use, people are the most important, and they are the ones who will build your team and work on a particular project.