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
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 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 by just following it's practices.
Kannan is great when the team moves on its own and with a good manager who calibrates the aim from time to time.
People always say this but ... why?
Yes, maybe some book somewhere says that Kanban™ doesn't have stand-ups or demos, but the secret is in the name: agile. Just do what is right for your team, and drop the rest.
A lot of the pain of "scrum" comes from the misunderstanding and abuse of story points, velocity, and sprint planning. Kanban can help relieve these pain points specifically, but just because you're now using a different way to project progress doesn't mean you also have to throw away other practices that may be beneficial to your team.
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.
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.
As a manager in my org I'm not driving deadlines, that's the PM and they mostly know what can get done and are reasonable. Its expected that if you keep jumping the line with stuff, other things are delayed. One downside that is concerning is focus time on specific areas of an app for developers and tech debt in those areas. Its like they keep hopping around from tree to tree like a squirrel. People that like long projects where they are 95% of the time building new things and don't have to deal with production issues, bugs, etc. this org and work style isn't for them.
The manager should be there to act as an umbrella and protect the engineers from the morons, the technical leadership leads the engineering team, and they make choices on what is high priority to get things done.
Product management absolutely makes decisions like that.
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.
The only difference between Kanban and scrum that I can see is that Kanban doesn’t insist on a 2 week sprint, although there’s no reason why you can’t adopt a Kanban system with a 2 week checkpoint and prediction window as well.
Scrum shows you where you are and tries to predict where you'll be in 2 weeks.
Where Scrum goes horribly wrong is when management tries to treat the 2 week prediction as a guarantee rather than a guess ... and to compound the problem imposes tougher predictions/deadlines to squeeze out more work.
Whatever the stated intentions, in practice Scrum almost always goes bad in this way.
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 too freeform for most management and sales to want to follow or encourage. In contrast to Scrum and most traditional planning approaches you don't make a commitment (whether it should be a commitment or not is another issue) to a particular set of capabilities on a particular date. You promise to get work done, as it comes in, based on the priority and capacity of the team/organization to handle.
There are no, or few, big meetings. There's no ritual. There are no conferences to attend and certifications to append to your email signature. What's the fun in that for a manager who wants to promote themselves or travel on the company dime? It also requires them to trust their staff which is hard for a person who isn't trustworthy themselves because they're too self-interested and assume everyone else is the same.
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.
If a team is very low performing, scrum is great. Once they're high performing, drop the routine and let them practice Kanban.
Where I work now we officially have sprints but we really practice a Kanban system.
Kanban is a great fit for the reactive work (e.g. bug 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 with high software quality 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.
Another distinction lies in how Scrum views developer teams as conveyor belts. In this approach, you can assign any set of imaginary tickets, regardless of their relation, and the team will implement them.
To the contrary in the mini-waterfall methods, you present developers with a cohesive collection of tasks featuring pre-approved, thoughtfully planned, and peer-reviewed designs. The best case is when devlopers are doing design by themselves, that way they don't need somebody else to decompose work into detailed tasks for them.
---
[1] Map of SDLCs and Product Frameworks
https://twitter.com/nivertech/status/1695945592801800412/pho...
[2] Kanban - Scrum - mini-waterfall continuum