Hacker News Reader

Comment by tasubotadas | Hacker News Reader

I must live in some kind of alternative reality where 80% of teams that I worked with liked Scrum (and I lead tens of teams).

The remaining teams just needed Kanban.

Not sure what everybody else is doing here, but I have seen teams where before we started doing scrum+jira all tasks were coming on Skype and discord, and stakeholders were either micromanaging (programmers managed by non-programmers) or either would forget project for 1 month and would come back to find something delivered that completely missed expectations.

After moving to proper task tracking and clear planning and review rituals, the developer satisfaction went through the roof (before that people were borderline considering quiting)

View on HN

> I must live in some kind of alternative reality where 80% of teams that I worked with liked Scrum (and I lead tens of teams).

I think it has a lot to do with how good estimates can be, and how much can be shared between the members of the team. The extreme situation where the tasks are all boring/predictable and everyone in the team can do everything probably works well with Agile (or any estimation-based religion, I suppose).

The problem is that in many situations, many tasks are not very predictable (because they involve novelty, risk, exploration, challenge), and not everyone is capable of doing everything. In that case the estimates are a big joke, and Agile is just bullshit.

I'm one that prefers Kanban myself. List each task, be able to group those tasks, move those tasks to whoever needs them, move those tasks to QA or wherever finished tasks go. So, I prefer Trello over Jira any day

How do you "prefer kanban"? Don't all these methodologies use kanban boards?

Kanban is more than just a board. To have effective Kanban your process needs to:

1. Be pull based - someone only picks something new up when they have the capacity to do so. There's no "finish this set of tasks by the end of the sprint" because there are no sprints, just priorities

2. Manage work-in-process, either explicitly or implicitly. This prevents the team working on too many things at once, which leads to any given piece of work taking a long time to get to production

Kanban (for the definition as I understand it) ditches sprints. There's the backlog, tickets that are ready to be worked on, in progress tickets, and various flavors of "done". It's common for kanban teams to ship directly to production once tasks/stories are merged in.

Reply on news.ycombinator.com