9 May · 7 min read
Delivering a successful software development project is a challenging task to complete. There is no doubt about it.
"The percentage of projects that fail is fairly high—a whopping 70% of all projects fail to deliver what was promised to customers." Source
Therefore, the methods of how to get to the finish line of a project with a valuable product, are constantly analyzed and refined. Running projects using Scrum and Kanban is one of the ways that do the job. Both methods, despite their differences, have several common elements. What in that case is the strongest link between scrum and kanban? Agile philosophy.
This article defines what Scrum and Kanban are, considering the Agile way of working as a bonding element of both.
Agile development is the core of Scrum and Kanban. Although the history of the two frameworks is different, and so is their age, both are based on the same main assumptions as Agile. The Agile way of working favors collaborative work of the independent team that gathers project requirements and creates code based on an iterative approach. This is due to managing the occurring changes and problems effectively.
"Responding to change over following a plan" Agile Manifesto
Agile methodologies are then about being flexible to the changing circumstances and thus the project's requirements. Agile was needed to replace a Waterfall (another methodology for software projects) that could not cope with change. And the opinions of all parties involved in software development projects were the same - you cannot predict and define everything, including the requirements, before starting work on the product. Often to draw a conclusion on the validity of a requirement, you simply need to see its implementation's effects. Thus the changes and ability to adapt are essential demands the project management methodology has to provide. And it is Agile that best responds to these needs.
Agile is then a philosophy that uses various tools – frameworks – to implement a project (which usually equals creating software). This definition presents Agile as a wide concept of how to do things, and Scrum and Kanban are the tools the Agile recommends to use.
Let's explain what Kanban and Scrum are exactly and which framework to choose based on your project needs.
Scrum teams deliver work increments in planned time periods named sprints. After each sprint, the team gathers feedback to improve the process and the results. The Scrum team (made up of members who have different roles like scrum master) takes part and performs various events and scrum ceremonies that help them deliver the elements of the product with each sprint. The base of Scrum tools and processes is the Scrum Guide which contains all the rules, the Scrum teams follow.
Kanban framework is aimed to visualize the workflow, which helps to monitor its implementation – progress and time needed to get the job done. One of the main Kanban tools is Kanban boards. They are used to present work - planned, being reviewed, in progress, or done. The way the board is divided depends on the development team and project. When the task changes its status it comes to a different column. The goal of Kanban board is to notice where the problems occur, for instance, at which phase the work is stopped, then define a blockage and take action to counteract it. It's about the continuous improvement of how the work, or rather the process is run.
This happens with the WIP work - work in progress, which is one of the main problems development teams struggle with. The Kanban allows seeing the excess of work in progress, setting the WIP limits, and monitoring their implementation.
The question like ' Is Kanban as good as Scrum' is not relevant because it's difficult to compare different Agile methodologies that Kanban and Scrum are. Still if the goal of both is to improve workflow to deliver even complex tasks, they are two various project management methodologies. The best way to discover which one will be best suitable for the project is to understand the differences in their key metrics.
Scrum is based on three roles and the resulting responsibilities.
Kanban roles are not defined, however, there is often someone responsible for project management such as project managers who manage the Kanban boards and its challenges. Generally, the whole team is in charge of a Kanban board ownership, the same as there is collective accountability for task delivery.
Scrum operates within sprints that last from one to four weeks, depending on the needs. Each sprint has to end with a working increment so the complex issues are split into smaller user stories that the development team delivers with every sprint.
Unlike Scrum, Kanban doesn't have a framed timeline in which the development team delivers a part of a product. The team does this as fast as it's possible. To help reduce delivery time, the team uses the Kanban board visualization.
Artifacts, events, ceremonies – all of that practices are important part of Scrum projects. They help the team to deliver the successful product with a support of the Scrum principles: transparency, inspection and adaptation.
What are the Scrum practices?
Sprint planning, sprint, daily scrum, sprint review, sprint retrospective.
Scrum metrics are various but they have a common goal – to increase product quality, in other words: to make it more valuable. They are used during the Scrum practices to measure effectiveness. Examples are the sprint goals, burndown chart, scrum team velocity, and a few more.
Kanban has different data to indicate or increase efficiency. They all help to make a task delivery more effective with the emphasis on reducing execution time. Examples: cycle time that tends to be constantly improved, WIP (work in progress) that must have limits set, CFD (cumulative flow diagram) helping to define the blockages that decrease cycle time.
Kanban practices are related to its metrics: workflow visualization, limiting the WIP, and managing the flow which also includes the feedback.
Kanban is made to incorporate changes at any time if needed. The whole process is very flexible, new tasks can be added to the backlog because current ones can be removed. It all depends on priorities. The same with changes related to metrics like WIP - the limits can be adjusted if the circumstances are changing.
The changes with Scrum are more complicated. When the sprint is in progress, it's difficult to change the priorities and tasks. The sprint should end, and the scrum practices like retro can help to define the needs of changes that will be taken into account with the next sprint planning.
As it's easy to see, there are some differences between Kanban and Scrum. However, they are related to the tools and practices, not the overall principles. The general rule of both frameworks is similar: to deliver valuable products in the most effective ways.
There is no right answer to a question about which is better Kanban or Scrum. It depends on the team's need, the project's type, the client, and the phase the software development project is in. Additionally, it's good to know that both frameworks aren't perfect and won't fully meet all the needs. Nevertheless, they are considered the best for the Agile delivery of software projects.
Undeniably, people are a fundamental component of the Agile way of working. Thereby, self-organizing teams are the basis of both Scrum and Kanban. Team decides what's best for them, as they know how to organize their work. Therefore, if the Agile team chooses to work in a hybrid model that combines Kanban and Scrum, they should try this out. Learning by doing is the best way to find out what works, and what doesn't for the team.
There is already a named option for combining these two frameworks in one, which is called Scrumban. It uses Scrum as the main foundation and a few Kanban principles as support. However, the rules of Scrumban are less important because the effect is what counts. The team has to be pleased with their way of working and its results.
The Agile Manifesto says: "Individuals and interactions over processes and tools"
Let's then people decide what's best for them, especially that from the business perspective, it's the working software that counts, not the path that was chosen to create it.
Curious about more Agile related content? Visit our website and learn more of how we deliver software products.