So let me ask you this: why is Kanban not as popular as Scrum? Why do managers seem to fight tooth and nail* not to try it?
*my own experience in at least 2 orgs
Where I work now we officially have sprints but we really practice a Kanban system.
Good question, but is it the right question? While I know that scrum and kanban differ, I've generally seen them used together. Every scrum team I've worked with has made a kanban board a central (or at least main) part of their work.
Maybe a more accurate question might be why don't more managers incorporate kanban into their project management processes?
Kanban is simple. So simple that no one could justify taking large amounts of money to teach people how to use a list of tasks.
Up to 2011 it was "manager keeps it all in their head, uses a spreadsheet, sometimes shares that spreadsheet in meetings"
After 2011 it was either Kanban or Kanban + Sprints. Sometimes the word Scrum was used.
The closest to Scrum place also has a product owner.
This allows managers to engage in Planning and Predictability Theater™, which they seem to find reassuring.
This corruption of Scrum also has the effect of reframing imperfect estimates as IC failures.
Genuine Kanban works better in cultures where ICs are highly trusted and failures are primarily examined through the lens of systems breakdowns, and views those systems as primarily the responsibility of management.
If a team is very low performing, scrum is great. Once they're high performing, drop the routine and let them practice Kanban.
If you have a team with low morale or motivation you need these tools to monitor what's up.
If you have higher ups that needs constant information about what's up scrum also gives you more information just following the system.
Kannan is great when the team moves on its own and with a good manager who calibrates the aim from time to time.
As a developer it meant a lot less overhead, made up estimates and false promises. Kanban sets priorities, not timelines. However managers really want those.
The benefit of "scrum" is that it splits the development into chunks of work that can be used when planning, which is why it is well suited when the majority of work consists of development and delivery of new features.
On the other hand, "kanban" works much better when the majority of work is maintenance, bug fixes, paying off of technical debt and only a limited amount of new development.
Kanban is a great fit for the reactive work (e.g. big fixing, support, mainetnance, ops, etc.)
Scrum solves a bin-packing problem, how to decompose work into imaginary tasks and fill them into 1-2-3-4 week cycles (aka sprints). Additionally it based on the false assumption that it's possible to accurately do time estimation of each task.
There is a continuum between purely reactive/unplanned work to purely proactive/planned work:
Kanban →
Scrum 1 wk sprints →
Scrum 2 wks sprints →
Scrum 3 wks sprints →
Scrum 4 wks sprints →
mini-waterfall / RUP / Shape Up 6 wks cycles
IMO it's impossible to build and deliver a non-trivial feature in >= 3 weeks.
Detailed task management is an anti-pattern, initially issue trackers were used to track bugs only, not as TODO lists.
Under mini-waterfall once the stakeholders agree on the goals, approve the design documents and delivery dates, the developers can work autonomously, they don't need to use task management tools, they can do it with pen and paper, or in their head if they want, it doesn't matter . Everything else is micro-management, handling only imaginary tasks, no tasks discovered after the work has already begun.
---
[1] Map of SDLCs and Product Frameworks
https://twitter.com/nivertech/status/1695945592801800412/pho...
[2] Kanban - Scrum - mini-waterfall continuum