What are the differences and similarities between Kanban and Scrum?

A good example in IT industry when Kanban shines the best is operational work like oncall shift. The issues are naturally being added to Todo list with no need to plan your day or week. The Todo list is sorted by issue priority so engineer knows what to take next and where the focus should be. The limits help to keep the focus on items that are in progress. Issuers are getting proper notifications with the status.

Kanban originated in the Toyota Production System to achieve just-in-time delivery. Kanban translates from Japanese as "signboard" or "signal card." In Toytota's production line, processing instructions were carried on a card (the kanban) from one step on the production line to the next. The Toytota production line is a flow system where work in progress is limited and pulled just in time, not pushed, through the steps in the workflow. The workflow is optimized through continuous improvement (the elimination of waste). David Anderson adapted Kanban for knowledge work and published it as the Kanban Method. The Kanban Method defines six practices, not three, and leverages Little's Law to build a stable workflow.

As it is considered to be a framework with simple, yet explicit processes, it can be a good start for teams that just transition to agility.

We use Kanban for our issue/bug backlog as it lends itself to 'get it out the door as fast as possible' type of working for the squads. We use Scrum for Project/Feature work, but for the laundry list style of tickets we use Kanban.

Ambos os métodos têm seus próprios contextos de aplicação e podem ser eficazes dependendo dos requisitos específicos do projeto e da cultura da equipe. A escolha entre Kanban e Scrum muitas vezes depende da natureza do trabalho e das preferências da equipe.

Scrum is a product development framework based on empirical process control, where decisions are based on observation, experience, and experimentation, co-created by Jeff Sutherland and Ken Schwaber. Scrum is an inspection cadence (the sprint) composed of four events aimed at inspecting and adapting the product (sprint review), the process (sprint retrospective), and the plan (daily scrum and sprint planning), executed by a Scrum Team (a product owner, scrum master, and developers). The first sprint was executed at Easel Corporation in 1993, eight years before the authoring of the Agile Manifesto. The first mention of Scrum was in the article "The New New Product Development Game," published in the HBR in 1986 by Takeuchi and Nonaka.

Kanban: Kanban is a flow-based methodology. It visualizes work on a board and focuses on managing and optimizing the flow of work items. Scrum: Scrum is a time-boxed methodology with fixed-length iterations (sprints), typically lasting 2-4 weeks, during which a specific amount of work is planned and completed.

Kanban starts with mapping (visualizing) the existing workflow, which can be very "prescriptive," and then proceeds to optimize it through continuous improvement (kaizen). David Anderson's Kanban Method recommends using cadences (formal feedback events) to optimize the workflow. It recommends using existing cadences when appropriate, which can map one-to-one to Scrum events in a Scrum organization. Work is pulled in Scrum the same as it is in Kanban; it is not pushed. Scrum, however, does not prescribe using work-in-progress limits, as does Kanban. But a Scrum Team is free to use them. Scrum does not prescribe any measures. There is no mention of velocity in the Scrum Guide (https://scrumguides.org/scrum-guide.html).

In most situations, Kanban is effective in environments where Scrum works well, although the reverse isn't always true. Scrum is typically more successful in scenarios that involve a certain level of stability, such as projects, tech uplifts, or mature products. Kanban is particularly effective in environments that experience high variability in demand and/or high variability in flow. For example, this makes it suitable for early startups, product discovery teams, and DevOps.

Algumas correções ao artigo: - Kanban foca no fluxo porque é um caminho natural onde o valor se materializa. - Scrum não é push-based, não há nenhuma afirmação sobre isso em nenhuma versão de Scrum Guide. Scrum pode ser pull, inclusive gera mais resultados e menos sobrecargas assim. - Kanban não é conivente com “alteração a qualquer momento”. Na verdade, aprendendo Kanban você fica ainda mais crítico com as mudanças repentinas de prioridade. - Scrum não prescreve (ou sugere) medidas para gerir o fluxo. Porém, dado que em qualquer trabalho existe fluxo, pode fazer uso das métricas sugeridas no Kanban. - “Values trumps flow” é um filtro de decisão usado no Kanban. Queremos maximizar os benefícios econômicos, o fluxo é um meio para isso!

Scrum follows fixed-length iterations with defined roles, ceremonies, and a backlog, promoting collaboration. Kanban focuses on continuous flow, visualizing work on a board, with no prescribed roles or ceremonies. In Kanban, WIP limits ensure teams don't overload, optimizing flow. Also, Kanban allows flexibility in prioritizing tasks, providing adaptability to changing needs. Scrum, with its fixed sprints and prioritized backlog, emphasizes stability in commitments. Swapping priorities in Kanban is smoother due to its fluid nature, while Scrum maintains commitment within the sprint. Each approach suits different contexts – Scrum for predictability, Kanban for flexibility. Both thrive on Agile principles, fostering iterative improvement.

Both Kanban and Scrum use visual boards (Kanban boards and Scrum boards, respectively) to display work items and their progress. This helps teams track and manage work. Both Kanban and Scrum promote self-organizing teams that have the autonomy to make decisions regarding how they work and deliver value.

Both Scrum and Kanban seek to limit work in process to improve throughput and flow. Kanban does this with WIP Limits - limiting the amount of work in process at any given time. Scrum does this through planning work that is your best guess of what can be accomplished within a specific time-box, or sprint, and creating a sprint backlog to focus and finish.

