HACKER Q&A
📣 baal80spam

Why Not Kanban?


Yet another submission denigrating Scrum on the front page, and yet again people saying to try Kanban instead.

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


  👤 PaulHoule Accepted Answer ✓
I am all for it. For my side projects my main management method is to have a limited number of balls in the air at all times.

Where I work now we officially have sprints but we really practice a Kanban system.


👤 billybuckwheat
> why is Kanban not as popular as Scrum?

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?


👤 devdude1337
Scrum is advertised massively. There is certifications and consultancies all around the globe making money out of it. Marketing works, especially on people with a CXX title…

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.


👤 quickthrower2
I have not experienced this exactly. There are 3 methodologies I have seens.

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.


👤 watters
Most organizations use a widespread corrupted form of Scrum, the most important features of which are the two-week sprint and task estimates expressed in "ideal developer days" but labeled story points.

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.


👤 syndicatedjelly
Scrum can produce something out of nothing. Kanban can allow nothing to persist.

If a team is very low performing, scrum is great. Once they're high performing, drop the routine and let them practice Kanban.


👤 jiveturkey
huh. it is common in my experience. but there aren't thought leaders and consulting opportunities around it.

👤 croo
In Kannan there is no reports(daily standup) accountability (demos) and no minor deadlines(sprints).

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.


👤 nicbou
Kanban does away with sprints. You promise nothing but to pick tasks from the top of the column. This was a really hard sell for managers.

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.


👤 BerislavLopac
The problem is when a single methodology is seen as a silver bullet for all kinds of projects -- it almost never is.

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.


👤 deterministic
Most devs use Kanban where I work. It’s simple. It works.

👤 nivertech
Task Decomposition / Task Management is only a small part of SLDC, but both Scrum and Kanban mostly focusing on it.

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
The shorter the cycle, the lower the response time, the greater the planning overhead and the lower the software quality.[2]

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

https://twitter.com/nivertech/status/1690669746578980864