How do you compare agile frameworks like Scrum and Kanban?

Scrum is a delivery framework, Kanban is an improvement or support framework. Scrum is designed to gain continuous delivery and learning within a short time to have feedbacks and deal with risk and confront uncertainties, Kanban is designed to improve the work cycle and eliminate bottle necks by limiting the work in progress.

In addition to these values above, one of the goals of scrum is to deliver working software by the end of the sprint, otherwise the framework breaks down.

Unless a developer is working in their own private branch of a source tree, they should only be checking in working code. This is extremely important when multiple developers are working on a given branch because checking in broken code will just break your teammates source trees and everyone gets stuck until a fix gets checked in.

Kanban also has Work In Progress (WIP) Limits, where a certain number of tasks cannot happen in the same state. This encourages storming on the current problems to move them to the next desired state.

Kanban is typically used in environments like DevOps tasks that are related to day to day operations while Scrum is better suited to development, including DevOps related development. Day to day tasks would include things like investigating the cause of a production problem or upgrading a server or COtS software. These tasks are relatively short tasks that can be handled over a few days, as opposed to building out a new release of software which typically takes much longer.

Key comparison that I believe is visualisation of work in Kanban which helps focusing on the ones nearest to the completion and identifying bottlenecks if any

Kanban und Scrum zu vergleichen, ist wie Äpfel und Birnen vergleichen. Kanban ist ein flow-orientierter Ansatz für Regelarbeit. Scrum ist iterativ und kann auch für Projekte genutzt werden. Was beide verbindet, sind einige Agile Grundsätze, aber auch nicht alle. Der Umgang mit Metriken ist völlig unterschiedlich, dafür nutzen beide Systeme zur Visualisierung von Arbeit Spalten und Post Its.

One of the main Difference Between Kanban and Scrum is: Kanban Delivers Tasks continously until the project is finished, but Scrum has Sprint and the Tasks will be reviewed at the end of the Sprint ( Max 4 Weeks). In Kanban we have the WIP ( Work in Progress) limitation, but in Scrum we don't ( But Team can commit to put a limitation on their work). P.S: In my Personal Opinion Scrum is more Structured than Kanban

There is an additional main Scrum role that is very important but is often treated as an afterthought, namely testing. A Scrum team is not complete without good testers.

In my experience, comparing Scrum and Kanban, I've found that Kanban's flexibility in roles allows teams to adapt to their unique needs. For instance, in a software development team, we empowered team members to choose tasks they felt most comfortable with, enhancing productivity. Kanban's adaptability encourages self-organization.

- Provides a structured framework with defined roles, ceremonies, and artifacts. - Emphasizes fixed-length iterations (sprints) and a focus on delivering a potentially shippable product at the end of each sprint. - Enables predictable planning and release schedules. - Scrum ensures that features are regularly delivered at the end of each sprint, facilitating reliable release planning.

- Offers a more flexible, continuous flow approach. - Doesn't prescribe specific roles or ceremonies; it adapts to the team's existing processes. - Focuses on visualizing work, limiting work in progress, and optimizing flow. - For Example, A customer support team can use Kanban to manage incoming requests, ensuring quick response times and efficient issue resolution.

Kanban is an excellent framework for Operations and Technical Ops based teams where the work is interrupt driven and procedural in nature.

From a leadership perspective, my experience has shown that Kanban's visual boards enhance transparency, enabling quick decision-making. For instance, in a project, we used Kanban to track tasks, and when a bottleneck emerged, we swiftly allocated resources to clear it, preventing delays. Kanban's flexibility allows us to adapt to shifting priorities. Furthermore, Kanban fosters a culture of continuous improvement. We encouraged team members to suggest process enhancements. One such suggestion led to a streamlined code review process, reducing review times and enhancing code quality.

What really matters is how the people doing the work think. If their thinking is right, the outcomes will be good irrespective of the framework. They may, for instance, do Kanban within the Scrum framework where that suits ("Scrumban"), or add things on to Kanban from Scrum if there are specific needs to be met (say in the form of mid-term (sprint-length) goals. It's the people that make the difference, not the framework.

The choice between Scrum and Kanban depends on the specific needs of the project and team dynamics. Scrum provides structure and predictability, while Kanban offers flexibility and visual management, both valuable in different contexts.

We should also consider the complexity of the work. In my experience Scrum prevails for teams working on more complex initiatives, where Kanban may help to maximize flow for faster moving items.