Scrum Or Kanban – Or Both?
As is so often the case, the answer is: It depends! Both Scrum and Kanban are agile frameworks. The goal of both tools is to define a framework in which teams can work as effectively as possible. But different tools are better or worse suited depending on the context, team structure, or the type of tasks to be mastered. For cooking, you use pots and pans the other time. And there are even situations where they use both or combine both. But regardless of whether it is a pot or a pan, ultimately, the tool alone will not be decisive in determining whether your food will taste delicious afterwards.
In the context of this article on Kanban vs Scrum, I don’t want to ask you again what Scrum is or how exactly Kanban works; no, I would like to introduce you to the most important differences and similarities. Give you decision-making aids for your request and point out possible combinations of the two tools.
The Main Thing Is Agile
Around 50 percent of German companies now rely on agile methods. As seen from a study by Bitkom Research from September 2019, most companies rely on Scrum. The reasons for this are usually the same. You perceive agile methods to be faster, more flexible and therefore more successful. Almost 40 percent of the companies surveyed stated that their employees would be more motivated due to the increased responsibility and self-organization. In addition, according to the study, agile procedures enable easier collaboration with IT freelancers, who still take on around a quarter of the total work in IT projects. But only around 17% of those surveyed use Kanban. I believe that the relationship between Scrum and Kanban can also be traced back to the marketing of the two variants. Scrum.org, the Scrum Alliance were and are pioneers in the marketing of Scrum and have made the Scrum product a hip brand. Just ask in your professional environment what people associate with “agile working methods”. I bet Scrum comes up faster and more often than the word Kanban.
Also Read: Resource Management: This Is How You Determine The Effort Of Your Project
Kanban Vs Scrum: Where The Methods Are The Same
Both frameworks support agile work and are by definition “lean”. This means that they are based on the following three principles of lean management :
- Continuous improvement
- Process orientation and
- Customer and employee focus
Both Kanban and Scrum rely on a continuous and experience-based approach to improvement to shorten lead times and minimize waste. This Lean principle is based on the traditional Japanese mindset “Kaizen” (Kai means “change”, Zen means “for the good”). This means that an open error culture is a central element in both methods. Errors are not viewed as bad but as a starting point for improvement.
Scrum and Kanban rely on the pull principle when processing the work to be mastered. It is generally assumed that the team will determine which and how many work packages it will carry out shortly with both methods. For this purpose, the team independently fetches the tasks from a pool of unfinished business. Compare the principle with a printer. This one won’t get any faster if you feed it more paper.
It is important at this point that the team does not pick the tasks that they like best. The aim should always prioritize the requirements or tasks with the highest possible value for the customer.
In addition, both variants rely on so-called WIP (“work in progress”) limits. This means that only a certain number of work orders can be carried out per work section. However, while in Scrum, the number of work packages is limited by the sprint duration, Kanban limits the number of work packages per state along a workflow.
Their flexibility characterizes agile methods. Both variants are conditioned to adhere to a plan exactly and be able to make changes and adjustments promptly in the interests of the customer. In addition, both approaches aim to design the process so that results are achieved quickly. On the one hand, to keep the customer close to the development process itself and on the other hand to receive prompt feedback.
Another characteristic of agile procedures is transparency. At the same time, this is achieved with Kanban with the visual representation on a board, short feedback loops, e.g., E.g. the desired result through daily stand-up meetings in Scrum. With the help of transparency, it is also possible to identify errors as early as possible and optimize the adjusting screws in the process.
The Main Differences Between The Models
But of course, Kanban and Scrum also have divergences. Scrum is fundamentally more rigid in its form than Kanban, as it contains more rules and prescribes processes in more detail.
Let’s start with a temporal consideration. Scrum is based on iterations being carried out in a specified time frame (so-called timeboxes). The length of the timeboxes can initially be varied but should remain constant over a longer period to establish a certain regularity among those involved. Because a regular rhythm, consisting of planning, implementation, delivery of the work results created and reflection of the results, creates security. In Kanban, you will find neither time specifications nor time boxes. So it is up to you when you plan, reflect, improve or deliver the process. However, in practice, it proves useful to establish a certain rhythm here as well.
The three roles of Product Owner, Scrum Master and Development Team are firmly prescribed in Scrum. Kanban, on the other hand, does not provide for any critical roles. However, this does not mean that you cannot or should not use roles in Kanban. It is even necessary that at least one person has understood the principles of Kanban and is responsible for following the process. This role has recently been referred to as a flow master or delivery manager, but you can also fill the role with a scrum master, project manager or product manager. Since 2016, equivalent terms have also been found for the product owner role in the Kanban environment; these are then Service Manager or Product Manager.
While both methods view change as the norm, they both treat it differently. While with Scrum, the tasks are fixed during a sprint (1-4 weeks as a rule), changes with Kanban can be continuously recorded and integrated into the process flow.
Another difference is found in the measurement of productivity. With Scrum, the team estimates the relative effort per work package, considering the complexity and the associated risk. This effort is added up for a sprint duration and thus results in a team-dependent speed. After a team has levelled itself off, i.e. reliably estimates it and delivers similar average speeds per sprint, this measured variable is used as a guide value for subsequent sprints.
However, this measurement also harbours dangers, team conflicts, illnesses, and poorly described requirements, and the resulting incorrect estimates can strongly influence the speed. Estimating the processing time of work packages is not prescribed in Kanban. Productivity is measured in the form of a cycle time. That is, the time it takes to complete a complete work package from start to finish.
Scrum + Kanban = Scrumban
You now know the most important similarities and differences between Scrum and Kanban. Perhaps while reading, you already had the thought of combining the most suitable of both worlds. Sorry, but unfortunately, you are not the first. Under the term Scrumban, hybrid models that pursue this approach have existed since the middle of this decade.
The basic element of Scrumban is a common Kanban board for visualizing the process flows. The to-do list of the Kanban board is arranged according to the Scrum backlog principle. This means that the entries with the greatest business value have the highest priority. In contrast to Scrum, there are no iterative sprints with Scrumban. The work of the team is carried out continuously under the premise of compliance with the WIP limits.
Furthermore, the roles in Scrumban can also be taken over from Scrum. The Product Owner takes care of the backlog prioritization; the Scrum Master is necessary for adherence to the process and the development team for implementation and planning. It also makes sense to regularly incorporate Scrum events such as the Daily Scrum and the Retrospective into the process. A systematic review with the stakeholders (sprint review) is usually also helpful. The duration of the particular time windows and the frequency of the meetings should be coordinated in the team.
The question remains when the use of Scrumban can be useful. Firstly, Scrumban is ideal for working groups that have to fix errors and communicate quickly and regularly. A two-week Scrum cycle with subsequent reporting is too lengthy and inflexible for this type of work.
Scrumban can also be interesting for teams that are heavily dependent on third parties. Often, agreements with suppliers or external service providers are based on not synchronized contracts with an internal sprint cycle. As a result, it is often very difficult for the team to estimate when a job will be completed. However, the expectation of Scrum is a clear and binding commitment by the development team as to what it intends to finish in the next two weeks. As you can imagine, this is next to impossible in such a context.
When Is Scrum, When Is Kanban?
Analyze Your Team
Is your team less flexible, and does it need clear guidelines with fixed time boxes? Should your team have phases in which they should work undisturbed? Then I would recommend Scrum because the tasks are fixed for two weeks, and external disturbances should not be considered.
Analyze Your Environment And Your Processes
Teams with less defined workflows start and finish work sequentially and often have to re-prioritize tasks to meet changing requirements better than Kanban. The prerequisite for this is that the tasks are not too extensive; otherwise, a new prioritization is also impossible.
On the other hand, Scrum is suitable for projects with certain planning security, at least a security for the duration of a sprint. If your customer demands regular involvement, I also recommend Scrum, as he is regularly presented with the real progress at the end of each sprint.
Take Corporate Strategy Into Account
Introducing Scrum quickly won’t work. For Scrum to establish itself in a company, it takes time and, above all, the support and will of management to march in the direction of self-organization. If the organization wants to try out agility carefully and does not want any fundamental organizational changes, then starting with Kanban is probably the better strategy.
Also Read: The Five Most Important Skills For Successful Project Management
