Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

lucasfcosta.com

Post reply on HN
Print view View original

51–60 of 341 posts

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

#51

Post by irjustin »

rqtwteye wrote: post #44
crazygringo wrote: post #27

Earlier quoted context omitted.

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.

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.

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

#52

Post by ethbr0 »

crazygringo wrote: post #27
DanHulton wrote: post #3

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.

The differences I've observed between successful-and-unsuccessful, Scrum-and-Kanban have been dominated by people over process (yes, I know).

1. Does the team have the right people, with the right skill sets, wearing the right hats? (e.g. BAs or PMs doing those actual jobs)

2. Does the team have self-motivated, high-performance people?

I have yet to see any process that can overcome "No and no."

Large tech org's knee-jerk response to failures is to increase the formalism of their agile frameworks, but that's just a bandaid over gangrene.

If they think the solution to bad people is more process, they've already lost.

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

#53

Post by josephg »

DanHulton wrote: post #3

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 think the "problem" is that Scrum orients more to the needs of people outside the team. So, (in theory) you get clearer reporting and more visibility into whats going on. People expect that extra reporting to be free, but its not free. The time taken to do team task estimation, update jira tickets and have retrospectives is time spent not programming.

The sad truth is that most management teams would prefer their employees to be predictable and observable (ie, under control) than be efficient. Especially if nobody can actually quantitatively measure the loss of efficiency.

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

#54

Post by Tagbert »

esafak wrote: post #47
DanHulton wrote: post #3

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.

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.

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

#55

Post by JakeAl »

dgdosen wrote: post #41
beoberha wrote: post #32

Earlier quoted context omitted.

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.

Because work is deadline driven by whoever is paying the teams' salaries. If you can't accurately estimate when you can get it done, you break it down until you can you get replaced by someone who can.

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

#56

Post by natch »

To get a known stable known velocity, so many things have to go right.

The most disruptive thing sabotaging this, all other things being positive, is typically manager turnover when they each have their own differing ideas on how, and whether, and what, to adhere to.

Hold your advice; doing anything about it is not at the pay grade of anyone who will be with the company for more than another six months. Unless… you leave the company. That is the one effective action you can take.

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

#57

Post by tysam_and »

DanHulton wrote: post #3

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've seen Kanban work well on smaller scales, and Scrum work well on larger scales.

I cannot for the life of me work in the churn and development pace of a Scrum team, so Kanban (and the culture around it) is best fit for me.

I think it also depends upon the type and culture of people working in the team as well. Some teams work really, really well with the predictable cadence, others do not.

It's a case by case kind of situation, I think.

That said I highly prefer Kanban personally for an number of reasons.

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

#58

Post by irjustin »

emeraldd wrote: post #31
leetharris wrote: post #10

Earlier quoted context omitted.

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.

Scrum does not provide accountability. It creates the illusion of accountability while creating artificial touch points that effectively become the only time anyone thinks about what's going on. At least that's how I've seen it operate in almost every instance I've ever worked with it. Of course, the counter to that is that we're not doing scrum right. The question in my mind then is if I haven't seen a single team d…

> It creates the illusion of accountability while creating artificial touch points

I'm surprised at the conclusion because this statement can be said of any framework. It's up to the people to actually make it accountable. Doesn't matter if it's Scrum/Kanban or another one. If your org treats accountability as "an illusion" then it's doomed to fail regardless.

> The question in my mind then is if I haven't seen a single team do Scrum correctly there's something wrong that makes the methodology so difficult it can't be applied ...

This I 100% agree with. I've come to look at these frameworks (kanban, scrum etc) as I look at the Bible... no church gets it right and never will. It's not possible.

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

#59

Post by esafak »

Tagbert wrote: post #54
esafak wrote: post #47

Earlier quoted context omitted.

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.

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.

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

#60

Post by fnordpiglet »

DanHulton wrote: post #3

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 have the software engineering uncertainty principle. The more you try to measure and estimate and predict software velocity and delivery the more you slow it down. I think this is probably true of any largely creative and problem solving task, but compounds because most of the uncertainty derives from dependencies requiring those dependencies to likewise measure and slow down. The more complex and interconnected an effort is the more scrum hurts it.
Post reply on HN