Eles são mais próximos quando olhamos para os pilares empíricos do Scrum - Transparência, Inspeção e Adaptação - para o Lean Thinking e para os seus valores. Ambos querem entregar valor aos clientes, mas seguem meios (ferramentais) e filosofias de mudança diferentes. Assim, em termos mais práticos, parece mais razoável dizer que eles são compatíveis, mas não muito “semelhantes”. Apesar disso, é possível explicar todo o framework Scrum pelas práticas-gerais do Método Kanban, mas isso acontece com qualquer abordagem que esteja no domínio do trabalho do conhecimento.

Kanban e Scrum, apesar de distintos, compartilham elementos fundamentais das metodologias ágeis. Ambos priorizam transparência com o uso de quadros e gráficos para visualizar o progresso dos trabalhos. O feedback do cliente é central, orientando a entrega rápida e frequente de valor. Ambas as metodologias enfatizam a melhoria contínua e a adaptação, incentivando equipes a responderem a mudanças e incertezas como oportunidades de aprendizado e crescimento. O uso de dados empíricos para revisar e ajustar processos e produtos é também um ponto comum, alinhando ambas as práticas com os princípios ágeis de desenvolvimento.

Despite their differences, Scrum and Kanban share fundamental Agile principles. Both emphasize customer value, iterative development, and continuous improvement. Both frameworks promote visualizing work, enhancing transparency for better team collaboration and stakeholder communication. Moreover, Scrum and Kanban encourage adaptive planning, allowing teams to respond to changing requirements efficiently. Daily stand-ups or Kanban's regular meetings provide opportunities for quick feedback and alignment. Ultimately, both Scrum and Kanban aim to deliver high-quality products through collaboration, feedback loops, and a commitment to constant improvement, demonstrating the core values of Agile methodology.

Scrum dumbs down to iteration. Kanban optimizes the flow of work: the transaction cost per iteration or cycle time per iteration.

As experiências práticas com meus times ágeis nos últimos anos comprovaram resultados excelentes com uso mútuo de Scrum e Kanban. Enquanto o Scrum traz constância para as entregas, o Kanban deixa tudo visual, de facial entendimento para os membros do time e demais stakeholders. Como característica forte dos frameworks ágeis, a adaptação para o seu projeto será parte crucial para o sucesso.

Se você entende a natureza evolucionária do Método Kanban, não vai ter problemas em combina-lo com nenhuma outra abordagem. Já que o artigo está cheio de erros, vale alertar da diferença confundida por boa parte da comunidade ágil: Scrum com Kanban é uma coisa, Scrumban é outra!

Combining Scrum and Kanban is often referred to as "Scrumban," offering the best of both worlds. Start with Scrum's structured framework, including sprints, roles, and ceremonies. Introduce Kanban elements like WIP limits and a visual board to enhance flexibility and flow. It's a dynamic approach, allowing teams to harness Scrum's predictability while leveraging Kanban's adaptability to changes and focus on continuous delivery. Regular retrospectives are crucial in Scrumban to refine and optimize the process continually. This blend offers teams the ability to maintain structure while adapting to evolving project needs, resulting in a more versatile and responsive Agile framework.

Given the enormous volume of misinformation on the internet regarding Scrum, Kanban, and Agile, training a Large Language Model (LLM) to generate articles on these topics is likely, not prudent. Garbage in, garbage out. Most of the article above qualifies as misinformation. There is insufficient space or time to correct all the errors. In the case of Scrum and Kanban, authoritative sources may be used to validate the model's output. In the case of Scrum, there is the Scrum Guide and Scrum.org, to name two. Similar sources exist for Kanban. Unfortunately, because many scrum masters and their kin are trained on misinformation or asked to work in "agile" in-name-only organizations, they do not see the errors.

São tantas diferenças que é difícil começar a conversa. Bons tópicos para comparar são: 1) gestão de mudanças. 2) abrangência na organização. 3) profundidade e visão de maturidade. 4) relação com o agile. 1) Kanban é o “start with what you do now method”, ou seja, evolucionário e sem limites arbitrados. Ele parte de qualquer processo existente (ex.: Scrumban, do Corey Ladas). 2) Kanban foca em melhorar o serviço, e isso pode significar apenas 1 time multifuncional ou pode significar dezenas de times configurados por especialidades. 3) Não existe Kanban errado, apenas aplicações menos conscientes e profundas (fica evidente no KMM). 4) Kanban se relaciona com abordagens preditivas sem julgamentos. Não é agile, mas promove agilidade.

Scrum or Kanban depends on the specific needs and preferences (capability and capacity) of the team, to adopt one over the other. Neither is imposed on the team. Using a simple kitchen analogy: A Scrum kitchen delivers meals, as increments, within a fixed timebox. A Kanban kitchen delivers meals, as throughput, using regulated flow (work in progress limits) instead of a fixed timebox. The flow of meals from a Scrum or Kanban kitchen to the table depends on how teams manage their respective releases - as increments where one meal builds upon another or as independent throughputs.

Maintaining a commitment to Agile principles is paramount, regardless of the framework you use. The goal is not just to implement Scrum, Kanban, or any framework but to instill the Agile mindset throughout the development process. By staying true to Agile principles, teams can navigate the challenges and complexities of projects more effectively, fostering a collaborative, customer-focused, and adaptable environment, ultimately leading to successful and timely delivery.