Live data from Hacker News

You don't need Scrum, you just need to do Kanban right (2022)

lucasfcosta.com

61–70 of 341 posts

Re: You don't need Scrum, you just need to do Kanban right (2022)

#61

Every team I've worked on that has switched from Kanban to Scrum has slowed down and never regained the previous velocity. Further, many of the promised benefits of Scrum (things like better insight and predictability about delivery rates) never materialized. Every team that I've worked on that has switched from Scrum to Kanban saw an immediate improvement in speed that never disappeared. Once, just once, I was lucky…

Yes but raw velocity is not the only thing that matters. For some projects it is, but for many the accountability of Scrum + the grouping helps with dependency management across an organization.

Thanks for confirming that Scrum is really for flogging.

Re: You don't need Scrum, you just need to do Kanban right (2022)

#62
post #8

Is “doing Kanban” just having tasks on a board without any sort of sprint structure? I feel like it’s a bit of a false equivalence. While I won’t ever defend all the cruft that comes with Scrum, the article seems like a bit of a straw man.

"kanban" is all about maximizing flow of completed tasks, and minimizing/limiting work in progress.

Someone is either working on a task, or idle. A task is either being worked on (making progress), or it's not being worked on. -- A task will get completed quicker if you can minimize the amount of time it's "in progress" but not being worked on.

If you have 5 workers and 15 tasks in progress, 10 of those tasks won't be making progress.

Often, a task may be blocked by requiring some action from someone else. (e.g. PR review, or more resources, or blocked on some other task).

The 'kanban board' is about visualizing work in progress. -- By visualising the work in progress, it's easier to identify bottlenecks & inefficiencies.

Re: You don't need Scrum, you just need to do Kanban right (2022)

#63
post #19

> This demand for estimations leads to unproductive and unnecessary estimation meetings. These meetings are unproductive because they cause developers to spend time debating whether something is worth two or three story points instead of actually writing code. They’re also unnecessary because if you feed the system with more work as soon as software comes out, estimations don’t matter. Only if all tasks are of equal…

Picking up on

> They’re also unnecessary because if you feed the system with more work as soon as software comes out, estimations don’t matter.

The question is: estimations don't matter to who? As much as I'd like a constant stream of quality features to be good enough, in reality senior managers and clients want to know what they're getting for their money, and when they'll get it (at least roughly). If your software is doing something important, it's likely that people will be depending on it and when a new feature ships can have a significant impact on how they work, and in turn, what they can deliver.

Re: You don't need Scrum, you just need to do Kanban right (2022)

#64

Earlier quoted context omitted.

To be honest I have never seen this materialize. Usually you get some input from product management, the devs estimate it and then do it. I have never seen feedback from estimation to requirements.

Isn't that because the product manager is gathering requirements from other orgs/users? > I have never seen feedback from estimation to requirements. Perhaps you work with perfect pms! jokes aside, usually all it takes is an estimation of 8 or 13 and something changes real fast.

Yea, they tell you that they don't believe your estimates and stop asking for them before setting the deadline.

Re: You don't need Scrum, you just need to do Kanban right (2022)

#65

Every team I've worked on that has switched from Kanban to Scrum has slowed down and never regained the previous velocity. Further, many of the promised benefits of Scrum (things like better insight and predictability about delivery rates) never materialized. Every team that I've worked on that has switched from Scrum to Kanban saw an immediate improvement in speed that never disappeared. Once, just once, I was lucky…

The only way better insight would happen is if the devs behaved like product managers/owners. We don’t want it.

I can actually see predictability improving, but mostly because we will ship whatever at the end of the sprint and let any issues come back as bugs later. We always ship on time at one Scrum job, but the quality is very low.

Re: You don't need Scrum, you just need to do Kanban right (2022)

#66
Kanban is great for systems with predictable output. If the work units remain mostly the same, you can greatly increase flow efficiency and velocity using kanban. It's basically waterfall meets JIT delivery (which is why it worked so well for Toyota).

Scrum is for less predictable work, where many/most of the requirements and/or challenges are not well known or defined yet, or are likely to change as new information becomes available. For this kind of work, you need a constant feedback mechanism so that the captain can adjust course as needed while traversing uncharted waters.

I currently work in a team that builds code that accesses poorly or completely undocumented systems, and is seeking a market fit for new products. In both of these cases, agility is far more important than velocity, so scrum is the right approach. In previous places, the work my team did was very predictable, so kanban was the right approach.

Note: There's nothing wrong with having both in the same company. Team has predictable work? Kanban. Else scrum.

Re: You don't need Scrum, you just need to do Kanban right (2022)

#67
post #42

I’m not a huge scrum defender - I’ve seen it done right and wrong. Same with Kanban. The only real problems I have with Kanban is that without those annoying team planning/documentation meetings, work will get duplicated, done hastily, done with no discussion or thought toward testing, architecture, maintainability. And that’s not exclusively true of Kanban. But I feel like the lack of organization can turn it from l…

Those same problems still happen in Scrum and it's very hard to get out of duplication hell once the backlog gets sufficiently large. I personally think Scrum is theoretically great if done right and with smart people, but that is rarely the case.

Duplication hell is the current bane of my existence - I think we would agree that it’s more of an inter-team coordination issue than it is the type of thing that you and the four other people on your team can fix with Kanban/Scrum. But I do feel like Scrum is better at the very least at stopping this from happening because that longer ramp up time from “customer wants X” gives people a chance to say “wait so and so already did that for their turn”

Re: You don't need Scrum, you just need to do Kanban right (2022)

#68
post #13

I am probably missing something but is kanban even the correct metaphor for creative work(like software development). Kanban is a back pressure mechanism that can get your factory logistics system running smoothly. However the logistics of creative work is very different than the logistics of assembly work. There are almost no parts needed, why is a backpressure system for part delivery even useful?

It's not, it's one of those cases where IT took some vague ideas related to a concept (e.g. visualizing/minimizing WIP and having a continuous flow) and decided that those meant we're doing the same thing.

See also "lean manufacturing/software development" and obviously "software engineering".

Re: You don't need Scrum, you just need to do Kanban right (2022)

#69
post #59
post #54

Earlier quoted context omitted.

I’ve always considered Kanban’s lack of sprints to be well suited to service teams where individual requests are not naturally tied to each other and there is no benefit of delaying delivery into sprints.

Everybody wants their ticket serviced ASAP. Scrum helps manage that expectation. If a sprint is underway, new requests have to wait for the next sprint unless an agreement is reached to drop an existing ticket.

Cycle time on a board gets you that as well.

Re: You don't need Scrum, you just need to do Kanban right (2022)

#70

Kanban is great for systems with predictable output. If the work units remain mostly the same, you can greatly increase flow efficiency and velocity using kanban. It's basically waterfall meets JIT delivery (which is why it worked so well for Toyota). Scrum is for less predictable work, where many/most of the requirements and/or challenges are not well known or defined yet, or are likely to change as new information…

Genuine question: How does Scrum help with less predictable work?

From my experience, the opposite is true: New things are discovered during sprints, but at that point it's already too late because that work item has already been estimated in the sprint planning (most of the time incorrectly). Also the arbitrary sprint deadlines don't help either.

Post reply on HN