Live data from Hacker News

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

lucasfcosta.com

41–50 of 341 posts

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

#41
post #23

Earlier quoted context omitted.

They're also visualized (on a kanban board) - are you doing that? Make work visible.

For us, visibility isn’t an issue. I would say estimations are by far the biggest struggle we have in “doing Kanban”. Luckily, they’re not super important for us and I usually bubble up a very rough estimate in monthly reports to management, but in an org where they matter more, I can absolutely see why Scrum gets adopted the way it does.

Why do you estimate when using a kanban? You might look at an item and break it down for simplicity. You also might go in with a goal of 'one card per member per day' or something similar. But nothing should be fixed to an estimate. If something is delayed, it should show up stuck in a lane. Respond as needed.

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

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

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

#44

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…

But velocity of code written is not the same as velocity of value delivered. In Scrum, estimation meetings usually result in follow-ups with stakeholders that can (and often do) radically change the stories themselves. Totally different code winds up getting delivered that increases actual value delivered, even if "lines of code written" slows. That's the whole point of agile, to deliver value rather than code.

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.

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

#47

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…

If I am being generous, Scrum is for service teams, which can benefit from some of Scrum to temper unreasonable requests of senior stakeholders by providing a social contract on what is going to be worked on. More autonomous teams don't need it.

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

#48
Beware blanket statements! I work with sound in games and have multiple times tried to do Kanban, both from an internal team and an outsourcing team, because of basically the same reasons mentioned in the article - it's agile and task based, and seems like a good fit to be a "factory" for sound assets.

However games are iterative by several orders of magnitude more than traditional tech (I've also been CTO at a more traditional design/consulting firm) and constantly evolving and audio team, both internal or external, end up tightly embedded over the course of 2-3 year long projects, and Kanban ALWAYS breaks down because the edges of tasks are fuzzier than you expect.

Scrum (real scrum, not the surface level dogmatism that passes for it in many places) does work better in this situation. I find myself saying this often "The best tool is the simplest one that does what you need it to". I really do prefer Kanban! It's far simpler. For projects that have clear needs and stakeholders it's great. For "factory" type set ups that provide tools to other internal stakeholders it also works great. But for places where the technical requirements are fuzzy the added complexity of Scrum is helpful, since it focuses on OUTCOMES rather than MEANS/tasks.

Don't be afraid to try different approaches for different sprints/releases and tweak formulas. You can normalize estimation by keeping it consistent while also changing methodologies. But just because Scrum is overused and misunderstood doesn't mean it's useless.

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

#49

- PM/PO loves scrum, that gives them an illusion of controlling the dev speed/progress... - the estimate is a joke... - the standup is useful to know who is pretending work. but no need a daily standup for sure. and a non-technical PM with scrum makes things worse.

Sounds like you have a very poorly run and dysfunctional team. When applied correctly, good project management ends up better for everyone.

"When applied correctly, good project management ends up better for everyone."

With good project management you can make any process work, be it waterfall, scrum, kanban or others. All dysfunction comes from people perpetuating processes that don't work. That's what agile was about originally.

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

#50

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…

I did scrum once and we were literally always sprinting. The daily standup consisted of trying to think of excuses why the multiweek task wasn't completed (like they expected) and one dude who "zereo'd his inbox" every day.
Post reply on HN