Live data from Hacker News

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

lucasfcosta.com

91–100 of 341 posts

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

#91
post #53

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 e…

The problem is even scrum doesn't give the predictability and observability better than kanban. It's extremely hard to predict what we need to do in next 2 weeks and what we can achieve in next 2 weeks. At my current company, half, if not more, of the tickets come in mid-sprint.

So even though the current company is using scrum, in my team I treat it as kanban with story point limited, meaning I start with a certain amount of story points, then add / remove as the sprint is going.

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

#92
post #77

Earlier quoted context omitted.

Cycle time on a board gets you that as well.

This provides more visibility and granularity, increasing confidence and satisfaction of customers.

How? How is pulling 10 points of work into every two week sprint "more visible" or "granular" than pulling anything as it comes up at a velocity of 5 points per week? I'm not even being contrarian, I truly don't understand how sprints could be better than knocking down a work queue.

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

#93
post #73

Earlier quoted context omitted.

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 softwa…

> 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). IME most of the time they need to get over it. The reality is that estimating in that kind of detail would be expensive and not worth the effort. However what they do reasonably need is the ability to priori…

It depends what you are working on, how you ship and how three rest of the company works. I work on Enterprise software that's not SaaS. We ship every 9-12 months. If we do it more frequently it just annoys our slow-moving costumers and increases our support burden because there are now more versions in support that might need patches. Our sales and marketing teams need to know when we ship. Sometimes costumers mighy need to adjust their own release schedules to when our next release is out. If one team needs longer for a critical feature, we need to know as early as possible so that we can discuss cutting scope, pushing the release out, cutting the feature, etc.

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

#94
post #87
post #53

Earlier quoted context omitted.

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 e…

Having predictability and observability is key to a business though, as higher level decision need to be made based on progress of the lower level teams.

In my experience, if the business has a higher level decision that depends on the progress of a lower level team, the only working approach is for the manager in charge of that decision to sit down with a person in the lower level team and discuss the state of things.

A metric compresses a very rich and nuanced opportunity into a false dichotomy.

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

#95
post #30

Earlier quoted context omitted.

I get that, that’s what I do with my team, but I’ve never heard that referred to as “doing Kanban”. Maybe I’m just being pedantic, but writing an article to say “you don’t need Scrum, just pull tasks off the board” completely misses the point of why teams use Scrum.

Scrum is pushing stuff into a sprint. Kanban is pulling the highest priority stuff through - it's done when it's done. Metrics/Analytics can be calculated when your done based on actual information, as opposed to the beginning when you're guessing, and likely to be held to your estimates.

I assume you still have planning meetings though only that you don't do commitments, right? Is this in any way different than the planning part of XP?

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

#96

The underlying triangle here: Out of time, scope, and quality, you can pick two to specify but you can't constrain all three. Scrum specifies fixed time and quality ("definition of done"), with scope as the flexible variable, as tasks get pushed out of each sprint. Kanban specifies fixed scope and quality, letting time be the floating factor for each task. Waterfall specifies fixed time and scope, with the inevitable…

Of course fixing time and quality requires the ability to create accurate estimates.

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

#97

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…

> without those annoying team planning/documentation meetings, work will get duplicated, done hastily, done with no discussion or thought toward testing, architecture, maintainability

I don't see why that is necessarily the case. It certainly didn't happen on the Kanban teams I've led. Maintaining the backlog and reviewing the work in progress is just as important in Kanban as in any other process.

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

#98
post #76
post #53

Earlier quoted context omitted.

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 e…

I agree. In my experience that outside visibility is mostly a mirage. Velocity metrics, burndown charts, point estimations, and all of that have been at best aspirational white lies and at worst outright falsehoods on almost every scrum/agile team I've ever worked on in the past fifteen years. In actuality many scrum teams are doing something closer to kanban day-to-day under the fake veneer of scrum/agile sprints on…

Ye padding estimates and report time according to the estimate to make the burn down chart straight was what I learned to do when Scrum was forced on my team for no good reason at all.

-"It is impossible to do accurate estimates"

-"You will get better at it"

I wonder if the Scrum Master knew that in the end "get better" is "starting to cheat".

Do anyone else share this experience?

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

#99
post #87
post #53

Earlier quoted context omitted.

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 e…

Having predictability and observability is key to a business though, as higher level decision need to be made based on progress of the lower level teams.

Yes, predictability is better for business, but business also needs to accept that there are limits to the amount of predictability you can achieve in software development, and trying to force too much process is only going to predictably increase delivery time. In my experience, working with high level estimates which you keep updating from time to time is the best compromise.

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

#100
post #53

Earlier quoted context omitted.

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 e…

The problem is even scrum doesn't give the predictability and observability better than kanban. It's extremely hard to predict what we need to do in next 2 weeks and what we can achieve in next 2 weeks. At my current company, half, if not more, of the tickets come in mid-sprint. So even though the current company is using scrum, in my team I treat it as kanban with story point limited, meaning I start with a certain…

I have seen a very predictable scrum, but the tradeoffs with productivity were comical. In this very large corporation, most developers could do most of the tasks in their 2 week sprints in 3 days of actual work. But they don't know if they are going to get 3 days of actual work, or some other team is going to keep master broken for a week. Therefore, your typical sprint involves mostly fictional standup updates, as to make sure that, when things go more than a little too well, the shameful levels of sandbagging aren't visible in jira or in git.

If you ask me, that level of predictability is a poor tradeoff, but hey, it's the same kind of organization that decides that SAFe scrum is a serious methodology.

Post reply on HN