How do you choose between Scrum and Kanban for your start-up project?

Scrum is a framework used predominantly for software development projects, although it can be applied to other types of projects. It is an Agile approach that emphasizes collaboration, flexibility, and continuous improvement. The core components of Scrum are the product backlog, sprint backlog, daily stand-up meetings, sprint review, and retrospective. Scrum operates in short iterations called sprints, typically lasting two to four weeks, where the team works together to deliver a potentially shippable product increment. The entire process focuses on delivering value to the customer, adapting to changing requirements, and maximizing the team's efficiency and effectiveness.

Scrum is a framework with incremental and Iterative approach where sprints max of 4 weeks is planned with defined Sprint Goal. Since it’s a framework so there are certain rules defined that must be adhered to run the scrum framework like the Scrum Events & artifacts.

Scrum is a framework used in Agile to take a project/product and break it down into short delivery cycles that produce value every iteration, and can adapt to Stakeholder/PO feedback received within a cycle. Scrum is best used for work that is consistent, able to be planned weeks or months out, and a well-articulated vision. It has more structure than Kanban, but isn’t quite as rigid as SAFe.

Et si on changeait d’angle de vue? Et se poser la question pourquoi le choix de Scrum ou Kanban ? La response à cette question entraînera sans doute une bonne approche.

Scrum is a goal-based, evidence-based, empirical-based, iterative and incremental-based approach for turning ideas into value with adaptive solutions for complex problems. Scrum is about increasing closed-feedback loops, inspecting and adapting what is, and what is ahead, giving direction to a team focusing on delivering regularly outcomes for a product that enables the team and the stakeholders to learn as they go.

Kanban is a pull-based strategy that provides signals for optimising flow. It provides measurements that enable teams to focus on getting stuff through the system from start to finish, for example, WIP, Cycle time, Throughput, Item-aging. CT and TP enable probalistic forecasting. With CT percentiles defined by the team, and shared with stakeholders, one can forecast how long a single workitem will probably take using empirical data. With throughput measured for a given period of time and with monte-carlo, one can forecast how long a number of workitems will probably take.

Kanban is a visual workflow management tool used to improve team productivity and efficiency. It originated in Japan as a manufacturing technique to manage inventory, but has since been adapted for other industries and purposes. A kanban board usually consists of columns representing the different stages of a project, and each individual task or item is represented by a card that moves through the columns as it progresses towards completion. By giving teams a clear visual representation of their work, kanban helps them prioritize tasks and collaborate more effectively.

For me, I disagree with the description written in the article for this question, Scrum is not scope-fixed, Increment delivery is not just at the end of a Sprint, increments can be delivered during the Sprint whenever they are ready, as described for Kanban here. Kanban and Scrum if seen as an alternative to one another, are not for the same domain of work, for example, Kanban works well for people providing a service, Scrum works well when creating a product and enables discovery. What is really interesting, is when creating a product, Kanban can be added to Scrum to enhance the transparency for the team, thus giving you the choice to use Kanban, Scrum, or even Scrum Kanban.

Scrum and Kanban are both Agile frameworks, but they differ in their approach to project management. Scrum focuses on completing a set of tasks within a fixed timeframe, known as sprints, and emphasizes teamwork, communication, and iteration. Kanban, on the other hand, is more flexible and focuses on visualizing the workflow, limiting work in progress, and continuous delivery. Kanban is a pull system where the team focuses on completing individual tasks as they arise, while Scrum is a push system where the team plans and executes a set of tasks during each sprint.

The differences are big, although both can be used to develop products and services. Scrum is a framework, with well-defined roles, has clear cadences (Review, Retro, Planning, Daily) and the work flows over a timebox of 1 to 4 weeks. In addition to some good practices, such as having a small team. In a way, there is a certain rigidity in Scrum. While Kanban is not an Agile framework, but rather a more flexible, evolutionary change management method. It has no timebox, does not require specific roles and has different cadences, such as Replenishment, Service Delivery Review and others. Some roles are suggested, such as Service Delivery Manager and Service Request Manager.

