And after all: Scrum or Kanban?

There was a time when the waterfall model was widely used in software development. This approach implies breaking down all work into stages, each depending on the results of the prior stage. Then the universe of development methodologies witnessed a big bang, and the Agile ideology appeared. It brought Scrum, Kanban, and other frameworks.

And after all: Scrum or Kanban?

The victory of Agile over the waterfall model

Before the Agile methodology appeared, the waterfall model was used in software development. The core of this model is a strict sequence of cycles: defining requirements, designing, coding, and so on. This model originates from the world of industry and construction, where a single sudden change could cause major financial expenses. The sequence was defined by the working process itself.

Apparently, the waterfall model was not the optimal option for the IT sphere. To create software, people needed another approach, open for constant changes and prepared to switch rapidly to new tasks. It did not take developers long to understand that they had to leave behind the bureaucracy. Thus, in the early nineties, new light software development methodologies (such as RAD, Crystal Clear, XP, and others) started to emerge.

The Agile manifesto, declaring 12 principles of the agile software development methodology, saw the light in 2001. This document was not a strict guide, but the ideology replacing old clumsy methodologies. The manifesto’s principles based on the acceptance of changes proved to be so demanded, that most IT companies (including Google and Amazon) switched to Agile.   

Some of the most popular Agile-methodologies are Scrum and Kanban. What are their strengths and in which projects will they be the most beneficial? 


In Scrum all the work is done within sprints, two- or three-week cycles. Developers set tasks for themselves before a sprint starts: they evaluate how much time they might need to solve each task and assign the corresponding number of “difficulty units”, known as story points. It is required to plan the work for the upcoming sprint properly. The thing is that once the sprint has begun, nobody should change the existing tasks (if the time is running out and something is not done, it is pushed back to the next sprint). Each sprint ends with a release and the discussion of the executed work.

Sprints promote releasing functional versions of a product on a regular basis. Each version gets a number of fixes and enhancements, so customers can actually follow the direction of the product’s development. Such an approach relates to the Minimal Viable Product concept, which, in its turn, comes from one of the Agile principles: “Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.”


Kanban has nothing to do with sprints: when developers finish tasks, they just start working on new ones. This process is well-visualized: on the Kanban board, the card of the finished task moves from the “in progress” column to the “done” column. As tasks can be added at any given moment, Kanban allows the team to change the development thrust time and time again. In Scrum you can shift priorities only while planning a sprint; in Kanban you can do it every day.

As there is no list of tasks that must be finished before the sprint ends, the release options are more extensive. Some organizations stick to the two-week release schedule, similar to Scrum. Some teams are ready to release once the “done” column gets the sufficient number of cards. In some cases clients might require a specific feature, so the product is released once the corresponding task is finished.

How to choose?

Although both Scrum and Kanban acknowledge the alterability of a product, one of the practices provides more freedom in regard to shifting priorities. Let’s figure out when it is an advantage, and when it causes nothing but confusion.

For the very first stages of development teams tend to select Scrum as a more structured Agile interpretation. Tasks are assigned before a sprint starts, which allows you to understand the status of the product in a few weeks. Once the sprint is finished, the new version is released. The processes take place according to the schedule.

When a software product is available to end users and they send their feedback, Kanban comes in handy. It is designed for handling multiple tasks, the performance of which might (and probably will) happen in a random sequence. What if a client needs a specific feature? Once it is ready, the new version is published. The schedule is up to the team. Or the team might ignore it whatsoever.

The Agile manifesto then and now

It is crucial to remember that the Agile manifesto is not a manual that provides you with the step-by-step guide on creating software products. It is an ideology based on changes and flexibility, common to the world of development. The authors of this manifesto strove to demonstrate that abandoning the bureaucracy was both possible and necessary.  

Over time the manifesto’s principles were carried out in methodologies. Sequences and rules that arrange workflows were created. Regardless of the practice that you are planning to implement, remember the first rule defined in the manifesto: individuals and interactions are more important than processes and tools.