Definitions

When you run an IT project, you should always consider the work method, that defines how the value is delivered to the IT product. The development process, no matter how many members your team has, can be either efficient or not. The challenges of your IT project have a lot in common with the challenges of other projects in the industry.

There are very popular work approaches to project management, that solve common process challenges. They are Agile work methods for project management, such as Scrum and Kanban.

Both Scrum and Kanban are:

• an iterative work method, an instance of Agile software development;
• a set of principles, a philosophy, leading to product development efficiency.

Scrum and Kanban differ from each other a lot. They are even aimed at different subjects. However, they are not mutually exclusive and can be used in one project simultaneously! In very short terms,

Scrum is a framework for complex products development. Kanban is an approach for changes management and process improvements of a supply chain.

More information about Scrum and Kanban and the the difference between both methodologies can be found in this article.

Let's make their similarities and differences simple:

Scrum and Kanban have both specialities and common features.

Scrum vs Kanban: efficiency metrics

Kanban metrics and tools

Kanban board is a board for cards moving through statuses (columns) and ordered by priority in each column.

Kanban Board example

Cycle time is the time when a task is in progress.

The less the cycle time, the better the customer service.

Throughput is the quantity of tasks that can be processed per time unit.

The bigger it is, the more powerful your team is.

Work in progress is an amount of work that is currently in progress.

The smaller WIP the more flexible the process is and the smaller the cycle time is.

Cumulative flow diagram is the chart with cumulative amount of tasks in each status by history time.

An example of the Cumulative flow chart

Scrum metrics and tools

Scrum board is a board for cards (current Sprint tasks) moving through statuses (columns) and ordered by priority (actually there is no big difference between a scrum board and a kanban board).

A Scrum Board example

Velocity is the amount of work that is done during one Sprint.

Burndown chart is the diagram for tracking the amount of work remaining to be done by the end of the sprint.

An example of the Burndown Chart

Burnup chart is the diagram for tracking the amount of work remaining to be done by the end of the sprint in relation to changes of the whole amount of work in Sprint Backlog.

A sample of the BurnUp Chart

Moving between Scrum and Kanban

Risks and opportunities

Moving from one method to another can be risky. Probably your current work methodology is working well. First of all, consider how to keep all the strengths that your current method has.

Secondly try to prognose, what amount of benefits you will have additionally after the movement.

And most important is that you probably don't have to ruin Scrum to get to Kanban and vice versa. Just develop your current work process with adopting new principles (from another method) that will bring more value for the customer and the team.

It is not good to throw one thing just to catch another. There are many market and technology challenges to be addressed by the software development team, and the change of the work method is yet another challenge that needs team's energy and time.

But "by changing nothing, nothing changes''. When the opportunities of the new approach are stronger than the risks to lose current properties, it is worth changing!

In this article we can only list changes that you may like to apply developing your current work method. Do not hesitate to leave your thoughts or questions in comments!

Moving from Scrum to Kanban

If your Scrum team is going to develop some Kanban principles, apply and develop them. It is better to apply new principles one by one gradually:

1. Visualization
2. Limited Work in progress at every moment
3. Active managing of items/tasks through the work progress
4. Making work policies explicit
5. Collaborative improvements

Moving from Kanban to Scrum

This is the opposite case. If your Kanban team is going to develop some Scrum principles or tools, apply and develop them:

1. Empiricism:
   1. Transparency
   2. Inspection
   3. Adaptation
2. Values:
   1. commitment
   2. courage
   3. focus
   4. openness
   5. respect
3. Team:
   1. cross-functional
   2. self-organizing
4. Framework:
   1. Roles
   2. Events
   3. Artifacts
5. Definition of "Done".

Myths disproved

Here are a number of widespread myths about the relation between Scrum and Kanban.

Each myth is followed by the disprovements.

1. "Both Scrum and Kanban are just a sort of Agile board for sticky notes."
   • Scrum and Kanban (on Lean manufacturing) are approaches to work on software projects. It is far more than just a visualization of the workflow on a board. However, visualizations are crucial indeed.
2. "Kanban and Scrum are not compatible"
   • As it is shown in our diagram above, Scrum and Kanban have a lot in common. The contradictions can hardly be found.
   • Both approaches are just about different principles. There are a lot of good examples of combining those principles on your project, such as Scrumban. Moreover, good Scrum teams follow all of the kanban principles and vice versa.
3. "It is always better to start from Scrum and move to Kanban for product support."
   • It may be better to move from Scrum to Kanban, because Scrum has a great potential of working in an unstable environment from scratch, while the project often has many degrees of freedom at its start.
   • Support works such as maintenance and operations can be run in Scrum, not only in Kanban. Scrum doesn't prohibit to release the results during the sprints continuously.
   • A project can be started in Kanban as well. Agility of Kanban enables fast adaptation of the work process for the product domain and specialities.
4. "Kanban is not applicable for complex products; Scrum is always better for development of complex products"
   • Scrum is optimized for complex products by design, as it is written in the Scrum Guide. And Kanban is applicable to the complex product development as well.
   • Both methods divide (decompose) complex tasks to pieces in backlog, however, the decomposition is often a sort of art in any approach. This decomposition provide teams with the required flexibility for the market demand and mitigating risks.
   • Kanban with its practices enforces teams to get the complex challenges done.
5. "Planning in Scrum is better than in Kanban"
   • This myth could emerge from the fact, that Scrum uses the strict cadence of Sprints and every Sprint starts from the Sprint planning meeting. The team makes estimates based on results of the past sprints.
   • But Kanban is not against prognoses and estimations either.
   • The correctness of the prognosis depends on the team product and technology conditions in both methods.
6. "All working groups in the large team should run only Scrum or only Kanban"
   • On one of ISS Art's large projects, we decided to give the team members rights to vote for running Scrum or Kanban.
7. "Scrum is revolutionary, while Kanban is evolutionary"
   • Maybe this myth emerged from the fact, that Scrum can change the product after each sprint dramatically. In fact, both methodologies are revolutionary and evolutionary at the same time.
   • However, Kanban can be revolutionary as well, it builds the manufacturing system that is ready for changes and even shocks either from the market or from the internal conditions.
   • Moreover, Scrum enables the incremental improvements of the product and the team itself, sprint by sprint. It is evolutionary by design. And Scrum does not forbid continuous delivery of small frequent changes.
   • So, it is more correct to say that both methods are ready for change (agile), no matter, how big the change is – revolutionary or evolutionary.

Conclusions

It was shown that principles of Scrum and Kanban can be applied to a project at the same time. So, the discussion of their contradictions is actually incorrect.

You don't have to choose between the two worlds, you can (or even should) exploit the most applicable principles of Scrum and Kanban in order to make your project flourish.

Let's discuss your thoughts and questions about the relation between Scrum and Kanban in the comments section below!

References

• Scrum and Kanban: Make your teams better by busting common myths
• 3 Differences Between Scrum and Kanban You Need to Know
• Myths about Kanban for Software Development