How do you choose between Scrum, Kanban, and Scrumban for your projects?

In my experience, I use SCRUM for projects with fixed timeboxed deliverables, as it ensures structured and timely progress. For tasks with less predictable inflow, I prefer Kanban. Its prioritisation of work in progress (WIP) suits business-as-usual (BAU) workstreams by allowing greater flexibility.

Scrum and Kanban are pretty solid tools for project management. Scrum is all about delivering in small chunks and constantly improving with feedback. Kanban, on the other hand, helps by visualizing tasks and limiting work in progress to boost efficiency. Combining these two methods seems effective since you get the best of both worlds: continuous feedback and manageable workloads. Personally, as a visual learner, I really like using Kanban boards and their metrics to communicate with stakeholders. But honestly, I'm still figuring out if this combo is truly the best way to go, and I'm open to other methods.

When a methodology is used to check off requirements without living and breathing its principles, the results can be disastrous. In my career I've watched Scrum Masters undertake daily standups with no sprints, sprint retrospectives, or sprint reviews (which is by definition not scrum). I've also seen companies lose out on code worth five figures due to scheduled erasure of development environments which was completely avoidable. A book that completely transformed my view on sprints from a flawed one similar to the examples given is called 'Sprint' by Jake Knapp. Not all design thinking activities from it will carry over for your needs but it should provide enough footholds to improve the ways that you and your teammates deliver value.

Scrum follows Fixed Timeline (Time boxed), Fixed Scope and Fixe resource developed by Self organized, cross functional team and delivered in Iterative and incremental way. A Skeleton structures with prescribed Ceremonies as a precautionary step to handle Delivery effectively

- de 10 membres ? Le Crado-Scrum c'est crado mais c'est Scrum ! Le Flow Channel : Assigne des taches adaptées aux compétences ou challenge de chacun. Planification hebdomadaire + Feedback sur Discord pour anticiper les imprévus. ??Une "Ice Box" d'idées alignées avec les OKR ?? : Ajoute tous les membres intéressés et choisi 1 pilote. ??Décrire les taches du backlog, les checkpoints et les ressources nécessaires pour démarrer. ??Scorer les taches avec Fibonacci et réduire les taches > 13 pts : Go deeper. S'appuyer sur la matrice d'Eisenhower pour prioriser. ?? Lancer des Sprints "On The Run" si leurs ressources sont disponibles. ????♂?????????♀? Livraison rapide pour test en production , validation par l'équipe produit ?? Go Live !

Good for Projects having continuous flow. Executing by identifying the Flow, setting WIP limit in each stage (As it is PULL based model) team can PULL based on the Capacity available and measure performance through THROUGHPUT, LEAD TIME and CYCLCE TIME. Mostly followed for Support based projects (Handle ticketing)

Pour moi, le Kanban n'a rien d'un cadre ou d'une méthode. Un Kanban, c'est un simple outil. C'est un board de management visuelle très utile quand on veut travailler en flux, mais ce n'est pas lui qui vous garantira des itérations courtes ou une capacité à être réactif au changement.

When team doing development and support. Where the Development Stories follow scrum, Committed vs Delivered and ADHOC tickets/support tickets will go by Kanban way follows Agreement (SOW) within how many hours to respond and how many days max to close it.

Does scrumban even exist? I know Corey Lades wrote the following book "Scrumban: Essays on Kanban Systems for Lean Software Development" Isn't it just scrum with kanban ;)

How do you choose between Scrum, Kanban, and Scrumban for your projects? I don't. I don't. I don't. I don't. I don't. I don't. (sorry, it had to be 125 characters minimum)

Aucun framework ne pourra vous garantir d'être agile. Pour moi, Scrum, c'est comme les petites roulettes sur ton vélo quand tu n'es pas encore agile et que tu aimerais le devenir. Le problème, c'est que de nombreuses équipes s'enferment dedans et le cadre devient plus important que le but. Le but, c'est d'être réactif au changement pour saisir un maximum d'opportunités. Pour cela, rien de mieux que d'adopter une approche empirique qui allie les relations humaines et la mesure. (Sans oublier une bonne dose d'excellence technique)

The choice of the method is not carved in stone. No matter if you use Scrum or Kanban, or both, or something different, you can use retrospectives to inspect and adapt.

Ask the people doing the work. Not the managers, not your personal thoughts, ask the people doing the work to set the terms. Simple right?

Building an MVP? You need Kanban Building for scale? You need an iterative model with manageable Units of Work so Scrum would be ideal. Especially when POD structures are being followed in your teams. Know what to build in the long term but you know there will be a lot of Flux in the requirements? You need Scrumban.

Below are examples of how I differentiate between the types of projects applicable to each framework. 1. Scrum is useful for a software dev team building a website, using daily stand-ups, sprints, and a product backlog. 2. Kanban would be preferred by a content marketing team creating blog posts, using a visual board, task cards, and daily meetings to track progress. 3. Scrumban is most suitable for longer projects such as a customer support team managing inquiries. They will probably prefer using a prioritized backlog, a visual board, daily stand-ups, and high level performance metrics together.

A escolha entre Scrum, Kanban e Scrumban para seus projetos geralmente depende das características específicas do projeto, das preferências da equipe e das necessidades do negócio. Cada metodologia tem seus pontos fortes e fracos, e a escolha pode ser influenciada por vários fatores. Ao escolher entre Scrum, Kanban e Scrumban, é importante considerar as características específicas do projeto, as preferências da equipe e as necessidades do negócio. Em alguns casos, uma abordagem híbrida, como o Scrumban, pode ser a melhor solu??o para combinar o melhor dos dois mundos.

It depends on project specifics needs: 1. Scrum: fit for clear and well-defined projects with fix goal. It has fix and clear length( Sprint Start& End), after planning and during the sprint changes in the Tasks ( adding, removing, changing in Sprint Goals) are not possible 2.Kanban: flexible projects, changing in prioritizing. Real-Time adjustments 3. Scrumban: when we need structure of scrum, but flexibility of Kanban.

Agile is a mindset that aids in more rapid, lightweight, and efficient development processes. The process delivers creations and services that customers look for, and the product development process is therefore faster in response to changes. Depending on the needs of your team and organization, you may choose to adopt one framework or establish a mixture of frameworks. Research all the situations and requirements you have and which methodologies suit you best. All these options are great, so trust me, regardless of your choice, you’re sure to improve productivity. Agile is built to create more efficient teams, so most of these methods will, at the very least, help your team gain a better understanding of what work to prioritize.