Kanban funktioniert super bei komplizierten Aufgaben, d. h. ich habe einen klaren Wirkungszusammenhang eine Wenn-Dann-Kette. Im Prinzip könnten wir das Vorgehen auch in einem Projektplan abbilden, aber: Anforderungen Aufgaben kommen unregelmäßig, eher ad hoc wir wollen ein Pull-Prinzip implementieren. Scrum ist die Antwort, wenn es sich ein komplexes Problem handelt. Wir können das Wenn-Dann nicht denken. Wir unterteilen die Aufgabe in Häppchen. Wir nutzen Sprints in denen Aufgaben erledigt werden, mit anschließender Reflexion, ob die vorhandene Lösung ausreichend ist. Die Frage ist immer: Wie sieht die Aufgabe vor uns aus? In der Regel haben Unternehmen unterschiedliche Aufgabenformen müssen ihr Vorgehen individuell anpassen.

Mon point de vue à travers mon expérience dans la pratique : - Scrum étant un cadre de travaille, ces 3 piliers (Transparence - Inspection - Adaptation) aide à livrer des incréments de valeur. Et tout ça est possible grâce à la mise en place d’événements Scrum (Daily, sprint planning …). Important Scrum applique le principe de l’empirisme 💡 - Kanban, quand à lui permet d’optimiser le flux de valeur à travers des métriques (débit, WIP…). Cela permet de prévenir les goulots d’étranglement et pas que , afficher aussi des statistiques avec le temps de traitement des demandes.

Most of the teams saying they are Scrum-based are in fact not. By definition Scrum doesn't allow much deviation, going for iterative and incremental delivery requires dedicated commitment. The framework defines many details which need to be accepted, all team members need to be cooperative. It's also a question of spirit, especially with the daily standup done online with homeoffice nowadays.

Pienso que se debe priorizar lo que mejor se adapte para la ejecución de proyecto, los equipos, la compañía y el plan estratégico, entendiendo la esencia de los resultados esperados.

El framework o método a utilizar no se debe priorizar por sobre el outcome que buscamos conseguir .. es el enfoque del producto el que nos debiese dar la respuesta de cuál es el enfoque más adecuado para conseguir el objetivo. Si el producto a desarrollar está en una etapa de descubrimiento, en donde de manera incremental podremos obtener feedback de cuáles serán los siguientes pasos a seguir me inclinaría por usar Scrum .. si en cambio el producto está en etapas avanzadas de explotación seguramente existan soportes y mantenciones a realizar además de las nuevas funcionalidades por lo que un equipo trabajando en Kanban en base a clases de servicios y enfocados en el flujo de trabajo sería una opción adecuada.

In my experience, I've come to understand that the choice between Scrum and Kanban depends on the specific needs of the project and the team. If we require predictability and detailed planning, Scrum is more suitable. On the other hand, if we prioritize flexibility and continuous adaptation, Kanban is the better option.

If you're in a startup, especially in the early stages, you don't need a framework like Scrum or Kanban at all. Ship something, get feedback, reflect on what you did in order to improve. Repeat that process. To accomplish those steps there are a multitude of practices and principles that can help. It's possible that, through reflection, you end up with a process that looks remarkably like Scrum or Kanban, but at least it has been done intentionally and from actual feedback, not just a gut feel.

The real question isn't simply choosing between Scrum and Kanban for a startup project; it's about understanding how the design of the Scrum framework and the principles of Kanban can address our specific challenges. We should consider how to apply insights from these methodologies to inform our next actions. Since one framework doesn't universally fit, it's crucial to maintain a bidirectional dialogue—assessing our problems and how different frameworks and methodologies can offer solutions—instead of merely selecting and adhering to a framework's directives.

The general misconception that both Daily SCRUM and Daily standup are same. Daily SCRUM is an event from SCRUM framework which is time boxed to 15mins and happens in same place same time everyday to inspect the progress towards the sprint goals and adapt changes accordingly but Daily Standup is not a SCRUM event. If you are a Scrum Master please don't fall for anything like daily stand-up, make sure you are only promoting the Scrum framework and its values.