Simona Pitam
Sep 5, 2018 · 6 min read

Kanban or Scrum , what methodology is to choose?

In this article I would like to talk about the software development methodology.What kind of framework is to choose?

The main issues of software development system is what kind of framework we should choose. May be it will be Scrum or may be it will be Canban.

Through this article I would like to understand what is Kanban & what is Scrum methodology.What kinds of differences we do have between two those methodologies.

What is Kanban?

Kanban is a tool used to organize work for the sake of efficiency.

Like Scrum, Kanban encourages work to be broken down into manageable chunks and uses a Kanban Board (very similar to the Scrum Board) to visualize that work as it progresses through the workflow. Where Scrum limits the amount of time allowed to accomplish a particular amount of work (by means of sprints), Kanban limits the amount of work allowed in any one condition (only so many tasks can be ongoing, only so many can be on the to-do list.)

What is Scrum?

Scrum is one of the most popular frameworks for implementing agile. So popular, in fact, that many people think scrum and agile are the same thing. (They’re not.) Many frameworks can be used to implement agile, such as kanban for example, but scrum has a unique flavor because of the commitment to short iterations of work.

Scrum calls for four ceremonies that bring structure to each sprint:

  • Sprint planning: A team planning meeting that determines what to complete in the coming sprint.
  • Daily stand-up: Also known as a daily scrum, a 15-minute mini-meeting for the software team to sync.
  • Sprint demo: A sharing meeting where the team shows what they’ve shipped in that sprint.
  • Sprint retrospective: A review of what did and didn’t go well with actions to make the next sprint better.

How are Scrum and Kanban the same?

Both Scrum and Kanban allow for large and complex tasks to be broken down and completed efficiently.

Both place a high value on continual improvement, optimization of the work and the process. And both share the very similar focus on a highly visible workflow that keeps all team members in the loop on WIP(Work In Progress) and what’s to come.

How are Scrum and Kanban different?

As alluded to above, there are a number of differences in both the philosophy behind and the practical application of Scrum and Kanban.

While the individual differences are many, they can be grouped into the following three buckets:

  • Scheduling, iteration, and cadence
  • Roles and responsibilities
  • The board itself

Scheduling, iteration, and cadence

Scrum processes place heavy emphasis on schedule. The scrum team is provided with a prioritized list of story points that need to be completed to deliver a shippable product. The team must decide how many of the points they feel can be completed within one sprint. Anything outside the scope they commit to must wait for the next sprint. Optimally, an efficient scrum team will quickly learn their capabilities over the course of several sprints and their estimates will improve and be optimized as time goes on.

Then, every two weeks (or however long their sprint is) the team produces a shippable product, carries out a retrospective to discuss optimizing the process, and moves into the next sprint. This iterative process is designed to allow for accurate estimations of workflow and effective management of multiple projects. On a Kanban team, there are no required time boxes or iterations. While the Kanban method is iterative in nature, the continual improvement is expected to occur in an evolutionary fashion as work is continually completed. The limitations placed on various conditions in the workflow will be regulated early in a team’s (or organization’s) use of Kanban until an optimal set of limits is arrived at to keep the flow steady and efficient.

Roles and responsibilities

On scrum teams, there are at least three roles that must be assigned in order to effectively process the work: the Product Owner, Scrum Master and Team Members. Each role has its own set of responsibilities, and they must work together to achieve an orderly and efficient balance. The scrum team itself also must be cross-functional, which is to say that one team must have all the resources necessary to complete the entire sprint’s work. Under Kanban, no set roles are prescribed. Practically speaking, it makes sense for someone to serve as a project manager or supervisor, especially for larger more complex Kanban projects, but the roles should theoretically evolve with the needs of the project and the organization.

A Kanban team is not required to be cross-functional since the Kanban workflow is intended to be used by any and all teams involved in the project. Therefore, a team of specialists and a separate team of generalists may be working on different aspects of the same Kanban project from the same board, and that’s ok.

The board itself

While very similar, the Scrum Board and Kanban Board are different animals.

On a Scrum board, the columns are labeled to reflect periods in the workflow beginning with the sprint backlog and ending with whatever fulfills the team’s definition of done. All the stories added to the board at the beginning of each sprint should be found in the final column at the end of that sprint or the sprint was unsuccessful. After the sprint retrospective, the board is cleared and prepped for the next sprint. On a Kanban board, the columns are likewise labeled to show workflow states, but with one vital difference: they also publish the maximum number of stories allowed in each column at any one time. This enforces the team-determined limitations Kanban prescribes for each condition. Since each column has a limited number of allowed stories and there are no required time boxes (such as sprint length), there is no reason to reset the Kanban board as work progresses. It will continue to flow for as long as the project continues, with new stories being added as the need arises, and completed stories being re-evaluated should it be necessary.

Why use Kanban instead of Scrum?

Scrum is arguably the most popular agile methodology in use today, and it does have some similarities to Kanban. There are several key differences between Scrum and Kanban as well. When determining which of the two is better for a particular team or circumstance, a number of factors need to be considered.

Flexibility: If the workflow would benefit from added flexibility and/or the type of work being handled is difficult to accurately estimate before beginning, Kanban’s more adaptable framework may work better.

Scheduling: If scheduling is tightly controlled and it’s vital that work be finished by a given time every time to meet business goals, Scrum’s more structured sprint schedule may be the best choice.

Team size/collaboration: If the bulk of work on any given project is handled by one team, and especially if that team is co-located, Scrum works well to allow everyone to visualize the current sprint’s work and collaborate appropriately.

Kanban does the same, but in a more flexible way that can work well for multiple teams and even teams that are not co-located (assuming the technology used to collaborate is up to the challenge).

Why Use Kanban instead of Scrum?

There are more factors to consider as well, but the real key is to understand that Scrum and Kanban each have their own pros and cons. There really is no absolutely right answer for any given team or organization. Often the best option is a hybrid combination of the two that maximizes the best aspects of each. This is a matter of experimentation and optimization that each team must handle on its own.

To help illustrate these differences and how they can be analyzed, let’s take a quick look at the classic agile use case: a software development firm. Automatically, Scrum is the obvious choice for an agile framework to be used in software development. But, below are reasons why three departments in this organization may be better off going with a Kanban-style solution or creating a hybrid.

As for summary, from my point of view each methodology can help us to manage the software lifecycle, but it depends how we apply these methodology & how it disciplines us & helps to our work be more productive, flexible & to deliver in time a product with the high quality.

Any comments & open discussions are welcome.