Comment choisir entre Scrum, Kanban et Scrumban pour vos projets ?

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 tâches 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 tâches du backlog, les checkpoints et les ressources nécessaires pour démarrer. 🃏Scorer les tâches avec Fibonacci et réduire les tâches > 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 !

I agree with the point of view mentioned above, that it's necessary to start with Kanban and then perhaps move on to Scrum. I've already made mistakes by defining which method/framework to use without first doing an analysis and having impostor syndrome at the moment of doing the right analysis and feeling that I was wrong and not defending my point of view better. I believe that not every project needs to use Scrum or Kanban. Using the Cynefin framework is an alternative to analyzing in a macro way in order to choose a methodology/framework to follow, but what if I don't follow Cynefin, am I doing it wrong? No, Cynefin is just one of the alternatives. Any form of analysis is acceptable, but it's always good to research and analyze.

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 ;)

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)

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)

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.

Through my years of PMing, I learned one thing the hard way: project management is an art, not a science. You must focus on your team and adjust the tools to your team's needs using your intuition. It didn't matter where my projects were - in Poland, the Netherlands, France, Spain, or the UK - every time I moved the focus from the team to the tools, my projects suffered. Please don't get me wrong. The tools and methodologies are important, but don't waste your time looking for the perfect one for a project. You don't know it yet, and you will know it fully only after completion. Don't you think it will be a bit too late to choose the perfect tool? ;o) Make an educated guess and don’t worry; with your team, you can pull this project through.

The first step is to start with what you already have, mapping the workflow of the team in response to business needs. Evaluate the nature of the requests made. Are they requests that require a certain amount of empiricism to be executed? Scrum. Are they frantic requests that require immediate action? Kanban. Are they requests that blend immediacy and empiricism? ScrumBan. However, in my opinion, experimenting with what best suits your scenario is the best way to go. Without this, insisting on any "silver bullet" is pure speculation!