Hacker News new | past | comments | ask | show | jobs | submit login
Ask HN: Why Not Kanban?
26 points by baal80spam on Aug 30, 2023 | hide | past | favorite | 25 comments
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




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.


In Kannan there are no reports(daily standup) accountability (demos) and no 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 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.


> In [Kanban] there are no reports(daily standup) accountability (demos) and no deadlines (sprints).

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.


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.


This exactly. The same thing happens with development frameworks and compliance (even worse of a racket in compliance).


That is actually not true. Kanban has all the certifications and trainings just like scrum and has even maturity models that your company can be graded at.

See https://kanban.university/


That is weird for me to look at - I am sure 15 years ago I would have been all over that site super excited to learn. Now I am like "meh!"


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.


Kanban allows for critical fixes/features to jump ahead of the line and its obvious what work is getting traded off for later. Kanban also flows very nicely with a CI/CD process where when something is tested and ready to ship, it gets shipped. I believe the essence of agile is these two concepts - shipping working software and lean prioritization. Things getting stuck in a backlog is a good thing because that shows they aren't that important (other things keep skipping ahead) and you aren't building, testing and delivering software that is hardly used.

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.


But a manager might want to have at least a rough estimate of how much something costs before deciding what to buy. That is, they might want to know roughly how long something is going to take before deciding to put it as a high priority item.


It's not the manager's job to make technical decisions or choices of this nature, or at least it really shouldn't be.

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.


By "management", I meant people including product management.

Product management absolutely makes decisions like that.


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.


Doesn’t Kanban split development into chunks of work as well?

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.


Kanban shows you where you are (how you use this info is up to you).

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.


> 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?


> 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.


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.


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.


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.


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


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


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. 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
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 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

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


You can do Kanbans of Kanbans to get better focus over longer periods of time.


We do Kanban every sprint.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: